This repository was archived by the owner on Mar 20, 2023. It is now read-only.
This repository was archived by the owner on Mar 20, 2023. It is now read-only.
Middleware refactor #675
Open
Description
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 (Request: Batch Client Query #428)
- Subscriptions (Subscriptions support #390)
- @defer and @stream directives (Support for experimental @defer & @stream #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 (feat: add fragments server side #575)
- Caching (Is caching not supported? #561)
- Returning the response in some format other than JSON (Allow usage of formats other than JSON? #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?
Metadata
Metadata
Assignees
Labels
No labels