Open swolidity opened 5 years ago
swolidity
commented
5 years ago Some interesting links:
We are planning to give you very simple hooks and integrations to support WebSockets (e.g.: PubNub or Pusher). For scalability reasons, it's likely you'll want to separate the code that deals with the "request-response" lifecycle from the realtime subscription. @rauchg
Dieff
commented
5 years ago Thought: a problem with the idea of Apollo subscriptions + Fanout is that you need some sort of intermediary storage to remember if a client is subscribed or not. (https://github.com/fanout/apollo-serverless-demo#how-it-works).
What if we simply used Fanout to send JSON messages to clients informing them that there was new data available? Fanout doesn't care if you submit a message to a channel that has no subscribers. On the front end, we would re-fetch data whenever a message came through with that key in the apollo cache.
For example, a user is sitting in a chatroom for their class. Another student posts a message. On the api, the message creator function (a resolver) sends a POST to Fanout. Since the first user is sitting in chatroom, they are connected to a websocket with the fanout channel class/:id, and they get the message from Fanout. At that point, we use the apollo cache to run another Query for new messages in that thread.
Disadvantages of this approach are that we don't actually have any graphql subscription support. We are faking it with an outside approach. Also this is slower then a subscription because it requires an extra round trip to the server to get the new data.
Creating this issue to discuss and gather information on implementing GraphQL Subscriptions on Zeit Now V2 which is lambda and does not currently support websockets.