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.

Neto•3/26/23, 2:29 AM

if you are deploying full stack next, then it would be hard to have this issue

Neto•3/26/23, 2:30 AM

but for fully separate layers, i don't think there is a way of easily syncing on production

NNeto if you are deploying full stack next, then it would be hard to have this issue

Brendonovich•3/26/23, 2:33 AM

not exactly - for long-lived sessions this issue could be hit. server components actually do a decent bit to help though

Neto•3/26/23, 2:33 AM

fair point

jingleberryOP•3/26/23, 2:33 AM

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)

jingleberryOP•3/26/23, 2:33 AM

I agree though that vercel deployments help alleviate a lot of the issues

Neto•3/26/23, 2:34 AM

main thing is the api version

Jjingleberry Why wouldn’t this have the same issue? Consider a user who’s got the page opened...

Brendonovich•3/26/23, 2:34 AM

yeah ig u gotta either have strict versioning or just be careful

Neto•3/26/23, 2:34 AM

if for some reason the code executing on the machine isnt the up to date

Neto•3/26/23, 2:34 AM

you have to either block actions

Neto•3/26/23, 2:35 AM

or force reload on version diff

jingleberryOP•3/26/23, 2:35 AM

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?)

jingleberryOP•3/26/23, 2:36 AM

But I guess the point is move fast break things when using this tool (and evolve it to be stable later)

Neto•3/26/23, 2:37 AM

you can version manually

jingleberryOP•3/26/23, 2:37 AM

(Not that I’m thinking of versioning trpc apis for my use case, I’m just interested in hearing peoples thoughts)

Neto•3/26/23, 2:37 AM

someRouter.v1.someOperation.useQuery()

Neto•3/26/23, 2:37 AM

versioning is a pain in every situation

jingleberryOP•3/26/23, 2:40 AM

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

jingleberryOP•3/26/23, 2:41 AM

Versioning by router looks like a nifty idea though!

Neto•3/26/23, 2:45 AM

versioning with /v1, /v2, /vn has always been a "easy" fix for different versions of the same api

Backwards compatible deployments with trpc?

Similar Threads

Similar Threads

Similar Threads