5 ms·

I'm a big fan of tRPC. It's amazing how it pushed TypeScript only stacks to the limit in terms of DX. Additionally, it made the GraphQL community aware of the l

I'm a big fan of tRPC. It's amazing how it pushed TypeScript only stacks to the limit in terms of DX. Additionally, it made the GraphQL community aware of the limitations and tradeoffs of the Query language. At the same time, I think tRPC went through a really fast hype cycle and it doesn't look like we're seeing a massive move away from REST and GraphQL to RPC. That said, we see a lot of interest in RPC these days as we've adopted some ideas from tRPC and the old NextJS. In our BFF framework (https://wundergraph.com/ https://wundergraph.com/) we've combined file based routing with RPC. In addition to tRPC, we're automatically generating a JSON Schema for each operation and an OpenAPI spec for the whole set of operations. People quite like this approach because you can easily share a set of RPC endpoints as an OpenAPI spec or postman collection. In addition, there are no discussions around HTTP verbs and such, there's only really queries, mutations and subscriptions. I'm curious what other people's experiences are with GraphQL, REST and RPC style APIs? What are you using these days and how many people/teams are involved/using your apis?

c-hendricks 3y ago
> it made the GraphQL community aware of the limitations and tradeoffs of the Query language Could you expand on that? Our graphql types are generated from our federated schema whenever it changes, and response types for queries / mutations are generated whenever you save a file.
- jensneuse 3y ago
  With tRPC and similar frameworks, you infer client types from server definitions without including actual server code into the client. As much as I like GraphQL, one thing that IDEs really suck at is recognizing when generated code changes. E.g. with Jetbrains IDEs it sometimes takes forever until a change to the generated code is actually picked up by intellisense. VSCode is a little bit better regarding this. When you infer types in tRPC style, this whole problem is gone. You can even jump between the client usage and the server implementation. That said, this is not without a cost. Large Typescript codebases can slow down the typescript autocompletion and this approach only works best when both client and server are written in typescript and ideally in the same codebase.
  - c-hendricks 3y ago
    Hm, yeah I don't think we had similar experiences with GraphQL then > you infer client types from server definitions without including actual server code into the client Our types are generated into their own package, so there's no chance of importing server code.
ushakov 3y ago
Garph is like tRPC but for GraphQL: https://garph.dev https://garph.dev For REST APIs there's ts-rest (https://ts-rest.com https://ts-rest.com), zodios (https://www.zodios.org https://www.zodios.org) and Hono (https://hono.dev https://hono.dev) If your team uses multiple languages, there's Fern: https://www.buildwithfern.com https://www.buildwithfern.com
- cassepipe 3y ago
  +1 for ts-rest The people on the Discord are very helplful https://ts-rest.com/docs/comparisons/rpc-comparison https://ts-rest.com/docs/comparisons/rpc-comparison
cjblomqvist 3y ago
The thing that always strikes me is that verbs and paths are pretty tiny details (and also easy to abstract away using endpoint consumer generation libs) - then what else do you really get compared to your normal average web api? You still need to perform everything in each call to the backend anyway.

c-hendricks 3y ago

> it made the GraphQL community aware of the limitations and tradeoffs of the Query language Could you expand on that? Our graphql types are generated from our federated schema whenever it changes, and response types for queries / mutations are generated whenever you save a file.

jensneuse 3y ago
With tRPC and similar frameworks, you infer client types from server definitions without including actual server code into the client. As much as I like GraphQL, one thing that IDEs really suck at is recognizing when generated code changes. E.g. with Jetbrains IDEs it sometimes takes forever until a change to the generated code is actually picked up by intellisense. VSCode is a little bit better regarding this. When you infer types in tRPC style, this whole problem is gone. You can even jump between the client usage and the server implementation. That said, this is not without a cost. Large Typescript codebases can slow down the typescript autocompletion and this approach only works best when both client and server are written in typescript and ideally in the same codebase.
- c-hendricks 3y ago
  Hm, yeah I don't think we had similar experiences with GraphQL then > you infer client types from server definitions without including actual server code into the client Our types are generated into their own package, so there's no chance of importing server code.

ushakov 3y ago

Garph is like tRPC but for GraphQL: https://garph.dev https://garph.dev For REST APIs there's ts-rest (https://ts-rest.com https://ts-rest.com), zodios (https://www.zodios.org https://www.zodios.org) and Hono (https://hono.dev https://hono.dev) If your team uses multiple languages, there's Fern: https://www.buildwithfern.com https://www.buildwithfern.com

cassepipe 3y ago
+1 for ts-rest The people on the Discord are very helplful https://ts-rest.com/docs/comparisons/rpc-comparison https://ts-rest.com/docs/comparisons/rpc-comparison

cjblomqvist 3y ago

The thing that always strikes me is that verbs and paths are pretty tiny details (and also easy to abstract away using endpoint consumer generation libs) - then what else do you really get compared to your normal average web api? You still need to perform everything in each call to the backend anyway.