GraphQL pays off on connected screens, but brings three costs

A tool that trims work, then sends three bills

Khosla builds internal applications that govern who may access which systems. Her React front ends call both REST and GraphQL back ends, so she has used each style under the same conditions. In an InfoWorld column, she argues that GraphQL earns its place on one kind of screen: the kind that combines highly interdependent data from several sources.

That is the useful idea for anyone approving an API strategy. GraphQL cuts front-end work and the effort of building back-end endpoints. Teams then pay three costs they did not plan for. The saving is real on connected screens. The costs come with the choice.

Where the saving is real

Khosla describes a client details screen. It shows the client, their accounts, the permissions on those accounts, the account owners and related objects. The screen needs a slice of every layer at once.

With REST, she sees two options. The front end can chain requests: client, then accounts, then permissions for each account. Each request waits for the one before it. She says this becomes inefficient when the network has problems. Or the back end can build a custom endpoint for the screen. That works while the screen keeps its format. After that, she says, you collect many endpoints nobody wants to maintain.

GraphQL changes who decides the shape of the response. The client asks for specific fields, and one query can follow related objects in a single request. In her application, a new screen means a new query, not a new endpoint.

She is careful about the evidence. She says she cannot quantify the benefit. She can state that there are fewer endpoints to build and fewer sequential queries on connected screens. This is one practitioner's experience, not a measured result. She adds that it holds when the data is connected, screens need different slices of it, and one team, or two teams that talk daily, own both sides.

Cost one: caching without a URL

Caching is easiest to see in REST. Each resource has its own URL, so a cache can store the answer for that address and serve it again. GraphQL sends every request to one endpoint. A cache that looks at the address sees the same URL each time and cannot tell one query from another.

Khosla points to the GraphQL caching guide. Without a URL to tell objects apart, it says, the API should give each object type a globally unique ID. That ID gives the cache something to hold on to.

Cost two: the client sets the size of the query

The client decides the shape of the query, so it can ask for a great deal. A query nested ten levels deep, or one that fetches everything from a long list, can hurt the back end. Khosla says this holds whether the cause is malice or carelessness.

She points to the OWASP GraphQL Cheat Sheet. It suggests limiting query depth, analysing cost, setting a maximum query cost, paginating results and disabling introspection in production. Introspection lets a client ask the server to describe its own schema.

Cost three: access checks on every object and field

Khosla says authorization gives companies the most trouble. In REST, securing an endpoint covers much of the problem, though object-level checks are still needed. In GraphQL, one query can reach a customer and their account, then step into a field on a related object the user should not see.

So the check has to happen per object and per field. She cites OWASP guidance to confirm the requester may see every object and field returned.

She is firm on where that check belongs. Resolvers are the small pieces of code that fetch each field. Her advice is to keep permission logic out of them. The GraphQL project's authorization guidance, she says, puts the rule in the business logic layer, so a resolver only asks for the verdict.

Her reasoning is practical. If the rule lives in resolvers, a second route to the same data may appear one day: a REST API, a batch process or another service. You then hold two slightly different versions of the rule, and two users get different data depending on which door they used. In a system that controls access, she says, this bug "behaves like a feature."

The real price is a central authority

This section is WebPulse's own argument, not Khosla's. Caching and query limits are tuning jobs. Published guidance exists for both, and a team can work through them. Authorization is different in kind.

Because one GraphQL query can cross many objects, every object and field needs a check. The only way to keep those checks consistent is to hold the rule in one place. That turns an API choice into an organisational one. Someone must own the rule, and every route to the data must ask that owner. Her example shows the alternative: two doors, two answers.

So the cost of GraphQL is the cost of centralising authorization. A company that already has a central rule layer has little extra to pay. Khosla says such a team is "in great shape." A company with rules scattered across services has to build one first, and that work is larger than adopting a query language. The sensible order is to settle the permission model, then pick the API.

Five checks before adopting it

Khosla offers five checks. First, count the clients and screens that need different views of the same data. With one or two, she says, a few carefully designed REST endpoints may do. Second, judge how tightly the data links together. The more interdependent it is, the more GraphQL gains.

Third, name who is responsible for the schema. She warns that a contract with no owner drifts. Fourth, find out where permission rules sit today. Scattered rules, she says, are what GraphQL will expose. The fifth is whether you need more than a plain REST endpoint. She says "probably" is a fine answer.

Her reading is simple. Several clients, connected data, a schema owner and central authorization point toward GraphQL, starting with the screens that hurt most. One client, flat data and no owner means waiting. Mixed answers suggest a trial on one read-heavy screen, with depth and authorization controls from the start.

She keeps action-style operations on REST, such as starting a credential rotation. Those endpoints do one thing and are easy to authorize, log and retry. Nobody gains from letting the client shape the result.

What to do this week

Khosla suggests listing your five most used screens and counting the distinct calls each one makes. If one or two turn out to be connected and chatty, that is where GraphQL may earn its keep.

Then ask your team to show you the permission rule in writing, and to say whether any second route could bypass it. Ask who owns the schema, and what limits exist on query depth and cost. If nobody can answer the first question, fix that before any API decision.

GraphQL makes it cheaper to ask for data. It does not make deciding who may see that data any cheaper.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: InfoWorld.