flexible tRPC - is it as flexible as GraphQL?
airbnb and graphql had the problem to have scalable APIs that can grow, are flexible and are backward compatible
graphQL solves this problem, so lets say we have something like this:
now I can grow add other relations to my persons, without breaking my code, so persons can have addresses, bank accounts, children, cars, bought products
how does tRPC grow that way
how does tRPC is telling you how to have flexible interface?
31 Replies
tRPC is not that flexible, the point is you define your endpoints and then it's rock solid and you have upmost type safety without code gen and validation of inputs through the use of Zod.
sure, so the mistake in my thinking is that I think about tRPC as an public API, right?
tRPC is a tool
You setup endpoints between apps and share types without codegen
but in tRPC you have to think what you need and what you want to render, everything else is implementation details that you not make public for others like a public graphql or rest api, correct?
I'm not sure what you mean by that exactly, but yeah, it's mostly intended for intern communication, you can use it for public api's too with trpc-openapi
let me rephrase:
in REST you have an endpoint and you know that many people are using it, so you have to think twice how to define it
if you want changes with a breaking nature, you can use tricks like versioning, so you have something like
www.abc.com/api/version2/users
But in tRPC you do not think in terms like being stable or care about breaking changes
you can break it and tRPC will tell you if your frontend can not deal with it
long story short: tRPC is not about flexibility, tRPC is about a better communication about front end backend for a mono non public api app
agreeing with that ?:)
yes
lets say you can decide to recode airbnb again, would you pick tRPC?
sure
EVEN if you have to support different platforms (android and IOS)?
theres create-t3-turbo atm which is expo and a next app by default with trpc
so sure
if i was building airbnb id probably pick graphql
what do you mean by that ?:)
because it would take a large team to build it
trpc is great when a small team wants to move fast
graphql slows you down in mvp stage due to schema, resolvers, n+1, etc
in my defense he said if
i
had to build airbnb
@cje that would be my next question
how do you work with tRPC in a team?
(a team with a mono repo in general)
if its a small team with a monorepo, you... just work with it?
idk what you want to know
if i had to build airbnb alone, id give up
@barry can you rephrase your create-t3-turbo answer again, and what you wanted to emphasize with it?
you can consume trpc from multiple frontends
for example a next.js frontend and a react native frontend
You seemed to imply it wasn't possible, so I just said how I would do it
@cje if you are in a team, you have many moving parts and I do not see how tRPC can hold everything together and setting the contracts that nobody can break
if someone breaks the contract, the build step fails
so as long as you have ci set up, you cant merge anything that breaks the contract
@barry what can create-t3-turbo do what create-t3-app can not?
theyre both just templates
It's just a "template" for a monorepo version of a t3-app
isn't tRPC all about mono repo by default/design?
create-t3-app isn't
run both and take a look at them
ohh, so create-t3-app is just the server, without any frontend
no
create-t3-app is a scaffolding cli which generates some various templates based on your choices