TypeGraphQL VS express-graphql

In this tutorial, we're building a simple application which uses Cerbos inside of a GraphQL server. The server is written in typescript and uses type-graphql to create the schema and resolvers, and TypeDI to handle dependency injection.

Using decorators required setting an --experimentalDecorators experimental compiler flag. Several popular TypeScript libraries, such as type-graphql and inversify, rely on this implementation.

TypeGraphQL

Have you tried TypeGraphQL v2 (it's in beta). Some in this thread have reported success with it.

When moving away from Apollo Server, and you're looking for a replacement built with JavaScript or TypeScript, let me give you some options. If you want to keep building your GraphQL API schema first, you might want to consider Mercurius (which relies on Fastify) or GraphQL Yoga. If you're going to build your GraphQL API code or resolver first, have a look at TypeGraphQL or Nexus. Alternatively, there are great GraphQL-as-a-Service solutions such as StepZen in case you no longer want to build, maintain and host your own GraphQL API.

There are two main approaches to keeping the types of the GraphQL schema and entities in business logic in sync. You can generate the schema based on your TypeScript code (e.g. TypeGraphQL), or you can generate types based on your schema (e.g. GraphQL Code Generator). We opted for the latter since it slotted right into our existing GraphQL server implementation using Apollo Server.

I've used tools (e.g. TypeGraphQL) in the past, and for smaller schemas I've just manually written the schema.

I'll be honest and say I don't think python is the right language to implement graphql. It's possible of course and if you're looking for a graphene tutorial, I'm sure you can find one (and I'll help you evaluate one, if you'd like). I'd personally go with node.js, typescript, and typegraphql.

Foal's dependencies have been updated so as to support the latest version of TypeGraphQL.

It looked a little janky but it actually worked fine. But then I needed file uploads. Something graphql-zeus does not support. So I had to create a small wrapper for the SDK created so that it worked. And then also express-graphql, the server I was using, was deprecated.

This seems like a minor deal unless you're not using Express as your web framework. And an important note here is that Express GraphQL is being deprecated by the GraphQL Foundation. So if you're using Express for a GraphQL API, you should move away from it anyway.

You might have seen other GraphQL server solutions where the schema is implemented by using a more programmatic approach. Here is an example of how schemas are implemented using the express-graphql library. (link: https://github.com/graphql/express-graphql)

I'm not sure where the "8MB limit" comes from but, indeed, there are issues like this where, in some implementations, the response size is limited to 100KB: https://github.com/graphql/express-graphql/issues/346

With Node I used express-graphql as opposed to something like Apollo because it's lighter and less heavy on resources compared to Apollo.

Daniel Rearden listed the following reasons pushing him to create Helix, believing that these factors were absent from popular solutions like Apollo Server, express-graphql and Mercurius:

Express GraphQL is a library for building production ready GraphQL HTTP middleware. Despite the emphasis on Express in the repo name, you can create a GraphQL HTTP server with any HTTP web framework that supports connect styled middleware. This includes Connect itself, Express and Restify.

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

express-graphql GitHub Repository

Not sure about other libraries but it's certainly not the case for express-graphql on node.js. You can tie the graphql endpoint to any method you like. On the site I work on, we have a graphql endpoint that only accepts GET requests in production and is thus cacheable by Cloudfront. In dev and staging we accept all requests so that GraphIQL works.