REST vs GraphQL: a real project shows the difference

TL;DR: On a food-delivery app, one order screen needs four separate network calls with REST and just one with GraphQL. REST is simpler to set up and caches for free; GraphQL saves data and time on slow connections. Most small teams should start with REST and switch only when a screen starts making four calls.

Your food app takes three seconds to open an order screen. The Wi-Fi is fine. The problem isn't the phone. It's how the app asks the server for data.

That's the whole REST vs GraphQL argument, in one screen.

The project: one screen, five pieces of data

Picture a small lunch-ordering app, the kind local kitchens use. One screen shows the kitchen's name and rating, three dishes with a photo and price each, the delivery estimate, and the driver's first name.

Nothing exotic. But on mobile data, every round trip to the server (send a request, wait, get an answer) costs 100–300 milliseconds. That's before a single byte of food data arrives.

How REST handles it: one address per thing

REST is the default way apps talk to servers. Each thing lives at its own web address, called an endpoint: /kitchens/12 for the kitchen, /kitchens/12/menu for the dishes, /orders/88 for the order.

That screen means four or five separate calls:

• Kitchen name and rating
• The menu, usually all 40 dishes, because the endpoint doesn't know you only show three
• Delivery estimate
• Driver details

Each call waits its turn. And the menu call downloads 40 dishes with 12 fields each, a big lunch for an app showing three items. Developers call that over-fetching: you ask for a little and get a lot.

How GraphQL handles it: one request, exact fields

GraphQL is a query language for APIs, built at Facebook and released publicly in 2015. It flips the model. Your app sends one request to one address and describes the exact shape of the answer it wants.

query OrderScreen($id: ID!) {
  order(id: $id) {
    kitchen { name rating }
    items(limit: 3) { name price photo }
    eta
    driver { firstName }
  }
}

One request, one wait. The server returns those fields and nothing else. On a weak 4G signal, that's often the gap between a screen that loads in a second and one that takes three.

The trade-off: the server does more work to assemble the answer, and it's harder to cache.

REST vs GraphQL: the trade-off that actually matters

REST wins the boring stuff. Every endpoint is a plain URL, so browsers and CDNs (networks of servers that keep copies of files in cities near your users) can cache the answer. A menu that changes once a day shouldn't hit your database 10,000 times.

GraphQL usually sends everything to one address with a POST request, so standard caching doesn't slot in. Teams add extra tools, such as saved queries and a client-side cache, to get that back.

REST also hands you free error codes: 404 means missing, 500 means the server broke. GraphQL answers 200 OK even when the query failed, so you have to read the response body.

When to use GraphQL, and when REST still wins

• Public API for outside developers? REST. Predictable, easy to document.
• Mobile app with many screens on slow networks? GraphQL earns its keep once one screen needs four calls.
• Internal admin panel? REST. Don't pay GraphQL's setup cost for five tables.
• Many teams, fast-changing data? GraphQL lets front-end teams add fields without waiting on a backend release.

What this means for your project

Start with REST. Less setup, free caching, and every developer you hire already knows it.

Watch for one signal: when a screen starts making four or more calls and pulling fields you never display, try GraphQL on that screen alone. You don't have to convert the whole app, since both can run side by side.

If you're hiring, ask which one they'd pick for a slow mobile app and why. Anyone who answers "GraphQL, always" hasn't been burned by caching yet.

Key Takeaways

• REST gives every thing its own URL; GraphQL sends one request and names the fields you want.
• REST caches easily and reports errors clearly; GraphQL needs extra tools to match that.
• GraphQL pays off on mobile screens that would otherwise make several calls.
• Most small teams should start with REST and move one screen at a time.

Frequently Asked Questions