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)
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.
- 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 ([email protected])