Backwards compatible deployments with trpc?

Throwing this in a thread to see if anyone’s got some opinions on this topic. Due to the zod validation in the trpc handlers, your frontend and backend deployments must always be in sync in order to avoid runtime errors. If you make a breaking change and somehow an outdated/stale bit of frontend code hits a newer deployment of the API, things will break. I feel like this possibility is not often discussed or even encountered as we tend to use trpc with next js and vercel. So coincidentally the frontend and backend deployments stay in sync.
13 Replies
Neto
Neto2y ago
if you are deploying full stack next, then it would be hard to have this issue but for fully separate layers, i don't think there is a way of easily syncing on production
Brendonovich
Brendonovich2y ago
not exactly - for long-lived sessions this issue could be hit. server components actually do a decent bit to help though
Neto
Neto2y ago
fair point
jingleberry
jingleberry2y ago
Why wouldn’t this have the same issue? Consider a user who’s got the page opened for a few days and doesn’t refresh the page. They’d then perform an action but that would be sent to a newer current deployment of the app. Thus validation would fail (assuming it’s evolved without backwards compatibility) I agree though that vercel deployments help alleviate a lot of the issues
Neto
Neto2y ago
main thing is the api version
Brendonovich
Brendonovich2y ago
yeah ig u gotta either have strict versioning or just be careful
Neto
Neto2y ago
if for some reason the code executing on the machine isnt the up to date you have to either block actions or force reload on version diff
jingleberry
jingleberry2y ago
Given the way people use trpc on streams, tutorials etc where they say “oh you can just rename this variable and update it both client and backend” I feel like backwards compatibility is an afterthought when using trpc It doesn’t support api versioning either (I think?) But I guess the point is move fast break things when using this tool (and evolve it to be stable later)
Neto
Neto2y ago
you can version manually
jingleberry
jingleberry2y ago
(Not that I’m thinking of versioning trpc apis for my use case, I’m just interested in hearing peoples thoughts)
Neto
Neto2y ago
someRouter.v1.someOperation.useQuery() versioning is a pain in every situation
jingleberry
jingleberry2y ago
At my work we use graphql and have tooling dedicated to ensure we don’t ever make breaking schema changes. Mainly cos you don’t version graphql apis but rather continuously evolve them Versioning by router looks like a nifty idea though!
Neto
Neto2y ago
versioning with /v1, /v2, /vn has always been a "easy" fix for different versions of the same api
Want results from more Discord servers?
Add your server