GraphQL is worth it when several different clients need different shapes of the same data — a web app, a mobile app, a partner integration — and you are tired of shipping a new endpoint for every screen. It is not worth it when there is one client and twelve endpoints.
The schema is the product
We design the schema around the domain, not around the current screens. Screens change every quarter; the fact that an order has line items does not. A schema modelled on today’s UI becomes a second UI to maintain.
Three questions before the first resolver
- Cost. What does the most expensive legal query look like, and what stops it? Depth limits, complexity scoring and pagination are decided up front.
- Authorisation. Permission is enforced per field, at the resolver, not at the route. A single endpoint means route-level checks buy you nothing.
- Caching. Persisted queries and a batching layer, so a nested query does not become forty database round trips.
Errors that mean something
A partial result with a typed error beats a blanket failure. Clients need to know the difference between “you may not see this”, “this does not exist” and “we are broken”, and the schema should say which one happened.
When REST is the better answer
If the surface is small, cacheable at the HTTP layer and consumed by one client, plain REST is simpler for everyone, including the person on call. We build those too — the decision is made per project, and it is written down with the reason. More on that in integrations and API.
Built on Node.js or Python, typed end to end with TypeScript.