System Design #23 — GraphQL

System Design #23 — GraphQL

“Instead of the server deciding everything, GraphQL allows the client to ask for exactly what it needs.”

In the previous article, we understood REST APIs. We saw that REST APIs organize data as resources like users, accounts, transactions, and cards. The client uses HTTP methods like GET, POST, PATCH, and DELETE to interact with these resources. REST is simple and widely used. But as applications grow, some problems can appear.

Let’s understand them with our banking application. Suppose the mobile app needs to show the home screen. The home screen may need: User name, Account balance, Last 5 transactions, Active cards, Loan summary, Latest offers

In REST, we may need to call multiple APIs:

GET /user/101

· GET /accounts/123/balance

· GET /accounts/123/transactions

· GET /cards

· GET /loans

· GET /offers

This can create many network calls. This is called under-fetching. Under-fetching means one API does not give enough data, so the client has to call more APIs.

Now another problem can happen. Suppose the client only needs the user’s name and account balance. But the REST API returns full user details and full account details. Now the client receives more data than it actually needs. This is called over-fetching. Over-fetching means the API sends extra data that the client does not need.

GraphQL was created to solve these kinds of problems. GraphQL is an API query language that allows the client to ask for exactly the data it needs. In simple words, GraphQL gives more control to the client.

Instead of the server saying, “This is the fixed response,” the client says, “I need only these fields.” Let’s understand this with our banking example.

In a physical bank, suppose you go to the cashier and ask: Please give me my name, current balance, and last 5 transactions. The cashier gives only that information. You do not receive your full KYC file, all loan history, all card details, and unnecessary documents. You asked for specific information. You got specific information.

This is the basic idea of GraphQL. Now let’s compare REST and GraphQL simply.

In REST, we usually have multiple endpoints.

· GET /users/101

· GET /accounts/123

· GET /transactions

In GraphQL, we usually have one endpoint. POST /graphql

The client sends a query describing what data it needs.

For example:

query {

user(id: 101) {

name

account {

balance

lastTransactions {

amount

date

}

}

}

}

The server returns only the requested data.

{

“user”: {

“name”: “Ojasva”,

“account”: {

“balance”: 9000,

“lastTransactions”: [

{

Get Ojasva koolwal’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

“amount”: 1000,

“date”: “2026–07–24”

}

]

}

}

}

Notice something important.

The client asked only for name, balance, amount, and date. The server returned only those fields. This is the main power of GraphQL. Now let’s understand some important parts of GraphQL.

The first part is Schema. A schema defines what data is available and how it is connected.

For example, a banking GraphQL schema may define: User has Accounts, Account has Transactions, Account has Cards, User has Loans The schema is like a menu. It tells the client what can be requested.

The second part is Query. A query is used to read data. For example: Get user name and balance

The third part is Mutation. A mutation is used to change data. For example: Transfer money, Update profile, Create card request In REST, we may use POST, PATCH, or DELETE for changes. In GraphQL, we use mutations.

The fourth part is Resolver. A resolver is the backend function that fetches the data for a field. For example, if the client asks for user balance, the resolver knows how to get that balance from the database or another service.

GraphQL Query

↓

Resolver

↓

Database or Service

↓

Response

Now let’s understand the benefits of GraphQL. The first benefit is avoiding over-fetching. The client gets only the data it asks for.

The second benefit is reducing under-fetching. The client can request related data in one query instead of calling many endpoints.

The third benefit is flexibility. Different clients can ask for different data. For example, a mobile app may need less data because the screen is small. A web dashboard may need more data because the screen is larger. Both can use the same GraphQL API but request different fields.

The fourth benefit is strong typing. GraphQL schemas define data types clearly, so clients know what kind of data to expect.

Now let’s understand where GraphQL is useful. GraphQL is useful when the frontend needs flexible data. It is useful when different clients need different fields. It is useful when one screen needs data from multiple resources. It is useful when REST APIs are causing too many network requests.

For example: Mobile apps, Dashboards, Complex frontend applications, Apps with many connected resources

But GraphQL is not always better than REST. This is very important. GraphQL also has challenges.

The first challenge is complexity. REST is usually easier to understand for beginners. GraphQL needs schema, queries, mutations, resolvers, and more planning.

The second challenge is performance. Because the client can ask for nested data, one query can become very heavy. For example, a client may ask for user, accounts, transactions, cards, loans, offers, and many nested things in one query. If not controlled, this can put heavy load on the backend.

The third challenge is caching. REST APIs are often easier to cache because they use different URLs.

For example: GET /accounts/123 This can be cached more easily.

But GraphQL usually uses one endpoint: POST /graphql

So, caching needs more careful handling.

The fourth challenge is security. If clients can ask for flexible data, we need to control what they are allowed to access. For example, a user should not be able to request another user’s private banking data.

So, permissions and query limits are important. Now let’s compare REST and GraphQL simply.

REST: Multiple endpoints, Fixed responses, Simple caching, Easy to understand

GraphQL: Single endpoint, Flexible responses, Client asks exact fields, More control, but more complexity

Now let’s connect this with our banking application. If our banking app has simple screens and simple requirements, REST may be enough.

For example: Check balance, View profile, Show transactions

REST can handle this easily. But if we have a complex dashboard that needs data from many places, GraphQL can be useful.

For example: User summary, Account balance, Recent transactions, Loan status, Card usage, Offers, Notifications

Instead of calling many REST APIs, the client can ask for exactly the required data in one GraphQL query.

So, the choice depends on the system. REST is not old or bad. GraphQL is not magic. Both are tools. A good engineer chooses based on the problem.

In this article, we understood that GraphQL allows clients to ask for exactly the data they need. It helps reduce over-fetching and under-fetching, but it also introduces complexity, performance concerns, caching challenges, and security considerations.

In the next article, we will understand WebSockets, which help when the server needs to send real-time updates to the client.