GraphQL API development
GraphQL lets a client ask for exactly the data it needs in one request. On products with several clients and screens whose data requirements keep changing, it removes a permanent source of backend churn.
Where we use GraphQL
GraphQL is part of the stack on these 5 services. Each page covers how we work, what you get and what it costs to start.
GraphQL in practice
GraphQL lets a client describe exactly the data it needs and receive that, in one request. On a product with a web app, a mobile app and a partner integration, that removes the permanent backend churn of adding endpoint variants every time a screen’s data requirements change.
The costs are real and worth naming. HTTP caching no longer works the way it does with REST, a naive resolver implementation produces N+1 queries immediately, and an unbounded query can be expensive to serve. All three have standard answers — persisted queries, data loaders, depth and complexity limits — but they are things you must do, not things you get.
What we build with GraphQL
One schema serving web, mobile and partner clients, each requesting only the fields it renders.
A typed contract agreed before implementation, so frontend and backend can proceed in parallel.
Headless commerce work, where Shopify’s own API is GraphQL and the schema is given.
Is GraphQL right for you?
Ask usA good fit when
- Several clients needing different shapes of the same data
- Mobile clients where over-fetching costs users real bandwidth
- Products where screen data requirements change often
- Integrating with an API that is already GraphQL, such as Shopify’s
Probably not when
- A single client with stable, simple data needs — REST is less machinery
- Heavily cached public content where HTTP caching is doing the work
- Small teams without capacity to handle its operational specifics
What we run alongside GraphQL
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- DataLoader
- Batching and caching per request. Without it, N+1 queries are guaranteed.
- Persisted queries
- Known queries by hash, which restores caching and closes off arbitrary expensive queries.
- Apollo Client or urql
- Client-side caching and state, which is where much of GraphQL’s benefit lands.
- Depth and complexity limits
- Bounds on what a single query can cost to serve.
- Code generation
- Types generated from the schema, so client and server cannot silently disagree.
Why GraphQL
Let’s talkNo over-fetching
A mobile client can request three fields where a REST endpoint would have sent forty — which shows on a slow connection.
The schema is the documentation
Introspection means tooling, autocomplete and generated types come from the API itself rather than a wiki.
Additive evolution
Fields can be added and deprecated without versioning the whole API surface.
What we get called in to fix
Get a second opinionN+1 resolvers
Every field triggering its own query. The classic first-implementation problem, solved with data loaders.
No query limits
Deeply nested queries that a single client can use to exhaust the database.
Schema as a database mirror
Tables exposed one-to-one, so the API carries none of the domain’s meaning.
Caching abandoned
HTTP caching lost and nothing put in its place, so every request reaches the database.
GraphQL or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
GraphQL when many clients need different shapes. REST for a single client with stable needs — simpler, and HTTP caching still works.
tRPC when both ends are TypeScript and you control them. GraphQL when clients are diverse or external.
Schema-first when frontend and backend teams must agree a contract before building. Code-first when one team owns both.
GraphQL works well with:
Node.js
React
TypeScript
Angular
AWS
Azure
Docker
Flutter
Google Cloud
GrafanaGot an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
GraphQL when several clients need different shapes of the same data. REST is simpler and often better for a single client with stable needs.
Yes at the HTTP layer, which we address with persisted queries and caching at the resolver and data-loader level.
Query depth and complexity limits, plus data loaders to prevent the N+1 pattern that catches most first implementations.
Different, not harder. Depth limits, complexity limits and field-level authorisation are the specific things you must add.
Yes — a common pattern for consolidating several services behind one client-facing schema.