1

I am trying to understand the following part of documentation.

Please note: By default graphql-subscriptions exports an in-memory (EventEmitter) event system to re-run subscriptions. This is not suitable for running in a serious production app, because there is no way to share subscriptions and publishes across many running servers.

What means sharing subscriptions/publishes and in which cases I may need it in production?

Pablo
  • 28,133
  • 34
  • 125
  • 215

1 Answers1

1

In a production environment, you'll typically want multiple instances that run on different servers to increase resiliency. This way, a single server failure won't necessarily impact availability. As your business and the resource demands on your server grow, it's also often easier and more cost effective to scale up horizontally by adding more servers than by adding more resources to your individual server.

The EventEmitters created by the basic PubSub implementation are tied to an individual processes. There's no way to share their usage across multiple processes, let alone different servers. So if you publish something, an application running on a different process or server will not be notified of the event. On the other hand, if you use the Redis implementation of PubSub (or pretty much any of the other ones), then Redis will serve as a "go-between" for your application instances -- each application will publish events to Redis and subscribe to it for changes.

Daniel Rearden
  • 80,636
  • 11
  • 185
  • 183