subscriptions.md

Simple case

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" }})

Simple case withFilter

See: https://github.com/apollographql/graphql-subscriptions

Using topics filtering

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.

object = deepSortKeys(object)
JSON.stringify(object).replace('"',"_").replace(",","").replace(":",""_")

What is object from this example, the filter argument coming from the subscription like {userId: {eq: "enda"}}? If that is the case, this will only work by using wildcards won't it? The create mutation resolver will publish the topic, and obviously this will not have the filter information available to it so it should use a wildcard in the topic path:

Mutation

const topic = 'CREATE_NOTE/filter/#';
pubSub.publish(topic, payload);

Subscription

const topic = `CREATE_NOTE/filter/${hashFn(filter)}`;
...
subscribe: () => pubsub.asyncIterator(topic)

need to set up a local OpenShift cluster to play with and learn about subscription topic wildcards.

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.

The way I seen this done was always related to the user owning the object - then you publish to topic with his id.

yep, saw it this way first after our conversation yesterday but wanted to get clarification on what object was.

This is very very specific to the auth implementation we have and it will be hard to have as generic provider.

Indeed.

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.

👍