graphql-hive / graphql-hive/envelop
Make it possible to skipResult() inside of `onSubscribe.onSubscribeResult.onNext` envelop plugin to avoid/skip re-send unchanged data
- Dominant language
- No language data
- Stars
- 827
- Forks
- 132
- PR merge metrics
- No merged PRs in 30d
Description
# Problem
I was recently researching the best approaches to implement real-time subscriptions sync with database and came across Hasura's approach.
https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md#when-do-we-refetch
Instead of watching to real database events, they are syncing at every 1 second, and the justifications are quite reasonable.
Furthermore, in order to optimize resources, they avoid sending same data over the network every 1 second, they only send if it changed. Which also makes perfect sense.
Inside of Schema builder, its [simple](https://github.com/hayes/pothos/issues/1349) to make the resolver call every 1 second.
But getting it to avoid sending duplicate messages seems to be a challenge.
# Solution
From Envelop plguins, we can create a custom functions to "rewrite" the result of each data response of subscription, but there is no API to avoid/skip sending it.
I think with a new option called `skipResult` It would make it possible to create a cache like Hasura's for Subscriptions
Does this make any sense?
```ts
onNext: ({ args, result, setResult, skipResult }) => {
const alreadySent = cacheCompare(args, result);
if (alreadySent) {
skipResult();
}
},
```
I took a good dive into the core/plugins code, did several tests/changes but always tried to avoid sending the expected data, graphql-ws threw an error
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the onSubscribe.onSubscribeResult.onNext flow in the core/plugins code and inspect how graphql-ws handles subscription results. Determine where a skipResult API could affect result delivery, then verify that unchanged subscription data can be skipped without triggering a graphql-ws error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, typescript
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100