Skip to content

GraphQL vs REST: The API Battle

3 min read
APIGraphQLRESTWeb DevelopmentBackend
GraphQL vs REST: The API Battle

GraphQL vs REST: The API Battle

How does the Frontend (your React app running on an iPhone) talk to the Backend (the database running on a server in Virginia)?

They use an API (Application Programming Interface). But there are two dominant ways to structure this conversation: REST (the old reliable standard) and GraphQL (the modern challenger).

REST (The Restaurant Menu)

Think of REST like a standard restaurant menu. It has set items.

You order "Dish #4" (which represents a User Profile). The waiter brings you exactly what is described on the menu: Name, Age, Email, Photo, Address, and Bio.

The Problem 1: Over-fetching What if I only wanted the user's Name to display in a tiny header? I can't just order the "Name." I have to order "Dish #4." The server sends me the Photo, Address, and Bio anyway. I threw away 90% of the data I paid for. This wastes the user's battery and data plan.

The Problem 2: Under-fetching What if I also wanted the user's "Last 5 Posts"? That isn't included in "Dish #4." I have to call the waiter back and make a second order for "Dish #8" (User Posts). This causes a "waterfall" of network requests, making the app feel slow.

GraphQL (The Buffet / The Specific Request)

GraphQL changes the dynamic. It is like a customizable buffet request.

I tell the waiter: "Bring me ONLY the Name of the user, and the Titles of their last 5 posts."

The waiter brings exactly that. Nothing more, nothing less. All in one trip.

Why It Matters

For complex, data-heavy apps like the g-makris.com Dashboard, GraphQL is incredibly efficient. It allows the frontend to ask for exactly what it needs for that specific screen.

  • Efficiency: Smaller data payloads mean faster load times on slow mobile networks.
  • Flexibility: Frontend developers can change what data they use without asking the Backend team to rewrite the API.

However, it adds complexity. Caching is harder. Security is harder.

For simple features, REST is still robust and simple. I use a hybrid approach: REST for simple actions (logging in), and GraphQL logic (via Firestore queries) for complex data views.

Best,

Gerasimos Makris Founder of g-makris.com AI Web Developer | Double Master's in MBA & FinTech and Blockchain

Tech Glossary & Concepts

  • REST (Representational State Transfer): The traditional architectural style for designing networked applications. It relies on standard HTTP methods (GET, POST, DELETE).
  • GraphQL: A query language for APIs and a runtime for fulfilling those queries with your existing data.
  • Over-fetching: Downloading more data than is actually needed for the current screen, wasting bandwidth and battery.
  • Payload: The actual data sent in an API response (excluding the technical headers).
  • Latency: The delay before a transfer of data begins following an instruction for its transfer.
GM

About the Author

Gerasimos Makris

AI Web Developer & FinTech Specialist

View Resume

Gerasimos Makris is an AI Web Developer with a background in FinTech operations. He specializes in building secure, scalable web applications that solve real-world financial problems. When he's not coding, he enjoys exploring the intersection of technology, finance, and business strategy.

Share:

Valuing Your Privacy

We use cookies to optimize your experience, analyze site usage, and support personalization. By clicking “Accept All”, you consent to our use of cookies. Learn more in our Cookie Policy.