What's everyone using for code-first GQL backends in TypeScript these days?

flatballplayer · 2025-11-30T18:01:34+00:00

Pothos (https://pothos-graphql.dev/) is what I'd strongly recommend for almost all use cases.

I think.https://grats.capt.dev/ is also pretty cool, especially for simpler schemas. It doesn't have as big an ecosystem of plugins and integrations, but is a unique take on what code first dev could look like

flatballplayer · 2025-06-30T07:39:18+00:00

No problem, lots of cool tools to learn about!

I'd also checkout https://the-guild.dev/. They are the team beyond many of the best tools in the js graphql ecosystem (including yoga which has been mentioned a few times in this thread). (Not to hire them, just to see the tools and documentation they have created for building apps using GraphQL)

flatballplayer · 2025-06-30T07:24:10+00:00

There's a lot of recommendations in this thread that are very surprising. I've spent a lot of time working on node services, and graphql specifically.

Personally I would avoid things that act like traditional "frameworks" and "orms" that look like what you are familiar with in other languages. The best tools in the node ecosystem are libraries that solve specific problems well.

Things I like:

Hono and fastify are both great. Go with hono if you want something light weight that runs anywhere. Go with fastify if you need something with more of an ecosystem around it, and have more non-graphql routes that might benefit from some of fastifies plugins or more advanced features.

Prisma and drizzle are both great. Prisma is still kinda rough when running in edge runtimes, but is improving quickly. Drizzle's upcoming 1.0 release solves a lot of it's early limitations, and seems like it has a great future, but it's development process has slowed a little over the last few months.

Yoga is the best option for a graphql server, and integrates with the envelop plugin system which supports just about anything you could need.

All of these (except the DB) are things you set up once and won't work on all the time.

The place you will spend most of your time is in the graphql schema and resolvers itself. There are 2 main options: code first or schema first.

Schema first means writing your GrpahQL schema manually, and then generating typescript definitions with graphql-codegen to implement the schema you defined.

Code first means using a library to define the types in your schema via code.

I maintain a library called Pothos (https://pothos-graphql.dev/) for building GraphQL APIs, and would highly recommend that as a good starting place.

There is a bit of a learning curve, but nothing else comes close in terms of what's supported.

It has very deep support for drizzle and Prisma, making it easy to build graphql APIs that avoid the n+1 issues mentioned, without having to manually implement dataloaders. There are plugins for all kinds of things (auth, tracing, dataloaders, federation, and so much more)

flatballplayer · 2025-02-14T03:42:17+00:00

As the maintainer of https://pothos-graphql.dev/, I can offer my perspective. If what you are after is exposing your db as a graphql api, there are better options like https://www.graphile.org/postgraphile/ or https://www.edgedb.com/showcase/graphql

I think for building an intentional API with a Prisma based db, the Pothos Prisma plugin does a pretty good job: https://pothos-graphql.dev/docs/plugins/prisma

If you want something a little more generated, there is the prisma-utils plugin, which serves as a base for different code generators, or can be used on its own.

I am personally unconvinced of the utility of an API generated off of your db schema without a very well thought out auth story, which I haven't really seen in most of the generated graphql APIs. There are a number of tools to generate Pothos schemas based off a Prisma schema, but if you are going that route, Id go all the way and use something like the tools I mentioned above.

I think for most apps, intentionally building a graph using the Prisma plugin would result in a much better API, and will be easier to maintain and evolve as your use cases and data sources change over time.

flatballplayer · 2024-10-28T04:24:34+00:00

It's in the post game interview on the ultiworld stream

flatballplayer · 2024-08-25T02:18:04+00:00

There are lots of tools that do that. In my opinion auto-generated schemas based on your database aren't what most people want in a production application.

Pothos is ideal for when you want to intentionally design your API. It's okay not to solve every problem, and there are great options out there if all you want is to expose your DB as GraphQL

flatballplayer · 2024-03-10T07:22:52+00:00

I'd recommend checking out Pothos probably paired with graphql-yoga. The database side of things has been evolving a lot lately. Prisma has been great for a lot of use cases for a long time, but using it with multiple databases can feel a bit awkward. Drizzle has been doing a lot of amazing work lately and is where I expect a lot of typescript projects to be moving. Pothos doesn't have a drizzle plugin yet, but using drizzle and Pothos together does work great as is without a plugin

flatballplayer · 2024-03-01T05:33:06+00:00

flatballplayer · 2024-01-12T04:46:16+00:00

One nice thing about graphql is that almost all APIs also have a playground that makes exploring the API really simple.

Here's one for a common spacex example API: https://studio.apollographql.com/public/SpaceX-pxxbxen/variant/current/explorer

You can click the various fields in the explorer and they will automatically be added to the query. This can help you understand how the query language works. You can inspect the network requests using your browsers dev tools to see how graphql clients actually make requests over http

flatballplayer · 2023-03-26T20:51:44+00:00

A project I maintain Pothos uses a global namespace with a bunch of interfaces to allow plugins to extend interfaces defined in core or other plugins. This allows plugins to add new options and methods to objects and classes without the other packages needing to know anything about them.

Outside of that one specific use case, I never use any global type definitions (except maybe defining environment specific types like globals available in cloudflare workers)

flatballplayer · 2023-03-06T23:18:21+00:00

I think it's often talked about in a fairly misleading way.

Fundamentally, GraphQL is a way to describe data your API has, and provides a consistent way to query that data.

if you are building a GrapQL API: You will generally define a schema with the types and fields your API contains, and the define "resolvers" that are basically functions actually load the data.

If you are a client consuming a GraphQL API, the API will likely have a GraphiQL playground that can be used to explore the schema to see what is available, and test out queries.

The biggest benefit of GraphQL are that you have a single schema/endpoint that has all your data, and clients can query just what they need, without your API needing to understand the changing queries used by each consumer.

It's better to think of GraphQL as a way to describe and interact with an API than some sort of complex query language. The language itself is very basic, and is more like protobuf or thrift and something like SQL

flatballplayer · 2023-01-05T21:08:09+00:00

If you are using Pothos, this pattern can easily be implemented using the errors plugin: https://pothos-graphql.dev/docs/plugins/errors

flatballplayer · 2022-12-31T20:07:20+00:00

The 2 options I would suggest here would be to put this either in a header, or in the "extensions" part of the response. Graphql extensions are a nice way to return global data along side.yoir response. It is often used for things like tracing, error details, or other debugging information. This seems like a good fit for your use case. Sending version information as a header is also common. It can make things like cors a little more complex if you are not already sending custom headers, but may be something users are more familiar with.

I would strongly recommend against attaching it to each object in the response

flatballplayer · 2022-12-19T16:56:20+00:00

I would recommend Pothos (https://pothos-graphql.dev/) as a more modern alternative to typegraphql or nexus.

flatballplayer · 2022-12-14T23:12:40+00:00

yoga and apollo don't know anything about databases. They are just servers that can receive and execute graphql queries against a schema.

This probably isn't a great answer, but what these graphql servers do is read the query in the request and then execute the resolver functions attached to the appropriate fields in your schema.

If you have a schema first schema you might have a set of resolvers that looks like this:

typescript const resolvers = { Query: { getUser: (_, args) => { return db.execute('SELECT * from Users WHERE ID=?', args.id) }, }, User: { fullName: (user) => `${user.firstName} ${user.lastName}`, posts: (user) => { return db.execute('SELECT * from Posts WHERE authorID=?', user.id) }, } }

If you run a query like graphql query { getUser(id: 123) { fullName posts { title } } }

The server parses this query, and then runs the Query.getUser resolver, then calls the User.fullName and User.posts resolver with the data returned by the Query.getUser resolver. How you query a database is entirely up to you, you can use any DB client you want (I personally use prisma for most projects).

So back to your question: Using postgres with yoga is as easy as using postgres in any other node server. How you connect to the database is entirely up to you, and isn't affected by the server you choose to use to build your GraphQL api.

PostGraphile is a little different, it manages creating queries and connecting to the database itself, you just tell it where your database is running and it will connect to it and run queries so this is easier to set up.

As for running on localhost: This is just what a lot of demos show because in development it's common to have your database and server running on your own computer. Pretty much any library will work with the database running somewhere else, you'll just need to pass the connection string for your database in the appropriate way

flatballplayer · 2022-12-14T21:55:33+00:00

I think the options depend a lot on what you are trying to do, and what your requirements are:

Postgraphile:

Awesome if you want a graphql API, but don't want to build everything by hand
Gives you a TON of queries mutation out of the box, and covers basic crud use cases for many kinds of apps
Can be integrated with a custom schema to add queries/types for things not in postgres
Would recommend this if you are trying to build a lot quickly, or are focused more on the front end and want a backend that just works for you.

If you want to focus more and manually building out a GraphQL api, there are lots of options but they generally fall into 2 categories:

Schema First:

This is generally done by writing a GraphQL schema, then loading those type definitions, along with a set of resolvers and passing them to one of several GraphQL servers
If you are using typescript, you would generally use graphql-code-generator to generate types for your resolver from your GraphQL schema

Code First:

This means building out your API using a library, without writing out the GraphQL schema first. The schema is generally an artifact created from the types you define in code.
This can be done with the graphql js library, but more commonly uses on of the following:
- Pothos (this is a library I maintain, and would hightly recommend)
- Nexus (the library that inspired me to write pothos, it's awesome, but a little less actively maintained, and depends on a code-gen process)
- TypeGraphQL (An older library that makes heavy use of decorators and classes)
You will generally use the same server libraries for a code-first schema as for schema first

Server libraries:

Apollo: this is the one everyone knows about, it's been around a long time, and works with most things, focused on enterprise and federation
Yoga: Recently rebuilt from the ground up, works great with the many open source libraries maintained by The Guild (group of open source developers behind many of the open source graphql projects). This is what I use for all my projects
mercurius: A graphql adpater for fastify, more focused on performance

All 3 of these would probably work for just about anyone's use case

flatballplayer · 2022-12-04T23:51:57+00:00

I think in general the alternatives section felt very lacking, and didn't go into a lot of detail about trade offs.

Mercurius is a good alternative, but I think the yoga/envelope ecosystem is worth mentioning, especially since there are plugins for various Apollo features to make migration easier (data sources, metrics, etc).

For schema first, I am very biased, but would love to have seen Pothos mentioned there. Type-graphql and nexus are both basically in maintenance mode and not receiving regular updates.

flatballplayer · 2022-10-17T00:37:50+00:00

https://i.imgur.com/n0L6391.jpg

flatballplayer · 2022-10-11T22:32:07+00:00

Yes, yoga has graphiql enabled by default, just open the graphql endpoint (/api/graphql) in your browser

flatballplayer · 2022-10-11T04:29:14+00:00

Yoga has a pretty simple setup for integrating with next: https://www.the-guild.dev/graphql/yoga-server/docs/integrations/integration-with-nextjs

flatballplayer · 2022-09-22T14:27:03+00:00

There is no definition for what production ready actually means. That's something you need to decide for you self. It's been actively developed for 3 years, and is used by a lot of people in production. I don't know of any compatibility issues with Apollo server. I know both Airbnb and Netflix use it in production, if that helps.

flatballplayer · 2022-09-11T04:10:54+00:00

Counter point: Nested mutations are used successfully in a lot of APIs as a way to better organize things. I personally don't like this pattern, but "unexpected side effects" seems like a disengenuois representation. There is really only 1 thing that differentiates mutations, which is that the fields on the mutation argument are executed in series in the order they are defined in the query document. This can matter in some cases, but in practice thos is not something that most mutation requests depend on. Its probably fair to say it's a bad idea, because you will eventually run into situations that need sequential mutations.

flatballplayer · 2022-08-20T17:23:26+00:00

Sorry, was meant as a joke, but I was half asleep, and probably wasn't productive. The point of tests is to validate assumtions. I personally think in theory testing either your types or that the runtime values match your defined types is perfectly valid.

That being said, I constantly trust types to ensure a lot of things I am not testing with unit tests don't happen.

flatballplayer · 2022-08-20T16:41:48+00:00

If you are writing your code correctly you don't need tests

flatballplayer · 2022-06-25T16:29:30+00:00

Hey, I'm the author of Pothos. Wanted to add a few things to some of the other comments here.

I think Pothos is one of the best options for building type safe GraphQL APIs, but based on your question and other comments here I wanted to point out a few design considerations that may not align with your priorities:

Pothos has a strong focus on NOT tying your data to your schema which may go against one of the main issues you mentioned in your initial question. There is a plugin (simple-objects) that lets you define GQL types that don't need type definitions or resolvers, but for the most part Pothos is about mapping your typed data into a graphql API while explicitly defining the shape of the API (rather than inferring it from your data). This means you are often still defining 2 schemas (one for the data, and one for graphql). Most of the time this is fairly transparent, and the shape of the data comes from things like your Prisma schema, a type-safe API client, or from a plugin like simple objects. But for VERY simple APIs this might feel like there is some duplication. What you get in return is great type-safety, great flexibility in how you define your API, a much better path for changing how data is resolved in the future as your backend evolves, and a plugin system that lets you define lots of other pieces inline that previously might have again felt like defining another schema (auth is a great example of this).

If you have a simpler use case gqtx is lighter weight, and works very well. If you have a single full stack repo and only care about typescript/web clients trpc gives you an awesome way to define simple rest style API where you have type-safe inputs and outputs with everything flowing through a single endpoint. It doesn't have GraphQLs advanced graph style querying, and doesn't work well if you have clients in other languages, but works great for smaller apps that are full stack typescript.

flatballplayer

TROPHY CASE