gqtx VS graphql-helix

My favorites are Pothos and gqtx. In terms of documentation and adoption Pothos definitely wins over gqtx. You might also want to check out the "I'm struggling to find proper Graphql Stack" Reddit thread.

By now you get a lot of typesafety without the need to write any types manually or having to generate them on the on the server by using https://github.com/sikanhe/gqtx

There are multiple ways available of constructing a graphql schema. Usually, you can break down those into "SDL" First and "Code" First. A simple example of a Code First approach is the programmatic graphql.js API using `new GraphQLObjectType`. You define your schema with code. In an SDL First approach, you write your schema in the GraphQL SDL (as text) and define a resolver map. You can find some examples over here: https://graphql.org/graphql-js/constructing-types/ A lot of tooling has emerged of those two methods of building GraphQL schemas and you usually have to choose whether you wanna stick to Code First or SDL First. Tools like gqtx (https://github.com/sikanhe/gqtx), giraphql (https://github.com/hayes/giraphql), and nexus (https://github.com/graphql-nexus/nexus) are built around the Code First approach and improve the developer experience over the programmatic API form graphql.js by providing a more type-safe API when utilizing TypeScript. They ultimately all do the same, with slightly (more or less opinionated) different APIs. On the other hand tooling for SDL has also evolved. graphql-tools provides a more advanced interface over how you define the resolvers map and a lot of utilities for constructing your schema from SDL/resolver map partials distributed across different files (https://www.graphql-tools.com/docs/generate-schema/). Together, with graphql-codegen resolver type generation (https://www.graphql-code-generator.com/docs/plugins/typescript-resolvers) you can bring this to the next level if you are working with TypeScript and generate fully typed resolvers from the GraphQL SDL. You have to find out for yourself which approach is best suited for you. I have been using both on different projects and they both have benefits and trade-offs. My opinion is mostly based on the TypeScript developer experience. Code First seems to be the better pick for me if you have lots of computed fields that cannot be mapped 1:1 to the data sources, where you would have to add a lot of type resolver mappings configuration for codegen. With SDL I like that I have the feeling that I can write the schema faster and less clumsy, and the SDL is immediately readable. On Code First you, however, can still generate an SDL file from the coding schema. Maybe there is a niche open for an approach that combines Code and SDL First approaches. We will have to see what the future brings. Here are some more articles/threads regarding the topic: https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3 https://www.reddit.com/r/graphql/comments/fpkx7a/codefirst\_vs\_schemafirst\_development/ https://blog.logrocket.com/code-first-vs-schema-first-development-graphql/ Also, note that most GraphQL server/transports do or should not care about the way you construct your schema. E.g. the apollo-server docs show you only an SDL first way of constructing the schema (https://www.apollographql.com/docs/apollo-server/schema/schema/), but it is also possible to provide a schema instance(https://www.apollographql.com/docs/apollo-server/api/apollo-server/#schema). apollo-server defaults to advocating creating a schema with SDL (by using an old graphql-tools@4 version under the hood).

Tools like gqtx (https://github.com/sikanhe/gqtx), giraphql (https://github.com/hayes/giraphql), and nexus (https://github.com/graphql-nexus/nexus) are built around the Code First approach and improve the developer experience over the programmatic API form graphql.js by providing a more type-safe API when utilizing TypeScript. They ultimately all do the same, with slightly (more or less opinionated) different APIs.

If I can give you an additional tip: Think twice whether you actually need apollo-server. All you need is a way of constructing a schema, which you can either do with the graphql.js programmatic API, graphql-tools (https://www.graphql-tools.com/docs/generate-schema/), or type-safe code first schema builders such as https://giraphql.com/ or https://github.com/sikanhe/gqtx

You will also have to figure out which schema generation flow suits you best. E.g. you can use the programatic API from graphql-js, makeExecutableSchema from graphql-tools https://www.graphql-tools.com/docs/generate-schema/ or code schema builders like https://github.com/sikanhe/gqtx or https://github.com/hayes/giraphql

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