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
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
not exactly - for long-lived sessions this issue could be hit. server components actually do a decent bit to help though
fair point
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
main thing is the api version
yeah ig u gotta either have strict versioning or just be careful
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
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)
you can version manually
(Not that I’m thinking of versioning trpc apis for my use case, I’m just interested in hearing peoples thoughts)
someRouter.v1.someOperation.useQuery()
versioning is a pain in every situation
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!
versioning with /v1, /v2, /vn has always been a "easy" fix for different versions of the same api