m19c / graphql-firestore-subscriptions Goto Github PK

Some types in graphql-firestore-subscriptions package are not optimally designed.
In addition, various Objects and Functions are also not clearly defined.

npm i --save @m19c/graphql-firestore-subscriptions
npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@m19c%2fgraphql-firestore-subscriptions - Not found
npm ERR! 404
npm ERR! 404 '@m19c/graphql-firestore-subscriptions@*' is not in this registry.

Hi, I'm not sure the proper way to do this, but I was looking at your example and wondering how to subscribe users to only new comments that are directed at them.

Do I somehow pass in the userId with the options?

const userHandler: UserHandler = (broadcast, { userId } = { userId: undefined }) => {
  return firebase
    .firestore()
    .collection(`users/${userId}/comments`)
    .onSnapshot((snapshot) => {
      snapshot
        .docChanges()
        .filter((change) => change.type === 'added')
        .map(({ doc }) => broadcast({ id: doc.id, ...doc.data() }));
    });
};
export const pubsub = new PubSub();
pubsub.registerHandler(NEW_COMMENT, (broadcast, options) => userHandler(broadcast, options));

I was also looking at using withFilter. Not sure if this is the intended usage:

commentAdded: async (_, { userId }, context) => {
      return withFilter(
        () => pubsub.asyncIterator(NEW_COMMENT),
        (payload, variables) => {
          return payload.comment.commentor === userId;
        },
      );
    },
  },

Hi Marc. Thanks for sharing what seems to be a very useful tool! As new as GraphQL is to me, I can’t get my subscription resolver to trigger at all. Would you be willing to take a quick look at this and share any obvious insights I’m missing (note that this is all client-side, perhaps GraphQL can't be used like I'm intending?). Many thanks!

/*
Database.subscribeEntity is just a utility around firestore.onSnapshot 
It returns the unsubscribe function
*/
const ps = new PubSub();
ps.registerHandler('ENTITY_UPDATE', broadcast => 
    Database.subscribeEntity( '4uKadJUdvbhDtwc3ofUEfAkwwob2', (data) => {
        broadcast({test: 'test string'})
    })
);

var subscribeType = new GraphQLObjectType({
    name: 'Subscription', 
    fields: {
        entityUpdate: {
            type: GraphQLString,
            subscribe: () => {
                console.log('I am never called');
                return ps.asyncIterator('ENTITY_UPDATE');
            }
        }
    }
});

var queryType = new GraphQLObjectType({ ... });

var testSchema = new GraphQLSchema({query: queryType, subscription: subscribeType});
var testSubscriptionQuery = `subscription watchEntity {
    entityUpdate 
}`
graphql(testSchema, testSubscriptionQuery).then((response) => {
    console.log(response);
});

`

I was scratching my head for quite a while about the behavior of this (based on the full example) compared to simply publishing directly on mutations with something like graphql-yoga's pubsub.

Seeing how I suppose neither using the apollo-client, nor subscribeToMore is particularly rare, I wondered whether it would be worth mentioning in the README that if one uses it, one has to skip broadcasting the initial snapshot. (I keep track of it with an isInitialSnapshot in the handler.)

This has also made me realize that in a scenario where you have e.g. 1000 documents in that collection and hundreds of people per hour loading up the page, that's a lot of unnecessary load and traffic. Maybe this would also be good to point out?