GraphQL in the Application Layer
GraphQL is an API paradigm introduced by Facebook (around 2015) to solve data-fetching inefficiencies common in REST-based systems.
Like REST:
- It sits at the application layer
- It usually runs over HTTP
- It is used for service-to-client communication
Unlike REST:
- The client controls the shape of the data
- The server exposes a schema, not fixed endpoints
Summary
GraphQL lets clients ask for exactly the data they need — no more, no less.
The Core Problem GraphQL Solves
Most real systems have:
- frontend teams (web, mobile)
- backend teams (databases, APIs)
These teams evolve at different speeds.
Common Problems With REST
1. Under-Fetching
- Frontend needs data from multiple endpoints
- Results in many API calls
- Increases latency and complexity
Example:
- Fetch list of users
- Fetch profile for each user
- Fetch groups for each user
→ 1 + N + N calls
Warning
Under-fetching increases round trips and slows page loads.
2. Over-Fetching
- Backend sends extra fields “just in case”
- Frontend only uses a small subset
- Wastes bandwidth and processing time
Warning
Over-fetching bloats responses and hurts performance, especially on mobile.
3. Endpoint Explosion
- New page = new API
- Aggregation endpoints grow complex
- Backend becomes hard to maintain
Summary
REST struggles when frontend data needs change frequently.
GraphQL’s Key Idea
Instead of:
- Server deciding response shape
GraphQL lets:
- Client describe exactly what data it wants
- Server returns data in that shape
The backend exposes:
- A schema (types, fields, relationships)
The frontend sends:
- A query describing required fields
Analogy:
GraphQL is like ordering food by listing ingredients instead of choosing a fixed combo meal.
GraphQL Query Anatomy (Conceptual)
A GraphQL query:
- Selects fields
- Can nest related objects
- Can include parameters
- Returns JSON shaped like the query
What the query expresses:
- Data requirements
- Relationships
- Structure of the response
Important
The response shape mirrors the query shape.
Why GraphQL Reduces Over- and Under-Fetching
With one query:
- Frontend fetches all required data
- Backend sends only requested fields
- No extra round trips
- No unused data
This is especially valuable for:
- Complex pages
- Mobile apps
- Slow or expensive networks
GraphQL Execution Model (High Level)
Behind the scenes:
- Query is parsed
- Validated against schema
- Executed via resolvers
- Data assembled and returned
Each field:
- May trigger custom backend logic
- May hit databases or services
Important
GraphQL shifts complexity from endpoints to query execution.
Where GraphQL Shines
GraphQL is a great fit when:
- Frontend requirements change often
- Multiple clients need different data shapes
- Mobile apps need to minimize data transfer
- Many teams query overlapping data
Typical use cases:
- Large web apps
- Mobile apps
- Dashboards with many views
- Products with rapid iteration cycles
Summary
GraphQL optimizes for frontend flexibility and developer velocity.
Tradeoffs and Backend Complexity
GraphQL is not free.
Backend challenges:
- Query execution can be expensive
- Deeply nested queries can be slow
- Resolvers can cause hidden N+1 queries - this is solved by dataloader, batch requests
- Caching is harder than REST
Sometimes:
- GraphQL ends up reintroducing complex aggregation logic
- Performance tuning becomes non-trivial
Warning
Poorly designed GraphQL schemas can hurt backend performance badly.
GraphQL in System Design
Interview reality:
- Requirements are usually fixed
- Interviewer wants to see clear data access patterns
- REST endpoints are easier to reason about
As a result:
- GraphQL benefits are less obvious in interviews
- Discussing resolvers may distract from core design
Important
REST is the default in interviews unless flexibility is explicitly required.
When to Bring up GraphQL
GraphQL makes sense if:
- Requirements are intentionally vague
- Frontend must adapt rapidly
- Many clients need different views of the same data
Good interview phrasing:
- “If client requirements are highly dynamic, we could consider GraphQL”
- “GraphQL helps avoid over- and under-fetching here”
GraphQL vs REST (Mental Comparison)
| aspect | rest | graphql |
|---|---|---|
| endpoints | many | usually one |
| response shape | server-defined | client-defined |
| over-fetching | common | avoided |
| under-fetching | common | avoided |
| caching | easy | harder |
| backend simplicity | simpler | more complex |
Mental Model for Revision
- REST = Server defines responses
- GraphQL = Client defines responses
- Schema = Contract
- Query = Data shape
- Resolvers = Execution logic
- Flexibility ↔ Complexity tradeoff
Summary
GraphQL trades backend simplicity for frontend flexibility — powerful when requirements move fast, unnecessary when they don’t.