Hey Alex, I had the luck to learn about tRPC directly from you when working at an open source company that used it for a while.
I quite remember tRPC being the only unknown part of the stack when I started there, and I was a bit scared, but tbh it was pretty easy to pick up and it's an awesome abstraction to make the server of fullstack codebases in typescript.
I always liked GraphQL but if you're working solo it doesn't make that much sense to have the GraphQL api as contract. With external devs a little bit more.
+1 to OpenAPI and being able to generate code, SDK's, docs, automagically.
Hey dude! We met in the prisma conf in Berlin a couple of years ago and had some beers after with an Aussie dude, since then I’ve used nothing but tRPC in all of my projects and couldn’t be happier, thanks for the hard work!
One big difference in philosophy here is that tRPC is not designed to be used for cases where you have third party consumers. It's built for situations where you control both ends. (That said, you can use trpc-openapi for the endpoints that are public)
On versioning: it's 2023 & in most cases, you can solve versioning in other ways than maintaining old API versions indefinitely. For RN there's OTA, for web you just need to reload the page or "downgrade" your SPA-links to a classic link to get a new bundle (did an example here https://twitter.com/alexdotjs/status/1627739926782480409)
Also, we'll release tooling to help keeping track of changes in cases where you can't update the clients as easily.
GraphQL is amazing but it isn't a silver bullet either, it has its own complexity that you have to accept as well.
> On versioning: it's 2023 & in most cases, you can solve versioning in other ways than maintaining old API versions indefinitely. For RN there's OTA, for web you just need reload the page or "downgrade" your SPA-links to a classic link to get a new bundle (did an example here https://twitter.com/alexdotjs/status/1627739926782480409)
I would suggest you think more deeply about this problem.
In all the examples you listed there is a population on the new version and the old version, even in the happy case. Distributed systems are not instant, and changes take time to propagate. Publishing a new version of your website / RN bundle to a CDN does not mean all edge locations are serving it. Long lived single page applications (Gmail for example) are not typically refreshed often. For small applications, this may not be an issue -- when your scale is millions of users, the population that now receives a 500 due to a bad request is significant, even if it's seconds or minutes where clients access both versions, but the backend only supports the latest version.
> Also, we'll release tooling to help keeping track of changes in cases where you can't update the clients as easily.
The ease of updating the clients doesn't solve this issue, and avoiding leaking it into your framework because it's messy or introduces constraints won't make it go away.
Thanks for the input! We have thought about it a lot.
The biggest challenge with trpc right now is that the API is transient so it's not obvious when you might be braking clients in flight and that you often can't guarantee perfect sync of deployments as you're rightly pointing out.
Once we have some more tooling around it, you'll be able to get the benefits of a traditional API where you consciously choose when to break the spec, but with the productivity benefits of not having to manually define it. I think that will scale pretty well.
> One big difference in philosophy here is that tRPC is not designed to be used for cases where you have third party consumers. It's built for situations where you control both ends. (That said, you can use trpc-openapi for the endpoints that are public)
I'm a happy tRPC user, and this is my use case. Our web application has no client other than our web frontend. I can't see a situation when it would (and I would bet this is true for most web applications), so I am very happy with how tRPC has worked out.
I did recently create a more limited data API, and for that I used express-zod-api [0] which I like very much.
Unless I'm missing something, Blitz RPC add's zero TS overhead. So the limitation will be the total amount of TS code you have which is not related to Blitz.
- The ts perf things that set trpc apart and make you feel it earlier in tRPC than blitz are largely resolved by the new major of trpc that is currently in a stable alpha (stable in terms of no known bugs, but API might change)
Would that help your team?
Happy to give you a demo if you reach out on Twitter dms or email (alex@trpc.io)