Hacker News Reader

Comment by ushakov | Hacker News Reader

If you want tRPC-like developer experience but prefer GraphQL, I can recommend Garph

You get all the benefits of tRPC and all the benefits of GraphQL in one package. Garph can also be used to replace graphql-codegen in your stack with statically inferred types

https://github.com/stepci/garph

(disclaimer: I'm author of Garph)

View on HN

I use GraphQL for disparate clients talking to the server, it's agnostic to the backend and frontend languages. If Garph is already in TS, why would I use it instead of tRPC? I guess if I have a non-TS frontend such as a Flutter app?

Perfect use-case for Garph:

You have a TypeScript backend and TypeScript frontend and want to expose the GraphQL API to third-party consumers or add a mobile app into the mix

And since Garph produces a spec-compatible GraphQL API you can use it with existing tools like Hasura, Apollo, Stellate, AWS AppSync, etc.

Makes sense, so if I already have a tRPC application, what's the transition like to Garph? Or do I need to have it already in Garph when first starting out (ie hard to transition)?

Depends on your application size. The hardest part to transition will probably be the client

We will provide a migration path in our documentation and build some utilities to automate the work required. You can join our Discord to get an update when we have something to share (linked in the repo)

Hmmm... interesting. Was this intended for public APIs? I think the whole point of tRPC is to reduce the overhead down to zero, since this is only for internal APIs.

Yes!

tRPC is a great choice if you want to call server functions from the client without overhead in a type-safe way. However, with React Server Components, I doubt you will need tRPC for this use-case anymore

Our concept was: take the amazing developer experience and end-to-end type-safety of tRPC but give you an actual, spec-compatible GraphQL API, that you can expose and others can use and that also works with existing GraphQL tools

This is how Garph was born!

This sounds pretty slick. I need to give this a try

took a quick look - does this differ meaningfully from pothos?

Great question, happy to answer!

There are a couple of differences: Garph is easier to use than Pothos, Garph fully supports circular references (no workarounds!) and Garph solves type-safety for clients without the need for code-gen. We also offer a compatible client for React/Next.js based on GQty (formerly GQless) for the best experience

Pothos is great for backend-only applications and if you need advanced features such as Relay right now. Garph is great if you want the best possible developer experience and type-safety on both ends of your stack

Reply on news.ycombinator.com