A commerce platform moves its primary API from REST to GraphQL. What genuinely improves for third-party developers, and what new problems does the platform acquire?

What improves

The client fetches exactly what it needs, in one request. A mobile app rendering an order summary previously made several REST calls and discarded most of each response. One GraphQL query replaces them, which matters enormously on high-latency mobile networks where round trips dominate.

The schema is the documentation and the contract, introspectable and typed. Client code generation becomes reliable, and a field type mismatch is a build error rather than a runtime surprise.

Field-level evolution. New fields are additive and invisible to existing clients; deprecated fields carry a machine-readable deprecation notice and can be measured for actual usage. This is genuinely better than REST versioning, where the whole surface moves together.

No over-fetching or under-fetching, so client teams stop asking the platform team for a slightly different endpoint.

What the platform acquires

Unbounded query cost. A client can request deeply nested data whose cost is arbitrarily large. With REST, the platform decides what each endpoint costs; with GraphQL, the client does. This is the central problem, and it must be solved before launch:

• Query complexity analysis — assign a cost to each field and connection, compute the query's cost before execution, reject over budget.
• Cost-based rate limiting rather than request counting. A rate limit of "1000 requests per minute" is meaningless when one request can be a thousand times more expensive than another.
• Depth and node limits as a crude backstop.

The N+1 problem, structurally. A query for 100 orders each with a customer naively produces 101 database queries. Batching and caching per request — the dataloader pattern — is mandatory rather than an optimisation, and it must be applied consistently or one unbatched resolver silently reintroduces the problem.

HTTP caching largely lost. Every query is a POST to one endpoint, so intermediate caches, CDNs and conditional requests do not apply. Caching moves into the application layer, which is more work and less effective.

Observability that must be rebuilt. "Which endpoint is slow" has no meaning. You need per-field resolver timing and per-query-shape analysis, and standard API monitoring tells you almost nothing.

Error semantics that surprise clients. A partial success returns 200 with errors in the body. Clients that check the status code and stop will silently mishandle failures, and many do.

The judgement

For a platform whose value is a rich, interconnected data model consumed by many diverse third-party clients, GraphQL is a strong fit and the client benefits are real. The cost is that the platform must build query governance before it needs it, because the failure mode is a single expensive query taking down a shared backend.

The common mistake is adopting GraphQL for the developer-experience benefits and adding cost controls after the first incident, by which time clients have built on unbounded queries and constraining them is a breaking change.