3 ms·

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 pa

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 https://github.com/stepci/garph (disclaimer: I'm author of Garph)

thdxr 4y ago
took a quick look - does this differ meaningfully from pothos?
- ushakov 4y ago
  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
noughtme 4y ago
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.
- ushakov 4y ago
  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!
arnorhs 4y ago
This sounds pretty slick. I need to give this a try
satvikpendem 4y ago
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?
- Wissmueller 4y ago
  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.
  - satvikpendem 4y ago
    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)?
    - ushakov 4y ago
      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)

thdxr 4y ago

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

ushakov 4y ago
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

noughtme 4y ago

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.

ushakov 4y ago
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!

arnorhs 4y ago

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

satvikpendem 4y ago

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?

Wissmueller 4y ago
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.
- satvikpendem 4y ago
  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)?
  - ushakov 4y ago
    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)