REST or GraphQL — which to pick as a beginner, and why

Picture ordering food. REST is the set menu: you ask for "combo #3" and get the whole tray, even if you don't want the soup. GraphQL is ordering à la carte: you write exactly "borscht and compote, hold the main" and get only that, in one go. That's the whole REST-vs-GraphQL debate — who decides what ends up in the response: the server or you.

First — what these even are

REST and GraphQL are two styles for your frontend to talk to a server through an API. Both do the same thing: ask for data, get a response. The difference is the shape of the conversation.

• REST — a set of addresses (endpoints). Each data type has its own address: /users/42, /users/42/posts. Hit the address, the server hands back a pre-built "card" whole.
• GraphQL — one address and a query language. You describe in the request exactly which fields you want, and the server assembles a response to match.

The real difference in practice

Two REST pains a beginner feels fast:

• Over-fetching. You need one name, and /users/42 sends the address, the phone, the signup date too. You drag extra over the wire.
• Under-fetching. To build one screen you hit three or four addresses in sequence: the user, their posts, the comments on those. Several round trips.

GraphQL fixes both: one request, exactly the fields you want, pulled from related entities at once. But you pay for the flexibility with upfront complexity — defining a schema, learning the syntax, and the familiar "cache by address" no longer works so simply.

A straight comparison

| Criterion | REST | GraphQL | |-----------|------|---------| | Learning curve | Gentle — pick it up in an evening | Steeper — schema, types, resolvers | | Who decides the response shape | The server (fixed card) | You, in the request | | Requests per complex screen | Often several | Usually one | | Over/under-fetching | Happens regularly | You take exactly what's needed | | Caching | Simple, out of the box | Harder, needs tooling | | For a small project | Just right | Often overkill |

Who should pick what

No dodging.

• Beginner and first project — REST. It's simpler, every tool understands it, it's easier to debug and cache. 90% of side projects live happily on REST, and learning on it is the right first step. How to wire one up — in the how to connect an API guide.
• GraphQL — when REST's pain has become real. Complex screens pulling data from many places; a mobile app that mustn't download extra over cellular; many different clients with different needs for the same data. That's when the flexibility pays for the complexity.

A simple rule: don't pick GraphQL because it's "trendy." Pick it when you're tired of fighting over- and under-fetching on REST. If that pain is unfamiliar to you, REST is exactly what you need.

FAQ: Is GraphQL a replacement for REST or a layer on top?

It's a different style, not a "new version of REST." GraphQL is often placed as a layer over the same data REST serves. They coexist fine: some parts of a project on REST, others on GraphQL. It's not "either/or" for life.

FAQ: Is it true GraphQL is always faster?

No. One request instead of three saves network round trips — that's a plus. But the server still fetches the same data internally, and complex GraphQL queries can load it more heavily. "Faster" is about fewer client trips, not magic.

FAQ: Where do I start if I want to try GraphQL?

First build a couple of projects on REST — you'll learn which pain GraphQL actually solves. Then take a ready GraphQL service, describe a small schema of two or three entities, and build one screen. The contrast makes the difference obvious faster than any theory.