I remember seeing graphql-jit on a comparative benchmark of GQL server implementations, and it blowing everything out of the water, really impressive:<p><a href="https://github.com/benawad/node-graphql-benchmarks" rel="nofollow">https://github.com/benawad/node-graphql-benchmarks</a><p>Depending on your usecase, you can go one level further and directly evaluate the query AST without delegating to resolvers.<p>(This generally only makes sense if you do programmatic schema generation. IE, read some metadata about a source and then generate GQL types/operations from it.)<p>So a query comes in, say something like:<p><pre><code> query {
users(where: { name: { like: "foo" } }) {
id
email
todos(where: { completed: { eq: true } }) {
description
}
}
}
</code></pre>
Rather than having resolvers, and firing the "users" and "users.todos" resolvers, you interpret the AST of the query directly as if it were a regular value<p>In the case of a SQL database, you'd have a recursive function that takes a level of the query AST and generates a SQL string. Then you'd execute the query, format the results, and return it to the client.<p>IE, in this case you'd probably generate something like<p><pre><code> SELECT id, email, JSON_OBJECT('todos', ...) AS todos
FROM users JOIN todos ON todos.user_id = users.id
</code></pre>
As far as the client can tell, it's a "regular" GraphQL server, but the serverside implementation doesn't have any kind of real executable schema. It just behaves like it does.<p>The downside of this approach is that you lose the ability to use built-in functionality for things like tracing, query depth/complexity limiting, etc. You'd have to write this on your own.