dotansimha / graphql-yoga

🧘 Rewrite of a fully-featured GraphQL Server with focus on easy setup, performance & great developer experience. The core of Yoga implements WHATWG Fetch API and can run/deploy on any JS environment.
https://the-guild.dev/graphql/yoga-server
MIT License
8.25k stars 572 forks source link

Support custom media types (HTTP Content-Type) for the normal request processor #3217

Open laurisvan opened 7 months ago

laurisvan commented 7 months ago

Is your feature request related to a problem? Please describe.

Our GraphQL API uses Content-Type for versioning, e.g. the client requests 'application/rescomms-0.11.0+json' (or a few API versions), and when the API has been bumped to e.g. application/rescomms-0.12.0+json, the server will reply with 406. I noticed GraphQL Yoga uses 'application/graphql-response+json', which is referred to in useResultProcessors and processRegularResult.

While it might be possible to create a totally custom result processor, we believe the default request processor would be fine for our use. Would it perhaps be possible to override the default 'application/graphql-response+json' with a custom result that useResultProcessors and processRegularResult uses?

Describe the solution you'd like

Provide default media types through Yoga constructors, and these would be used in place of with hard-coded defaults, e.g.

const yoga = createYoga({ mediaTypes: ['application/json', 'application/rescomms-0.11.0+json'] })

Describe alternatives you've considered

I believe an alternative to this would be a custom request processor, yet I did not manage to write one yet. It seems the helpers for e.g. stringifying JSON, error handling etc. were out of reach, as they were not part of public API.

Additional context

ardatan commented 7 months ago

https://github.com/dotansimha/graphql-yoga/pull/3219/files I created an example for you. But later, I guess we should document it.

laurisvan commented 7 months ago

@ardatan Thanks, this works like charm (yet the list on accepted content types is wrong in regular.js in case of content type failure). My migration to yoga (from fastify + graphql-helix) is not yet complete, but I believe this will work.

In order to include processRegularResult, I needed to patch the index files to export - that will likely be needed in order the example to be usable.

Vince-Smith commented 1 day ago

Running into the same issue... any way to achieve this without patching the dependency to expose processRegularResult?