What Is GraphQL?

GraphQL shows up in tech discussions as an alternative to the usual way of building APIs, often with an aura of being newer and smarter. The idea behind it is actually simple and solves a concrete problem, but it comes with a cost that’s just as important to understand. Here’s what GraphQL is, what problem it solves, and when it’s worth its complexity – without the hype.

The client asks, the server answers exactly

In a regular API, the client calls a fixed address and gets back whatever amount of data the server has decided that address should give. GraphQL flips the control: here the client sends a query describing exactly which fields it wants, and the server responds with precisely that – no more, no less.

Think of it as the difference between a fixed menu and an order where you specify every detail. Instead of receiving a finished dish with sides you might not want, you ask for exactly the parts you’re after. If the app only needs a user’s name and email, it asks for just that, and doesn’t get the whole user record thrown in.

The response also comes in the same shape as the query, which makes it predictable. The client knows what it asked for and therefore knows what it gets back.

The problem it solves: over- and under-fetching

GraphQL emerged from a real point of frustration, most visible in mobile apps, and it has two sides.

Over-fetching is when a call returns more data than needed. The app wanted a name but gets the whole profile with twenty fields. That wastes bandwidth and battery, and over a mobile connection it’s noticeable.

Under-fetching is the opposite. A call returns too little, so the app has to make several calls and piece together the responses to get what it needs. First a query about the user, then one about the user’s orders, then one about each order’s contents. Many round trips make the app slow.

GraphQL solves both at once. Since the client asks for exactly the fields it wants, in a single response, both the surplus and the need to stack calls disappear. A trimmed, combined data set is fetched in one go.

A minimal example

Say the app wants to show a user’s name and the titles of the user’s most recent orders. With GraphQL, it formulates a single query that says roughly: give me this user’s name, and for each order the title. The query lists just those fields.

The server responds with exactly that, and nothing else:

• name: Anna Svensson
• orders: “Winter jacket”, “Backpack”, “Water bottle”

No address, no extra data about the user, no separate calls for the orders. The client asked for a combined view and got it in one response, shaped by the query.

When the complexity is worth it

The flexibility is real, but it isn’t free. A GraphQL server is more complex to build and run, and requires extra care for both performance and security precisely because the client can ask open-ended questions. That cost needs to be paid for by a real need to be justified.

The rule of thumb is that GraphQL pays off when many different clients need different data views of the same information. If you have a mobile app, a website, and maybe partner integrations that each want different fields, or views assembled from several sources, the flexibility pays for itself. Each client fetches exactly the right data and can evolve at its own pace without the server constantly having to build new addresses.

If the clients are few and the data needs simple, though, GraphQL rarely justifies its complexity. Then a regular, simpler API does the same job at a lower cost. If someone proposes GraphQL, the reasonable question is therefore: what concrete problem does this solve for us?

At Weapp we build both GraphQL and simpler APIs and help you decide what fits your product. Check out our services or get in touch.