Middleware refactor

[danielrearden]

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?

[NetOpWibby]

I'd like support for curveball: https://www.npmjs.com/package/@curveball/core

[acao]

I proposed rearchitecting and creating middelwares like these years ago but @IvanGoncharov was against the idea