Graphql subscription with multithreaded nodeJS server

Question

I am trying to create a graphql subscription service in a multi-threaded architecture.

If I, for example, create a subscription like below

const SOMETHING_CHANGED_TOPIC = 'something_changed';

export const resolvers = {
  Subscription: {
    somethingChanged: {
      subscribe: () => pubsub.asyncIterator(SOMETHING_CHANGED_TOPIC),
    },
  },
}

and have multiple instances of identical nodeJS server running on my docker cluster, I do not want each of the instances to send subscription event to the client every time new subscription publishing has been made. I only want one (of course preferrably load balanced among the clusters) to be responsible for sending subscription to the client.

Only way I can think of doing this right now is to create an isolated server that is in charge of subscription event and only receive subscription event from a single source as a client. But same multi-threading problem I have mentioned above occurs if I spread out the load of the subscription-responsible servers.

How do I make sure that I only send out single subscription event to the client when there are multi-threade nodeJS backend? Is it only possible with the client side filtering? ie ignore events that have already arrived - However I think this is a terrible waste of resource as subscription grows.

Answer 1

In this case I would use Redis as a PubSub, that way you have "one source of truth". ie https://github.com/tomyitav/redis-messaging-manager .

I'm sure there are plenty of other libraries that do something similar