graphql-js VS TypeGraphQL

To begin, I'm going to start with GraphQL. This repo is a JS-specific implementation for GraphQL, for which projects written in JS/TS can utilize to build an API for their web app. The reason why I chose this project is because I've always been intrigued by how GraphQl challenges the standard way of building an API, a.k.a REST APIs. I have very little knowledge about this project since I've never used it before at work or for my personal projects. I only have theoretical knowledge about it which I gained from watching YouTube videos. It also uses TypeScript which is fascinating because type safety is very important when building software considering it cleans out a lot of bugs early on before the software is shipped.

When I asked this in StackOverflow over a year ago I reached the solution of using graphql + graphql-zeus.

In short, we chose not to pursue GraphQL due to some limitations with union types and a lack of support for maps. This is further detailed in this link: limitations.

benchmarks: This directory contains benchmark tests that help measure the performance of the package's code, these tests can be are very useful when experimenting with performance optimizations, and to ensure no slowdowns are introduced between releases. Example from graphql.

GraphiQL (and many other tools) relies on introspection query which AFAIK is not guaranteed to have any specific order (and many libs don't support it). Apollo Server is built on top of graphql-js and it relies on it for this functionality.

GraphQL.js + Knex.js + knex-types (TypeScript generator for Knex)

Yoga v2 supports some experimental GraphQL features such as @defer and @stream, allowing you to get a taste of the future of GraphQL (with compatible clients such as URQL).

Visitors are used for many reasons like extensibility, plugins, printing an entire schema somewhere, etc.

support for @defer and @stream

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.