const SOMETHING_CHANGED_TOPIC = 'something_changed';
export const resolvers = {
Subscription: {
somethingChanged: {
subscribe: () => pubsub.asyncIterator(SOMETHING_CHANGED_TOPIC),
},
},
}
pubsub.publish(SOMETHING_CHANGED_TOPIC, { somethingChanged: { id: "123" }})
See: https://github.com/apollographql/graphql-subscriptions
export const resolvers = {
Subscription: {
todoChanged(_parent, args, info): {
subscribe: () => pubsub.asyncIterator(SOMETHING_CHANGED_TOPIC + "_" + hashFn(args.filter) || ""),
},
},
}
Publish:
pubsub.publish(hashFn(SOMETHING_CHANGED_TOPIC), { somethingChanged: { id: "123" }})
Ideally we need to have both approaches. hashFn is embeeded on compilation time which means we cannot handle this for cases like graphql-serve etc.
I think that wildcard is defined only on server to define namespace for multiple topics.
When publishing we need to use explicit topic. This is major problem as we cannot rebuild it as you have mentioned.
The way I seen this done was always related to the user owning the object - then you publish to topic with his id.
This is very very specific to the auth implementation we have and it will be hard to have as generic provider.
As you have mentioned hashing will not work efficiently and in some cases will produce even worse results than in mem filtering.
I guess we can do inmemory filtering an call it a day + create follow up to extend our auth implementation to supply ownership subscriptiuons or similar concept.