graphql-helix VS graphql-jit

Depends on language, I've build GraphQL servers in a few, though mostly JavaScript and Python. For Python I used to use Graphene, these days I use Strawberry.

For JavaScript, I originally used graphql-js and express-graphql, as these were the original libraries and I was a literal day 1 adopter. All the libraries are essentially just wrappers around graphql-js, so it's still viable to use directly. But for schema-building I now use Pothos (https://pothos-graphql.dev/), I'd probably use graphql-helix as the http layer (https://github.com/contra/graphql-helix).

If you want a lower level graphql server https://graphql-helix.vercel.app/ or https://benzene.vercel.app/ might be worth checking out.

While there are many GraphQL server packages available, we need one that will play nicely with Nuxt3's server engine (Nitro / h3). In the spirit of keeping things extensible and framework-agnostic, GraphQL Helix seems like a really good choice. Let's add it to our project:

Looks interesting, have you tried graphql-helix?

When using a JavaScript server, a convenient way to achieve this is with GraphQL Helix, which decouples the handling of the HTTP request from the GraphQL server. With Helix, we can have the routing logic be handled by a Node.js web framework (such as Express.js or Fastify), and then — depending on the requested path (i.e., the requested endpoint — we can provide the corresponding schema to the GraphQL server.

GraphQL Helix is a framework and runtime agnostic collection of utility functions for building your own GraphQL HTTP server. Instead of providing a complete HTTP server or middleware plugin function, GraphQL Helix only provides a handful of functions for turning an HTTP request into a GraphQL execution result. You decide how to send back the response.

import { envelop, useSchema, useLogger } from '@envelop/core'; import fastify from 'fastify'; import { processRequest, getGraphQLParameters } from 'graphql-helix'; // This creates the `getEnveloped` function for us. Behind the scense the wrapped functions are created once, here. const getEnveloped = envelop({ plugins: [useSchema(schema), useLogger()], }); const app = fastify(); app.route({ method: ['POST'], url: '/graphql', async handler(req, res) { // Here we can pass the request and make available as part of the "context". // The return value is the a GraphQL-proxy that exposes all the functions. const { parse, validate, contextFactory, execute, schema } = getEnveloped({ req, }); const request = { body: req.body, headers: req.headers, method: req.method, query: req.query, }; const { operationName, query, variables } = getGraphQLParameters(request); // Here, we pass our custom functions to Helix, and it will take care of the rest. const result = await processRequest({ operationName, query, variables, request, schema, parse, validate, execute, contextFactory, }); if (result.type === 'RESPONSE') { res.status(result.status); res.send(result.payload); } else { // You can find a complete example with Subscriptions and stream/defer here: // https://github.com/contrawork/graphql-helix/blob/master/examples/fastify/server.ts res.send({ errors: [{ message: 'Not Supported in this demo' }] }); } }, }); app.listen(3000, () => { console.log(`GraphQL server is running...`); });

Fortunately, we now have libraries like Graphql Helix, which, in my humble opinion, should replace express-graphql as the reference HTTP implementation since GraphQL Helix is also not tied to any web server framework.

If you are using Node.js there are a lot of implementations of GraphQL servers with a few being express-graphql, apollo-server, mercurius, graphql-helix and more. And if you are using other languages, you can see a great list here

Graphql Helix

In the end like all performance questions you'll have to measure it. Persisted queries, and even more extreme approaches, like a GraphQL JIT (https://github.com/zalando-incubator/graphql-jit) can remove a lot of the overhead.

We faced something similar. To improve GraphQL performance, we use graphql-jit. We turned off all other tracing that datadog turns on by default. Then, we then wrote a custom tracer to connect graphql-jit to dd-trace. Hopefully this same pattern works for you!

GraphQL JIT – GraphQL execution using a JIT compiler\ (0 comments)

https://github.com/zalando-incubator/graphql-jit#compile-a-q...

so I guess the difference is instead of having totally generic functions that parse the query every time, instead you can call a factory function up front to get a specialised function for a particular query

and V8 JIT can make that faster

JS has always been special & excellent because it allows multiphase programming. That one coild just add more code has been unique versus the world of statuc languages, where maybe youcd have some tool to generate stubs for Thrift or gRPC, then compule that in to your program. Which works ok, if and only if you know ahead of time what schemas you might need. Im these cases, you have to give up on stub code & start using more interprtted systems.

The advantages in js have been colossal, often an easy order of magnitude win to compile selectors & queries & other fast inner loop bits into jit compiled code versus having userland interpretters. Some of thd rete engines enjoy this. Just today there's graphql-jit. https://github.com/zalando-incubator/graphql-jit/blob/main/s...

Everything you say is full of doubt & scorn & skepticism. I just cant imagine living im such a world where each system had to know fully well ahead of time each type of data it might want to interact with, might have to have that precompiled & baked in. Thatcs a shitty miserable world that looks like the hell JS plucked us out of, by being a flexible, dynamic language that could load in routines & change it's behavior over time. Screw that dark hell world.

By using useParserCache we make sure to parse every unique operation only once. By using useValidationCache we make sure to validate every unique operation only once. By using useGraphQLJit we replace the default execute function with a just-in-time implementation.

One thing to understand is that, if you are using Node.js graphql-js would typically be the underlying implementation of all libraries and ultimately everything would get converted to JS/TS objects typically an AST ultimately making all these as abstractions on top of the existing way to define schemas. Note that the implementation can differ a bit in other languages or even within Node.js if you are using other ways of implementation like graphql-jit

Could you provide more context? the GraphQLJit plugin is a lightweight wrapper around graphql-jit. Could you share your previous datadog/graphql setup? Would love to dig in and find a proper solution!

Customizable runtime. Use custom GraphQL implementation such as graphql-jit or rolling our own for performance and cutting-edge features.