Backend for apps: REST API vs GraphQL, which to use

Every mobile app needs a backend to give it data: users, products, orders, whatever. The question is not whether you need one, but how your app talks to it. And that is where the two big approaches appear: the veteran REST API and the flexible GraphQL. Choosing well determines how much code you write, how much data the user spends and how fast your app feels.

REST is simple, standard and cacheable. GraphQL asks for exactly the data it needs, no more and no less. There is no absolute winner: there is a winner for your case.

What a REST API is

REST organizes everything into resources with URLs and HTTP verbs (GET, POST, PUT, DELETE). Each endpoint returns a fixed data structure. It is mature, universal, easy to cache and understood by any developer on the planet. Its price: sometimes it gives you more data than you need, or forces several calls to build a single screen.

What GraphQL is

GraphQL exposes a single endpoint and a query language: the client asks for the exact fields it wants and receives just that, in a single request even when it crosses several entities. A query reads almost like the result you expect:

query {
  producto(id: 10) {
    nombre
    precio
    categoria { nombre }
  }
}

The difference that really matters

REST’s classic problem is over-fetching (it returns more data than you use) and under-fetching (you need several calls for one screen). On mobile, with limited data and uneven networks, that weighs. GraphQL solves both: you ask for exactly what you need in a single call. In exchange, the server is more complex to set up and caching stops being as trivial as it is with REST.

REST vs GraphQL at a glance

When to use each

• REST if your API is simple, the resources are clear, you want easy HTTP caching or you will expose it to third-party integrations.
• GraphQL if you have many screens with different data, mobile devices with limited bandwidth, several clients (web and app) consuming the same thing or a front end that evolves quickly.

Many modern backends already give you both out of the box. We saw it when comparing Directus vs Strapi, which expose REST and GraphQL, and also in a headless WordPress with Next.js architecture, where the front end consumes whichever API you prefer.

What I would choose

What I would choose depends on the size of the project. For a simple app, with few data types and where I want caching and speed without complications, REST is still unbeatable for simplicity. But as soon as the app has many screens asking for different combinations of data, or when a website and an app share the same backend, GraphQL pays back its complexity many times over: fewer calls, less wasted data and a front end that evolves without asking the backend for a new endpoint every week. My practical advice: do not choose by fashion. If you doubt and the project is small, REST; if you already see the data will be varied and the app large, GraphQL from the start saves you a painful refactor.

Are you going to build an app or a product and do not know how to approach its backend? At Codegea we design and build custom REST and GraphQL APIs, made so your app runs fast and grows without being rebuilt. Tell me what you are building.