Measure Before You Optimize
Finding inefficiency is not the same as finding a problem.
Something Looked Wasteful
The Orders screen needed only id, status, total, and itemCount.
But GET /orders returned complete Orders, including their Order lines.
The browser derived itemCount from the Order lines but did not need the remaining line details.
Measured Evidence
The response was doing more work than the collection screen required. The next question was whether that inefficiency created meaningful performance pressure.
- Total request
- 18.95 ms
- Server wait
- 10.60 ms
- Download
- 2.04 ms
- Total request
- 22 ms
- Server wait
- 13.47 ms
- Download
- 2.95 ms
The Decision
The over-fetching was real, but the measured performance pressure was not.
No production code changed.
That meant no pagination, no caching, and no specialized summary endpoint.
The Lesson
Finding inefficiency is not the same as finding a problem.
Measure first. Architecture second.
CONTINUE THE ARCHITECTURE JOURNEY
The substitution experiment is only part of the story.
This experiment comes from my book Building Software Around the Business — Not Around the Framework — Frontend Architecture with TypeScript, Angular, and React.
The book follows the architecture from the first frontend behavior through Domain and Application boundaries, state ownership, capability segregation, runtime composition, and the final REST-to-GraphQL substitution proof.
Explore the frontend architecture book →