tRPC with mobile apps?
What's the suggested way of working with tRPC when it comes to mobile apps? How do you ensure that your CI doesn't let you push a new backend to production if it breaks the mobile app in production?
24 Replies
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
GitHub
GitHub - t3-oss/create-t3-turbo: Clean and simple starter repo usin...
Clean and simple starter repo using the T3 Stack along with Expo React Native - GitHub - t3-oss/create-t3-turbo: Clean and simple starter repo using the T3 Stack along with Expo React Native
You have everything you need in this starter
It's typesafe in the same way as tRPC in NextJS so you're always sure you're correct when it comes to API <-> mobile app relation
But it's not right?
It's typesafe in your code but that does not ensure that you're not pushing breaking changes that destroys your current prod app right?
When you deploy the backend you also deploy the NextJS app but when you deploy the backend you don't automatically deploy a new app because that has to go through apple and google for them to approve it.
What do you mean by this?
How should these pre-commit / pre-push tests ensure that my changes don't break the app that is currently in production? 🤔
Yeah, I meant changes to the routes / inputs / outputs
Yeah but as soon as you push a breaking change to your api's it's gonna break the app that is live in production right and there's no way to handle like versioning of API's with tRPC right so I can't have the app continue using the v1 of the api when I deploy a v2 of it without having to have both API's separately in my code right? 🤔
Yes, that's right
I don't think I know a good way of handling that
I've never built a prod-ready mobile app haha
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Yes I know but even if your commit is fine it doesn't mean it won't brick the app that is in production 🙂
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I'm not sure you understand the problem.
I'll try to explain it below.
Let's say the production mobile app has version 1.0 and is fully functioning. (with functioning backend)
The backend commits breaking changes and you fix those changes in the FE as well. (no TS complaints in BE or FE)
The backend in prod is then updated.
The Mobile app is in review at google and apple and it will take up to a week until the new FE changes are in production.
During this week the mobile app would be bricked in production since the new FE changes are not yet live but the new BE is live.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Codepush is a thing
Should only be used for bug fixes though, Apple don't like it too much from what I've heard.
I mean that's a dream scenario right but I've never worked on any big projects that haven't had to add new major versions of APIs from time to time.
Yeah not sure what good solutions there are for this that's why I'm asking ^^
I’d probably just use CI to run a test suite and check that the endpoints are ok
If you expect more than one version of the app to be in use, you need to keep every version of every endpoint anyway
Would just need to force users to update after breaking backend changes so should at max have two versions of an API at a time.
Or send version number with the request and have the api respond differently depending on that
API and app are never “really” connected with mobile apps so idk if there’s a different way of doing it, no matter what stack you’re using
With REST you have versioning of APIs right and then it's really easy to return different versions of the API based on an app version header or such
API versioning is usually done through query params, headers, or path
Yeah I guess this might be the only somewhat simple way to handle it, can you pass headers with tRPC or would it be a prop to the functions?
you have all of those in tRPC
(tRPC is REST)
Ah found it
https://trpc.io/docs/v10/header
Custom header | tRPC
The headers option can be customize in config when using the httpBatchLink or the httpLink.
Would you guys say this is a good way to handle it?
- Send a x-app-version header with all requests from the mobile app.
- If there are any breaking changes in the backend a new version of the API that has breaking changes is created.
- The backend will return the old version of the endpoint unless the x-app-version is a version where the fixes have been applied in the mobile app.
- Once the new mobile app is live in production either the feature which is affected would be feature toggled or the whole app would be killswitched telling the users to update the app.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View