Let’s be honest.
Most developers — frontend and backend — suck at structuring data.
Not because they’re stupid.
Not because they’re lazy.
But because the industry taught them to think in screens, not systems.
Once you understand this, everything starts to make sense.
Let’s break the taboo.
1. You think in UI, not in domain
Most devs start from a Figma screen or a quick whiteboard sketch — but rarely from actual business logic.
They ask:
“What JSON do I need for this response?”
instead of:
“What does the underlying domain really look like?”
So the API becomes a reflection of the UI, not of the business.
Your tables, models, and routes start to smell like:
subtitleisCollapseddisplayOrderobject.with.20.levels.of.depth
That’s not data modeling.
That’s serializing your component tree.
2. You merge unrelated concepts “because it’s easier”
You know this one:
{
"user": {...},
"orders": [...],
"permissions": [...],
"stats": {...}
}
Congratulations.
You've created a blob API — a JSON smoothie.
It works for one screen.
It dies everywhere else.
3. You don’t separate stable vs unstable structures
UIs change weekly.
Business rules change yearly.
If your API breaks every time someone moves a card in Figma or a customer requests a “tiny change”…
You didn’t build an API.
You built a UI transport layer.
A good data model must survive:
- redesigns
- mobile apps
- partner integrations
- analytics
- AI
- new features
- new markets
If it doesn’t survive these → it was never a real data model.
4. You over-aggregate because you’re afraid of making 4 requests
Some developers believe:
“We need one endpoint for the entire page.”
No, you don't.
Making multiple async calls is:
- cleaner
- more predictable
- easier to cache
- easier to invalidate
- far more flexible
Aggregation is a tool.
Not a default.
5. You don’t understand entities vs projections
This is the root cause of 90% of bad APIs.
- Entities = the truth of your business
- Projections = reshaped, convenient data for a specific use-case
If you mix them, you get:
- UI fields leaking into persistence
- domain rules encoded inside components
- APIs that break with every design update
- models nobody understands anymore
Good developers keep these two worlds separate.
Great developers document the projection boundaries.
6. You never ask the hard questions
The best data architects ask:
- What is the source of truth?
- What entities actually exist?
- What invariants must never break?
- Would a mobile app use this?
- What happens if the UI changes completely?
If you never ask these questions, you're not modeling — you're sketching.
🔥 So… how do you get better?
Here’s the simple framework that instantly levels up your architecture.
✔️ 1. Model the domain before the API
If you can’t explain the business with boxes on a whiteboard → don’t write the endpoint.
✔️ 2. Keep entities pure
No UI fields.
No layout info.
No Figma-driven naming.
If your database tables look like React components, stop everything and refactor.
If you chose a document database because it mirrors the UI, ask yourself:
“What if there was no UI at all?”
✔️ 3. Prefer multiple granular endpoints
Frontend frameworks are built for composition.
Use them.
Let the UI combine the data.
Don’t let the UI dictate the data.
✔️ 4. Use projections sparingly — and name them clearly
Examples:
-
/orders→ entity -
/orders/overview→ projection -
/dashboard→ projection -
/users/:id/profile-view→ projection
Good naming avoids 80% of confusion.
✔️ 5. Design for multiple frontends
Ask yourself:
Would this structure still make sense if:
- I built a mobile app?
- A partner consumed the API?
- I fed this into an analytics pipeline?
- I replaced React tomorrow?
If the answer is no, start over.
✔️ 6. Think in relationships and constraints
A real data model is not:
“Objects with stuff inside.”
It’s:
- entities
- references
- invariants
- constraints
- timelines
- state machines
This is where a developer becomes an architect.
✔️ 7. Simpler is better
Multiple small, meaningful entities are easier to maintain
than one giant “god object.”
✔️ 8. Avoid deep nesting — prefer flat structures
Your API should deliver flat, normalized data.
Let the UI handle grouping, filtering, nesting, aggregation.
Flat data = predictable data.
✔️ 9. Use correct naming — and be consistent
Clear naming saves lives.
UserGroupsResponse is instantly understandable.
If your naming forces people to guess → it’s wrong.
✔️ 10. Anticipate change
Your model will grow.
It will evolve.
It will get more complex.
Design with flexibility in mind.
Future-you will thank you.
🎯 Final message
You don’t suck at structuring data because you’re bad.
You suck because nobody ever taught you to think beyond the screen.
Once you learn to separate:
- domain vs projection
- entity vs layout
- truth vs convenience
…everything becomes easier.
Screens change every week.
Good data structures last a decade.
Top comments (0)