The backend renamed a field and didn't tell me. Here's how I find what broke

This happens in every project eventually. The backend dev renames title to name, deploys on a Friday, and doesn't mention it. Your app still compiles, because the types in your code were written by hand and they still say title. Then a screen shows nothing, or crashes, and you find out from a user.
In a big app it gets worse, because now you're hunting through API layers, interfaces, normalizers, and consumers trying to work out what else that field touches.
Here's how I deal with it now.
Don't write the types by hand
Every request and response type in my apps is generated from the backend's OpenAPI spec. There's one openapi-fetch client, and the types flow from the schema into the client, into the resource hooks, and into the screens. There are no hand-written interfaces in between that can quietly go stale.
What happens when a field gets renamed
Say the items endpoint used to return title and now returns name.
- Regenerate the types:
npm run gen:api
- Run the type check (or just look at your editor):
npx tsc --noEmit
- TypeScript now lists every place that still uses the old field:
Property 'title' does not exist on type '{ id: number; name: string; }'.
Every screen and hook that touched title shows up as an error, with the file and line. I fix them one by one, and when the errors are gone, I'm done. It takes minutes, and I'm not guessing what else might be broken.
What it doesn't do
Two limits, so you don't trust it more than you should:
- The types are only as good as the spec. If the backend changes the API and doesn't update the spec, nothing knows. If your backend generates the spec from its code, that mostly takes care of itself. With Laravel, packages like Scramble or L5-Swagger do this.
- It's compile-time only. It catches mismatches in your code. It doesn't validate what the server actually sends at runtime.
Where this lives
All of this is part of a starter template I made for my Expo apps and now use for most of my projects. I switch between three or four apps in a day, and every new project used to start with a few days of the same boilerplate work for routing, auth, API layer, types, error handling, theme, components. None of it is specifically hard, but it's slow, and every project comes out slightly different. So I made the template once, and now the boring part is already done.
What's in it:
- Typed networking. The
openapi-fetchclient and generated types from this article. - Data layer. TanStack Query with a resource-based custom hook pattern, plus shared conventions and helpers (response unwrapping, pagination, error handling etc.) already wired into the app.
- Global error handling. One error type, one error store, and toasts, with per-request flags to opt out.
- Auth and role-based routing. Public, auth-protected, and dashboard routes for role-based navigation, all configured and structured to expand.
- Theme and UI kit. A global theme with dark and light mode, plus a small responsive UI library built on
react-native-size-matters. - A mock server. A local mock backend generated from the OpenAPI contract, so you can build and test screens, including login and the dashboard, before the real backend exists.
You clone it, set up your env and project config by following the README, and start coding:
gh repo create my-app --template amirazerani-gif/expo-starter-pack --clone --private
The part I like most is maintenance. Architecture doesn't look like a big deal while you're building, because everything is fresh. It gets painful months later, when you open an app to fix something and have to dig through decisions nobody remembers. With the same structure in every project, I open any of my apps and already know where everything is.
It's opinionated. It assumes a Laravel-style JSON API, because that's what most my backends look like, and the README lists the files to change if yours differs. It's on Expo SDK 57 right now, and the SDK 58 upgrade is on the way.
Repo: github.com/amirazerani-gif/expo-starter-pack
I wrote about how I use it in general here: This is how I start a new project in Expo
If you end up using it, let me know how it goes. Open an issue, drop a comment, or leave a star if you liked it.
About the author
- Mobile dev. I build apps in React Native, Expo, Compose, and KMP, keep them running in production, and keep the users happy 👑. Ajman, UAE.
Comments
Join the discussionNo comments yet. Be the first to comment.
Inside expo-starter-pack
How I structure Expo and React Native apps: typed API clients from OpenAPI, TanStack Query hooks, global error handling, role-based routing, and a mock server for building before the backend exists.