Consider using fastify-gql

[kripod]

According to recent benchmarks done by Ben Awad, migrating to fastify-gql+graphql-jit could result in a 4x performance improvement.

[jasonkuhrt]

We’d mused about looking into this generally (other servers) but no issue/research yet. Thanks for kicking this off!

[jasonkuhrt]

CC @mcollina 🙌

[jasonkuhrt]

• Serverless is something we think is important, so this was interesting to see:

  Fastify is not designed to run on serverless environments. The Fastify framework is designed to make implementing a traditional HTTP/S server easy. Serverless environments requests differently than a standard HTTP/S server; thus, we cannot guarantee it will work as expected with Fastify. Regardless, based on the examples given in this document, it is possible to use Fastify in a serverless environment. Again, keep in mind that this is not Fastify's intended use case and we do not test for such integration scenarios.

  https://github.com/fastify/fastify/blob/master/docs/Serverless.md#attention-readers

• What do we lose by not being built on top of express? In particular, the community of middleware?

• Ben already rolled his own taking inspiration from fastify-gql to make express-gql. No surprise his claimed motivation was that he was using some express middleware

• We should make a perf baseline so that we can measure the impact of whatever change we make.

[mcollina]

Please check out https://github.com/fastify/aws-lambda-fastify#%EF%B8%8Fsome-basic-performance-metrics. All of this means that Fastify has a worse cold start time than express, while it provides better runtime performance (which is significant even on lambda).

I would also add that the caching technique in fastify-gql relies heavily on in-process caching to achieve maximum throughput. In-process caching is against the lambda philosophy, and as a result the benefit of something like graphql-jit are minimized.

[Weakky]

I think what this issue outline is that we definitely need a concept of plugins for servers. We will not fulfill everyone's requirements regardless of what we choose. We already see three different use-cases/motivations:

• Performance (fastify)
• Ease of use (compatibility with express middlewares & or apollo-server plugins)
• Lambda

There's a couple of options for us as to what we choose by default (assuming we come up with a plugin system to support any graphql server). My suggestion would be to bundle by default a server that has the best ratio performance/bundle size. And for that, I think using something "minimal" like graphql-express is our best shot. WDYT?

[jasonkuhrt]

About:

What do we lose by not being built on top of express? In particular, the community of middleware?

Well: https://github.com/fastify/fastify/blob/master/docs/Middleware.md

Fastify provides an asynchronous middleware engine out-of-the-box, which is compatible with Express and Restify middleware.

Later, expected:

Express modifies the prototype of the node core Request and Response objects heavily so Fastify cannot guarantee full middleware compatibility. Express specific functionality such as res.sendFile(), res.send() or express.Router() instances will not work with Fastify. For example, cors is compatible while passport is not.

I find this interesting as more a point for our own abstraction on the question of if we use fastify or not. See #295