express-graphql
express-graphql copied to clipboard
Published
20 hours ago •
graphql
graphql
Middleware refactor
I'm opening this issue so we can further discuss approaches to A) splitting the middleware into separate functions and B) supporting additional frameworks. Here are some initial thoughts:
Goals
- Provide reference implementation of GraphQL over HTTP spec
- Support a wider range of HTTP frameworks
- Empower consumers of the library to more easily hook into the different parts of the “request pipeline”
Questions
- Which HTTP libraries, frameworks or services do we want to explicitly support?
- https://www.npmjs.com/package/express
- https://www.npmjs.com/package/connect
- https://www.npmjs.com/package/restify
- https://www.npmjs.com/package/@hapi/hapi
- https://www.npmjs.com/package/koa
- https://www.npmjs.com/package/fastify
- https://www.npmjs.com/package/micro
- https://www.npmjs.com/package/sails
- https://www.npmjs.com/package/adonis-framework
- https://www.npmjs.com/package/derby
- https://www.npmjs.com/package/socket.io
- https://www.npmjs.com/package/ws
- https://www.npmjs.com/package/aws-lambda
- Azure Functions
- Google Cloud Functions
- https://deno.land/x/oak
- Note: For serverless environments, it may be possible to just use a existing framework like express and wrap it so explicit support for serverless may not be necessary
- What features do we want to eventually support? Any potential changes to the API should be considered in the context of these features’ eventual implementation.
- Request batching (https://github.com/graphql/express-graphql/issues/428)
- Subscriptions (https://github.com/graphql/express-graphql/issues/390)
- @defer and @stream directives (https://github.com/graphql/express-graphql/pull/583)
- Some features should not necessarily be a part of this library, but we want to empower the community to easily create middleware to implement them.
- Server-side fragments (https://github.com/graphql/express-graphql/issues/575)
- Caching (https://github.com/graphql/express-graphql/issues/561)
- Returning the response in some format other than JSON (https://github.com/graphql/express-graphql/issues/556)
- Custom error handling
- Persisted queries
- Tracing
- Logging
- File upload
- What steps in the “request pipeline” should be split into individual middleware?
- Parse
- Validate
- Execute
- Format response
- How do we persist state between middleware? For example, does each supported framework allow us to arbitrarily mutate the incoming request object?
- How do we account for differences between frameworks?
- Publish individual sets of middleware for each support framework
- Create a generic interface (like this library does)
- How do we account for shared configuration between the different middleware?
- Would it make sense to have a single function that accepts the shared config and then returns a set of middleware functions or middleware generator functions?
I'd like support for curveball: https://www.npmjs.com/package/@curveball/core
I proposed rearchitecting and creating middelwares like these years ago but @IvanGoncharov was against the idea
