A shared API is a bottleneck for four client teams. Does a flexible query language fix it?

What is being tested

Whether you separate the payload problem from the ownership problem, which are frequently conflated.

What it fixes

Over-fetching and round trips. The client requests exactly the fields it needs, in one call, rather than making six requests and discarding most of each response. That is a genuine and substantial improvement, particularly on mobile networks.

What it does not fix

The bottleneck. Four client teams queueing on one API team for behaviour changes — a new field that requires backend work, a new resolver, a change to business logic — is Conway's Law operating as a delivery constraint. A query language changes nothing about who can make that change.

If the constraint is "we wait three weeks for the API team", the fix is ownership: a backend for frontend per client class, owned by the client team.

What it introduces

• Caching difficulty. No simple URL-based cache key, so HTTP caching and CDN caching largely stop working and must be replaced with application-level caching.
• N+1 at the resolver layer, unless batching is implemented deliberately. The pattern is invisible in the query and obvious in the database.
• A denial-of-service surface. A deeply nested query can be enormously expensive. Query depth and cost limits are mandatory, not optional, for any externally exposed schema.
• A schema that is a public contract consumed by clients you may not be able to enumerate.

How to decide

Ask which problem you have. If the payload and round trips are the pain, a query language or a compound endpoint solves it. If the team queue is the pain, only moving ownership solves it — and doing both is common and reasonable, provided you know which one you are buying.