REST or GraphQL: how we choose

If you're having software built, somebody on the technical side is going to decide how the front end talks to the back end. The two names you'll hear are REST and GraphQL. Developers argue about this endlessly online, which makes it sound like a hard decision. For most business software, it isn't. Here's how we choose, and what the choice costs you either way.

What each one is, without the jargon

REST is the traditional style. The server exposes a set of URLs, each representing a thing: /customers, /customers/42, /customers/42/invoices. The app asks for a URL, the server sends back that thing as JSON. It's been the standard way to build APIs for about twenty years, and nearly every service you've heard of (Stripe, Twilio, QuickBooks) offers a REST API.

GraphQL is a query language Facebook released in 2015. Instead of many URLs, there's one endpoint, and the app sends a description of exactly the data it wants: "give me this customer's name, their last five invoices, and the status of each." The server assembles precisely that shape and returns it in one response.

Both get the job done. The difference is where the complexity lives and who pays for it.

Our default is REST, and here's why

Most business applications have one front end talking to one back end, built by one small team. The screens are known. The data shapes are known. In that world, REST's simplicity wins on every axis that affects your budget:

• Any developer can work on it. REST is universal knowledge. You will never struggle to find someone who can maintain a REST API. GraphQL narrows the hiring pool and adds a learning curve for every new person who touches the project.
• Less machinery. A REST endpoint is a route and a function. GraphQL needs a schema layer, resolvers, and client tooling before you've served your first byte. That's setup time you pay for and infrastructure that can break.
• Easier to debug and secure. With REST, caching, rate limiting, monitoring, and permissions map cleanly onto URLs, and the whole industry's tooling assumes that model. GraphQL pushes all of that inside a single endpoint, where each piece takes custom work. It also introduces its own failure modes, like a client writing a deeply nested query that hammers your database, which you then have to defend against with query-depth limits.
• Boring is a feature. Twenty years of REST means twenty years of solved problems. When something goes wrong at 4 p.m. on a Friday, you want the technology with a decade of Stack Overflow answers behind it.

Where GraphQL earns its complexity

GraphQL isn't hype. Facebook built it for a real problem, and if you have that problem, it pays for itself. The signals:

• Many different clients with different needs. A web app, an iOS app, an Android app, and a partner integration all consuming the same backend, each wanting different slices of the data. With REST you end up either sending everyone everything (wasteful, slow on mobile) or building custom endpoints per client (a maintenance mess). GraphQL lets each client ask for exactly what it needs from one schema. This is the canonical case.
• Deeply nested, interconnected data. If your screens routinely need "project, with its tasks, each task's assignee, and each assignee's current workload," REST forces either several round trips or bloated purpose-built endpoints. GraphQL fetches the whole tree in one request.
• Front end and back end teams that move at different speeds. With a GraphQL schema in place, front end developers can build new screens and pull new combinations of data without waiting for anyone to add an endpoint. On larger teams, that decoupling is real velocity.

Notice what those have in common: scale and variety. Multiple clients, multiple teams, sprawling data. If you're reading this as the owner of a business commissioning an internal tool or a customer portal, you almost certainly have one client and one team, and none of those pressures apply yet.

The costs people don't mention

When someone pitches GraphQL for a small project, ask what it's buying you. The honest ledger includes the debit side: more setup, more specialized knowledge, caching that no longer comes free from HTTP, and security work that REST gives you cheaply. On a big multi-client platform those costs amortize into nothing. On a two-screen internal tool, they're the most expensive part of the project.

The reverse mistake exists too. If a project genuinely has four client apps and everyone is drowning in one-off endpoints, insisting on REST out of habit means paying the mess tax forever. Tool choice follows the shape of the problem, not the résumé of the builder.

How to know the choice was made right

You don't need to referee this decision yourself. You need to hear a reason. Ask whoever's building your software why they picked what they picked. "REST, because you've got one app and one team, and it keeps maintenance cheap" is a good answer. "GraphQL, because you'll have a web app, two mobile apps, and a partner API sharing this backend" is also a good answer. "GraphQL, because it's what modern companies use" is the sound of your budget funding someone's learning project.

We build REST by default and reach for GraphQL when the client list and the data shape demand it. That's not a hot take. It's just matching the tool to the job, which is most of what good software work is.