Backend interview question:
Why should your API not return database models directly?
A common junior answer is:
“Because it works and it is faster to develop.”
And honestly, for a small prototype, that might be fine.
But in real production systems, returning database models directly can create problems very quickly.
For example, your User table may have fields like:
passwordHash resetToken internalNotes roleId createdBy deletedAt
Even if you “hide” some fields today, the risk is still there.
The bigger problem is coupling.
When your API response is the same shape as your database model, every database change can accidentally become an API change.
That means:
Frontend becomes tightly coupled to backend internals
Refactoring the database becomes risky
Sensitive fields may leak by mistake
API versioning becomes harder
Your response shape is designed around storage, not user needs
A better approach is to use DTOs or response mappers.
The database model answers:
“How do we store this data?”
The API response should answer:
“What does the client actually need?”
That small separation makes your system much easier to maintain as it grows.
Senior backend development is not just about making the endpoint work.
It is about protecting future changes.
How do you usually structure API responses in your projects?
#NodeJS #BackendDevelopment #APIDesign #TypeScript #SoftwareEngineering #FullStackDevelopment
