In our last post, we discussed the API Gateway as the “Head Waiter” of your software architecture. But how exactly do you place your order with that waiter?
For a long time, there was really only one standard way to talk to a server: REST. It was the industry standard—reliable, predictable, and rigid.
But as mobile apps became more complex and data-heavy, developers at Facebook realized the old way was too slow. They needed something faster and more precise. So, they built GraphQL.
Today, we explore the difference between these two data-fetching giants using the simplest analogy possible: Fast Food.
REST: The “Combo Meal” Menu
REST (Representational State Transfer) is the classic architectural style for APIs.1 It is organized into “Endpoints” (URLs).2 Each endpoint represents a specific resource, like a User, a Product, or an Order.3
If you want data, you have to hit the specific endpoint for that data.
Real World Analogy: The Fixed Menu
Imagine you go to a burger joint where the menu is strictly set.
- You order Meal #1 (The User Profile).
- The waiter brings you the entire plate: The Burger (Name), The Fries (Email), The Drink (Address), and the Coleslaw (Profile Picture).
The Problem (Over-fetching):
What if you only wanted to know the user’s Name? Too bad. With REST, you get the whole plate. You are wasting bandwidth downloading the “Fries” and “Drink” (Address and Email) even though you throw them away immediately.
The Problem (Under-fetching):
What if you want the user’s Name and their last 5 Orders?
REST usually doesn’t put those on the same plate. You have to:
- Order Meal #1 (Get User ID).
- Then order Meal #5 (Get Orders for that ID).
You have to make two trips to the counter.
REST is great because it is simple and cacheable, but it can be inefficient. You often get too much data or have to make too many calls to get what you need.
GraphQL: The “Build-Your-Own” Buffet
GraphQL is a query language for APIs.4 Instead of having many “Endpoints” (URLs), it usually has just one.
You don’t ask for a “Meal #1.” You send a specific query describing exactly what you want, and the server builds that exact JSON response for you.
Real World Analogy: The Salad Bar / Chipotle
Imagine a restaurant with a blank order form.
You tell the chef: “I want a User. But I ONLY want the Name. And I want their last 3 Orders. But for the orders, I only want the Total Price.”
The Chef (GraphQL) looks at your custom list, runs around the kitchen, grabs exactly those specific items, puts them on a single tray, and hands it to you.5
- No Over-fetching: You didn’t get the user’s address (The Fries) because you didn’t ask for it.
- No Under-fetching: You got the User info and the Order info in a single trip.
Why isn’t everyone using GraphQL?
If GraphQL is so precise, why do people still use REST?
- Complexity: Setting up a “Fixed Menu” (REST) is easy. Setting up a “Custom Chef” (GraphQL) who can handle any combination of requests is hard. It requires more engineering upfront.
- Caching: Since every REST request is standard (Meal #1 is always Meal #1), it’s easy for browsers to save (cache) that data. Since every GraphQL request is unique, caching becomes much trickier.
- Security: If you let customers ask for anything, a malicious actor might ask for a “nested query” so deep it crashes your server (e.g., “Give me the user’s friends, and their friends, and their friends… infinity”).6 You need guardrails.
Summary
- REST is like a standard menu. Reliable, cacheable, but inflexible. You get what you get.
- GraphQL is like a personal shopper. Precise, efficient, but complex to manage. You get exactly what you ask for.
For simple apps, REST is often fine. for complex apps (like Facebook, Shopify, or GitHub) where you have complex relationships between data, GraphQL is a lifesaver.