For more sane usage of our CDN - we've decided that we don't want to cache any GraphQL queries that contained errors. Our clients should likely be more resilient as they'll encounter such responses with errors, but if we cache those we'd likely be 'down' for longer than needed when there was some upstream hiccup.
Ideally, we'd be able to implement something that accomplishes this without needing to re-parse any response into JSON to look for errors, or anything like that.
To that end - I'm proposing a patch to express-graphql where we'll have access to the JSON.
Why a patch?
While we don't typically reach for patches, in this case:
there is a corresponding spec
we're not anticipating upgrading this lib anymore (after the last upgrades from @MounirDhahri ) - eventually we need to move off of it anyway, and thus likely re-implement any patch or non-patch code
while there are other solutions that don't involve a patch (putting this logic in the Cloudflare worker, custom MP middleware to intercept the response) - those do involve needing to parse the JSON for every MP request, which is kind of a steep performance penalty all to avoid a couple lines of a patch, especially when most requests won't even have an error.
What this does
For more sane usage of our CDN - we've decided that we don't want to cache any GraphQL queries that contained errors. Our clients should likely be more resilient as they'll encounter such responses with errors, but if we cache those we'd likely be 'down' for longer than needed when there was some upstream hiccup.
Ideally, we'd be able to implement something that accomplishes this without needing to re-parse any response into JSON to look for
errors, or anything like that.To that end - I'm proposing a patch to
express-graphqlwhere we'll have access to the JSON.Why a patch?
While we don't typically reach for patches, in this case: