DEV Community

Prasun Chakraborty
Prasun Chakraborty

Posted on • Edited on

Full Stack System Design 4 : GraphQL and gRPC

#fullstack #systemdesign #graphql #rpc

In our previous episode on REST APIs, we broke down how traditional APIs work from architectures and URLs to headers and status codes. We saw how REST keeps things simple and predictable using HTTP methods and resources. But as apps get more complex, REST can sometimes feel limiting. That's where alternatives shine. In this Episode 4, we'll explore GraphQL and gRPC.

A Quick History of GraphQL and gRPC

  • GraphQL started at Facebook in 2012 when they were dealing with mobile apps that needed flexible data without wasting bandwidth. The old REST way meant over fetching of extra info, which was bad for slow networks. They built GraphQL internally and then open sourced it in 2015. It quickly caught on because it let clients ask for exactly what they needed. Today, it's used by big names like GitHub, Shopify, and Netflix for complex UIs.

  • gRPC, on the other hand, came from Google around the same time, it evolved from their internal Stubby system and open sourced in 2015. It's built on HTTP/2 and uses Protocol Buffers for efficient data packing. Google needed something fast for microservices talking to each other, especially in data centers. Now, it's popular in cloud setups like Kubernetes, with companies like Uber and Square using it for backend to backend speed.

Both came out around the mobile boom and microservices trend, solving pain points REST couldn't handle well. But they're tools, not replacements, based on your system's needs.

What is GraphQL?

GraphQL is a query language for your API and a server side runtime that runs those queries against a type system you define for your data. Unlike REST with its many endpoints (like /users, /posts, /comments), GraphQL usually has just one endpoint, say /graphql and the client decides the data shape, not the server. You send a query like:

query {
  user(id: "1") {
    name
    posts(first: 3) {
      title
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

The server returns exactly that no more, no less:

{
  "data": {
    "user": {
      "name": "Prasun",
      "posts": [
        { "title": "Web Basics" },
        { "title": "Protocols" },
        { "title": "REST Deep Dive" }
      ]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

This is powered by a schema in Schema Definition Language (SDL) that defines types, like User and Post, with fields and relationships. Tools like Apollo or Relay handle the client side, making it easy to integrate with React or other frontends.

Why GraphQL? (Problem → Solution → Benefits)

In the 3-tier architecture we discussed in Episode 3, REST works well for simple use cases, but real world applications expose its limits especially as frontends grow more dynamic.

  • Over fetching is a common issue. Suppose your mobile app only needs a user’s name for a profile badge. A REST call like GET /users/1 often returns everything like email, bio, address, login history. That’s unnecessary data moving over the network, slowing performance on 3G connections and draining battery. With GraphQL, the client asks for exactly what it needs: 
{
  user {
    name
  }
}
Enter fullscreen mode Exit fullscreen mode
  • Under fetching is the flip side. A dashboard that shows user details along with recent posts might require multiple REST calls like GET /users/1, then GET /users/1/posts?limit=3. Each call adds latency and coordination overhead. GraphQL solves this by allowing nested queries, fetching all required data in a single round trip. This is especially valuable in full stack systems where frontend requirements evolve faster than backend APIs.

At its core, GraphQL acts like a surgical instrument for data access it's precise, flexible, and efficient. It doesn’t replace REST but it complements it where flexibility and performance matter most.

This design unlocks several key benefits:

  1. Declarative Data Fetching
    Clients explicitly describe the shape of the data they need. For example, the same API can return full post details for desktop views and lightweight summaries for mobile, without new endpoints or server changes.

  2. Strongly Typed Schema
    All data is defined in a shared schema schema.graphql. This enables IDE auto completion, early error detection, and tooling like GraphiQL. Think of it as TypeScript for your API that makes full stack development safer and more predictable.

  3. Introspection by Design
    GraphQL APIs are self describing. Clients can query the schema itself e.g.,__schema { types { name } }, making it easier to explore capabilities and evolve systems without breaking consumers.

  4. Faster Frontend Iteration
    UI teams can move independently. If the schema already exposes postViews, frontend developers can query it immediately no new endpoint, no backend redeploy. This dramatically shortens iteration cycles.

Top comments (0)