Real Time GraphQL — Chat (Part 1 Server)

I always ask people…

Do you really need real-time?

This question really boils down to your data-access patterns in product. If most of your specifications are static lists or content, then having a simple request and response transport coupled with a caching client can serve most of your needs.

This is what is I love about GraphQL technologies, they are optimized for the majority use case and give you alternative methods to keeping data fresh:

• Polling
• Refetch
• Client Cache Invalidation

Previous Real Time Experience

Coming from the Meteor community previously, data access was “real-time” via a piece of technology called DDP (Distributed Data Protocol). This allowed the engineer to create a subscription on the client for pieces of data, sent over WebSockets via “live-queries”.

This real-time solution works great for experiences demanding real-time feature sets, and having your data refresh on screen in response to any document changes is magical, but it leads to tons of waste. In this pub sub system you would, using Mongo Syntax, enforce the data over the wire via “projections”. A client developer would specify fields they need to render…