If you're a founder and someone on your team has brought up this question, here's the short version before we get into the rest: for most small and mid-sized business projects, REST is still the right default, and GraphQL earns its complexity only in specific situations we'll walk through below. If you're a developer who already knows the tradeoffs and just wants the nuance, skip ahead — the short answer above is deliberately oversimplified. |
What These Actually Are, Quickly
An API is how your frontend — your website or app — talks to your backend to get and send data. REST, the older and more established approach, structures this around fixed endpoints: /users gives you users, /products/42 gives you product 42, and each endpoint returns a predetermined shape of data whether you need all of it or not. GraphQL, developed at Facebook and released publicly in 2015, takes a different approach — a single endpoint where the client specifies exactly what data it wants in the request itself, and the server returns exactly that, nothing more.
That single difference — fixed responses versus client-specified responses — is the root of almost every tradeoff between them. Everything else follows from it.
Where GraphQL Genuinely Wins
The classic problem GraphQL solves is over-fetching and under-fetching. Say your app's homepage needs a user's name, their last three orders, and a product recommendation. With REST, that's often three separate requests to three separate endpoints, each returning more data than you actually need for that screen — the /users/42 endpoint might return twenty fields when you only needed one. With GraphQL, that's one request specifying exactly those pieces of data across all three, and the server returns exactly that, no more.
This matters most in two specific situations. First, complex applications with many different screens or client types — a web app, a mobile app, and a smart TV app, say — each needing a slightly different slice of the same underlying data. REST tends toward either bloated generic endpoints trying to serve everyone, or a proliferation of custom endpoints for each specific need, both of which get messy to maintain as an application grows. GraphQL lets each client request exactly what it needs from the same underlying schema without either problem.
Second, GraphQL genuinely shines when your frontend team moves faster than your backend team can keep up with new endpoint requests. With REST, adding a new screen that needs a new combination of data often means asking a backend developer to build a new endpoint or modify an existing one. With GraphQL, if the data already exists in the schema, a frontend developer can often assemble exactly what a new screen needs without waiting on backend changes at all. For teams building fast-iterating products with frequent UI changes, this can meaningfully speed up development.
Where REST Still Wins, and Why It's Still the Default
Here's what GraphQL's own marketing tends to underplay: simplicity has real value, and REST is simpler in ways that matter for most projects, especially smaller ones.
REST is dramatically easier to cache. Because REST endpoints are predictable and stable — the same request to /products/42 always returns the same shape of data — standard HTTP caching, CDN caching, and browser caching all work with REST out of the box, with decades of established tooling built around exactly this pattern. GraphQL's flexible, client-defined queries make this significantly harder, because two different requests to the same endpoint can ask for completely different data, defeating a lot of standard caching approaches unless you build additional infrastructure specifically to handle it.
REST is easier to secure and rate-limit sensibly. A REST API's fixed endpoints make it straightforward to apply access controls and rate limits per endpoint — "this user can call /orders up to 100 times a minute." GraphQL's single endpoint with arbitrarily complex, client-defined queries makes this genuinely harder to reason about; a poorly-designed or malicious query can request deeply nested data that ends up being expensive to compute server-side, and defending against that requires more deliberate engineering than most small teams have the time or expertise to build properly early on.
REST is easier to hire for, debug, and reason about, particularly for smaller teams. Most developers, especially in Nigeria's current talent market, have significantly more hands-on REST experience than GraphQL experience, and REST's simplicity means fewer moving parts to debug when something breaks. GraphQL brings real additional complexity — a schema to design and maintain, resolvers to write, and a steeper learning curve for anyone new to the team — and that complexity is a cost you're paying whether or not your project actually needs GraphQL's specific benefits.
The Honest Framework for Deciding
Ask yourself three questions, roughly in this order.
QUESTION 1 Do you have multiple, meaningfully different clients consuming the same backend — web, mobile, maybe a partner API — each needing different slices of the same data? If yes, GraphQL starts looking genuinely attractive. If you've got one frontend talking to one backend, this advantage barely applies to you.
QUESTION 2 Is your data highly relational, with screens frequently needing to pull together information from several different, deeply nested sources in a single view? If your app is mostly simple CRUD — creating, reading, updating, deleting fairly flat records — REST handles this without friction and GraphQL's flexibility buys you very little.
QUESTION 3 Do you have the team and time to properly implement GraphQL's additional complexity — schema design, resolver performance, query complexity limits — or would adopting it mean a junior team learning these concepts under real project pressure, likely producing a poorly-secured, poorly-optimized GraphQL API that's worse than a straightforward REST API would have been? Be honest here. We've inherited more than one GraphQL project where the added flexibility was never actually used, but the added complexity was very much still there, slowing down every developer who touched it afterward.
What We Actually Recommend for Most Clients
For the majority of small and mid-sized business projects we build — a business website with a booking system, a straightforward e-commerce platform, an internal dashboard, a single mobile app talking to a single backend — REST remains the right call. It's simpler to build, easier to secure sensibly with a smaller team, cheaper to maintain, and there's a much deeper local talent pool who can pick up an existing REST project quickly if your original developer moves on. GraphQL is a genuinely powerful tool, but power you don't need is just complexity you're paying for without the benefit — and for the kind of businesses we're usually building for, that benefit rarely materializes in practice. |
If you're building something that genuinely has multiple client types pulling different, complex slices of deeply relational data — a platform serving a web app, a mobile app, and third-party integrations off the same backend — that's the point where the GraphQL conversation is worth having seriously, with a team that has the experience to implement it well rather than as a first attempt at the technology under real deadline pressure.
