A screen is not a database table

Imagine a mobile screen that shows an app’s recent activity alongside a small summary. The server has the information, but the client has to make several requests and join the results before it can draw anything useful.

It is tempting to treat that as an immediate argument for GraphQL. I would first ask whether the existing API is giving the screen the right response.

An HTTP/JSON API can return a composed read model. The public response doesn’t have to mirror the database tables, or require the client to discover how the backend stores everything. An endpoint for the activity screen might return the recent entries and the summary together.

That is a design choice with a cost. A very specific response can become awkward if every new screen needs a slightly different variation. The server can accumulate endpoints that overlap without anyone understanding why.

But I wouldn’t reject a useful response just because it serves a particular client need. I would look at how stable that need is, what data belongs together, and whether the response has a clear meaning beyond the current widget layout.

GraphQL’s field selection offers a different way to handle varying requirements. The client can express which fields it needs. That is worth comparing against the cost of maintaining several fixed response shapes.

The example here is hypothetical, but it captures a question from my API research: where should the assembly happen? Before changing the protocol, I want to understand how much complexity comes from the current boundary itself.