Shared types file.
One field rename on the backend. Six components silently trusting the wrong shape.
And TypeScript never said a word.
That’s the part people miss with “just share your types between frontend and backend.”
It sounds clean. It feels safe.
But it only works if someone actively keeps that shared contract in sync. And in a real product, especially in a fast-moving SaaS environment, that assumption breaks more often than people admit.
We ran into this mid-sprint.
The backend renamed a field in an API response. The API call layer was updated to reflect the change. The shared type file wasn’t.
Everything still compiled.
No red flags. No warnings.
The UI didn’t crash either — which would’ve been easier to catch. Instead, it started rendering incorrect data in subtle ways. It looked like a frontend issue at first.
That’s the worst kind of bug.
Not failures. Drift.
Here’s what the type looked like:
type UserResponse = {
id: string
name: string
avatarUrl: string
}
But the actual response had already moved on.
At that point, we weren’t debugging types anymore. We were debugging behavior.
We changed how we handle it after that.
Instead of trusting a shared type file as the source of truth, each layer now validates what it receives at runtime, then maps it into its own types.
Yes, it feels less elegant.
Yes, there’s some duplication.
But it’s much harder for things to silently go out of sync.
Shared types don’t enforce contracts.
They assume them.
And in production systems, assumptions are where bugs like this hide.
typescript
nextjs
saas
webdev
Top comments (0)