I'm trying to build an app with realtime text editing and am stuck on how to best architecturally proceed. Currently, I'm using graphql with apollo and hasura to fetch user profile information along with document metadata and content.
To save content, we are currently just debouncing graphql mutations of the entire document. The drawback here is a user can navigate away without the document content being written back. As a result, I want to move to an approach based on websockets.
For an app that involves realtime text editing, where on each stroke we're sending a delta update, should I try to
- use graphql subscriptions with a custom resolver since I'm already using apollo and hasura, or
- use a vanilla, separate websocket for each document and avoid using graphql completely?
In both cases, instead of directly writing back to postgres, we would use a redis cache while the websocket connection is live, and then persist the cache content back to postgres when the connection is closed. The former approach would take advantage of already having apollo client, and authentication through hasura; while the latter approach would avoid sending binary blobs (delta updates) over graphql but require more setup.