nexus VS pothos

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 you want in-dept examples of plugins in nexusjs, I suggest that you have a look at how the default plugins are written here.

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.

I noticed this being shared around on Twitter the other day - pretty handy, as I'm currently trying to architect a similar experience for my job using Pathos and graphql-codegen.

- tRPC

But I'd likely throw out Clerk a cheaper option:

- Supertokens, and also since Supertokens is easy (lots of enthusiastic reports about it), has a managed solution (which is cheaper than the alternatives), is secure and scalable (rotating refresh tokens with JWTs), open source, has magic links, and the architecture of Supertokens would allow me to simply and quickly eject to self-hosting it if/when I'd eventually need to (if the app ever reaches mass-market scale).

And I might throw out tRPC for the equivalent GraphQL experience (esp. if business strategy dictates I need a 3rd party API):

- GQty.dev on the client, for inferred queries/mutations. For rapid dev speed. Simple code example: https://gqty.dev/docs/intro Then move to URQL or Relay at scale, or just skip GQty and go with URQL from the start (if scalability trumps dev speed).

- Pothos http://pothos-graphql.dev on the server, for auto building the schema from your TS code (aka. code-first). Better than Nexus (e.g. Max Stoiber moved from Nexus to Pothos on his Bedrock starter template because Pothos is best in class: https://bedrock.mxstbr.com/tools/pothos/ ).

And I might throw out NextJS (Webpack) for the equivalent experience in Vite:

- vite-plugin-ssr, since both architectural control (libraries > frameworks) and Vite rocks. I'd likely then have to make solito-vite https://github.com/nandorojo/solito/discussions/157 to have a unified navigation between React Native and Web, but Solito is allegely tiny, so recreating it should be doable.

(If doing all of these replacements, maybe starting from scratch would be easier than modifying create-universal-app ... That said, I think if someone made a starter repo with the above choices it would be a real killer!)

Then I'd also likely use:

- Vercel (and try their Edge Functions, for a serverless sweet v8 isolates experience without slow cold starts), or maybe Cloudflare Workers (cheaper, slightly more hassle?) for hosting.

- Planetscale or Supabase for the DB. (Not brave enough to try EdgeDB or SurrealDB just yet, though EdgeDB is close..) Unless I had a specific use case where a more specialized/optimized DB would make sense.

This stack should stick even post-MVP, as it's not only optimized for a solo developer but for scalability.

Have you used Pothos? It's a way to make GraphQL schemas in TypeScript, in a type-safe way. So the creator of Prisma Client Rust is thinking about making a Pothos-style API based on the t builder pattern:

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

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).

Pothos is a breeze of fresh air when it comes to building GraphQL APIs. It is a library that lets you write code-first GraphQL APIs with an emphasis on pluggability and type safety. And it has an awesome Prisma integration! (I am genuinely excited about this one, it makes my life so much easier.)

In today's article we are going to create a GraphQL api using the Koa framework together with the GraphQL Yoga library and Pothos. In addition, we will use Kysely, which is a query builder entirely written in TypeScript.

If you're a GraphQL developer, Pothos is the best example - all your user-defined types just fits in it like a glove 99% of the time. It definitely makes the most use of TS generics.

https://pothos-graphql.dev/

(I'm a bit sleepy, so this is the main one I can think of at the moment that I really enjoy using.)