GraphQL is a cost you pay for clients you may not have
Choose GraphQL by the clients and teams you actually serve. Count authorization, query limits and maintenance before paying for an API's flexibility.
By 
Paul. Architecture and infrastructure
A team building one web application should ask who needs to choose the shape of its API responses. If the same people control the interface and the server, a typed REST or RPC API is a sensible starting point. GraphQL deserves a specific reason to replace it: independent consumers whose different data requirements make fixed responses costly to coordinate.
That is a decision rule, rather than a prohibition. Client count is only a proxy for coordination cost. One complex application may justify GraphQL; several applications with similar needs may not. The useful question is how much freedom clients need and who will maintain the machinery that makes that freedom safe.
A complaint worth turning into a budget
Matt Bessey's 24 May 2024 essay challenged GraphQL on security, performance and maintenance after his own experience using it. His account is evidence of an engineer's difficulties, not a measurement of all GraphQL deployments. It is useful because it puts operational work beside the attraction of asking for exactly the fields a screen needs.
For a new project, write down the consumers that exist today. Include their owners and release schedules. A separately released mobile application has different constraints from a website shipped alongside its server. An external partner has different constraints again. Future clients belong in the estimate only when there is a credible plan for them.
Then describe one likely change. Suppose, as a design exercise, a customer screen needs invoice totals while a support screen needs recent delivery events. If one team can add two focused responses in the same release, negotiating response shapes may be cheap. If independent teams repeatedly wait for that change, client-selected data becomes more valuable. That waiting cost is the benefit GraphQL must earn back.
Flexibility changes what needs a limit
An endpoint count is a poor proxy for server work. With GraphQL, two requests to the same URL can demand very different amounts of data. The current GraphQL security guidance discusses pagination, depth limits and query complexity as ways to control demand. These are current design references, not evidence of what a particular server enforced in 2024.
The engineering estimate should therefore include someone choosing limits and reviewing legitimate requests that exceed them. A limit that rejects the most important customer screen is a product decision as well as a security setting. It needs an owner who can explain the tradeoff.
Nested resolution also deserves a data-access plan. Loading a list and then fetching related records separately for every item can multiply database work. REST handlers can make the same mistake. The practical difference is that a narrowly defined response gives the team fewer combinations to inspect. Neither protocol supplies an efficient query plan automatically.
Permissions belong to the business rules
A user who may see a customer name may still be forbidden to see payment information. GraphQL's current authorization guidance recommends keeping permission logic in the business layer. That keeps the rule available wherever the same data is reached.
The proposed design should show how a sensitive field stays protected through different paths. Putting a check on one screen or one resolver is insufficient if another route reaches the same record. Typed REST also needs object and field permissions; choosing it does not remove that obligation. Its attraction for a small, jointly owned product is a more constrained response surface to reason about.
This is where estimates often become misleading. A schema can be generated quickly. Demonstrating that users receive only the data they may see takes separate work. Ask for that work explicitly before treating a working API explorer as completion.
Restricting operations changes the bargain
For first-party applications, an allowlist can limit production traffic to approved GraphQL documents. The trusted-document guidance explains this approach. Merely storing queries to save bandwidth is different from rejecting every unknown operation.
An enforced allowlist makes the operational interface resemble named RPC operations: the server accepts a known request shape with parameters. It still retains GraphQL's schema, composition and tooling. Calling it literally identical to RPC would miss those differences. But the comparison exposes a useful purchasing question: if production accepts only a fixed operation catalogue, which remaining GraphQL features justify maintaining it?
Existing expertise can be a strong answer. Reusing a well-run GraphQL system may cost less than introducing a second API style. A constrained first-party API can also be a deliberate security choice rather than a retreat from the technology.
Keep the architecture proportional to the consumers
The strongest case for GraphQL is organizational independence: consumers evolve at different speeds and need useful combinations of shared data. Schema discipline and capable maintainers can make that a good investment. The strongest case against adopting it by default is paying that maintenance cost before the independence exists.
For an existing application, changing protocol requires its own business case. Migration can consume effort without improving a customer task. Start by finding the actual bottleneck: permissions, database access, coordination or tooling. Repairing that bottleneck may be enough.
For a new custom software project, ask for a written comparison around real screens and real owners. Choose the smallest contract that serves them, and record what future change would justify revisiting it. That gives the team a decision it can explain when the original architect has left.