TypeGraphQL VS graphql-spec

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.

GraphQL's first draft release was 8 years ago. [1]

It's first non-draft release was 5 years ago. [2]

It's first release under a community foundation was 2 years ago. [3]

[1] https://spec.graphql.org/July2015/

[2] https://github.com/graphql/graphql-spec/releases/tag/June201...

[3] https://github.com/graphql/graphql-spec/releases/tag/October...

I'm a big believer in GraphQL (in fact, at time of writing I'm #2 contributor to the GraphQL spec itself) so it pains me that a tool I built doesn't always have easy ways to achieve the "versionless schema" design that GraphQL encourages when it comes to making significant breaking changes to your underlying database tables. (Personally, I think you should aim for your database schema itself to be versionless, but this is not always possible.) Of course you can build your PostGraphile schema over views instead of tables, but views have their own problems that I won't go into here…

I created a proposal for Map type but didn’t make it through.

https://github.com/graphql/graphql-spec/pull/888

The issue with GraphQL is it tries to appease too many masters.

Similar to jsx. The language isn’t evolving.

The good thing is the spec is (almost) frozen, so there’s many implementations, the bad is it can encompass the flexibility of json schema can do.

Longer thread - Subscriptions RFC: Are Subscriptions and Live Queries the same thing?

https://github.com/graphql/graphql-spec/issues/284

You’ve probably figured it out by now, but for others who may be in a similar position; GraphQL is a specification (with various implementations) and you can read up on the spec here: https://spec.graphql.org/

If you're asking whether GraphQL supports anonymous objects that can be arbitrarily nested then no, it doesn't.

show this feature request some love https://github.com/graphql/graphql-spec/issues/174

* Performance: It's just hard to track down what makes an operation slow. The waterfall nature of resolvers is a big contributor

[1] https://github.com/graphql/graphql-spec/issues/488

:::note GraphQL Union is available for Types only, not for Inputs. However, the oneOf directive will bridge the gap in the future.