DEV Community: Anil BT

gRPC Explained: The Framework That’s Quietly Replacing REST

Anil BT — Fri, 11 Jul 2025 15:11:48 +0000

Introduction

Stop me if you’ve heard this one before: your team is building out a microservices architecture. You’re pushing more services into production, connecting them with REST APIs. Everything’s working until it isn’t. Suddenly, you’re chasing down inconsistent API definitions, your endpoints feel bloated, response times are creeping up, and debugging across services is a nightmare. You start wondering: Is there a better way to make services talk to each other?

That’s exactly the question that led many engineering teams to discover gRPC.

Originally developed at Google and now an open-source project under the Cloud Native Computing Foundation (CNCF), gRPC is a modern Remote Procedure Call (RPC) framework that’s gaining serious traction in the world of high-performance systems. It’s fast, strongly typed, and built on top of HTTP/2, using Protocol Buffers instead of JSON. But this isn’t just about a faster alternative to REST but it’s a shift in how we think about service communication.

I’ve written this guide to help you get a real, working understanding of gRPC. what it is, how it works, when it’s useful, and just as importantly, when it isn’t. You’ll walk away knowing whether it’s the right fit for your system, and if so, how to start making the transition with confidence.

Problem Statement

Imagine you're working on a platform with dozens of microservices. Your front-end apps need to talk to several back-end services. Your services talk to each other. Third-party apps call your APIs. Everything is RESTful until you hit scale.

At first, things are manageable. JSON payloads are readable. Endpoints are easy to test with Postman. You document your APIs with Swagger. But as the number of services grows and services starts to break.

When your services interaction grows. JSON responses grow larger, and parsing becomes slower. You start worrying about versioning. One team updates an endpoint and accidentally breaks another service. Your logs are filled with HTTP 500 errors, and it gets difficult to debug.

You start spending more time debugging your APIs than building new features. And you’re not alone.

Before we dive into the details, it’s worth saying: gRPC isn’t here to replace REST ( checkout blog post on How to Choose Between gRPC, GraphQL, Events, and More ). But it does solve many of the problems REST struggles with, especially in high performance, polyglot, service-heavy systems.

What is gRPC?

gRPC stands for google Remote Procedure Call. It’s an open-source framework that lets services communicate with each other as if they were calling functions directly across machines.

But what does that actually mean?

Let’s break it down.

Instead of sending a request to a URL and parsing a JSON response like with REST, gRPC lets one service call a function in another service directly, using strongly typed data and high-efficiency messaging.

It uses two key technologies under the hood:

Protocol Buffers (Protobuf):
A language-neutral, platform-neutral, extensible way of serialising structured data like JSON, but much smaller and faster. You define your messages and service interfaces in a .proto file. From that, gRPC generates client and server code in multiple languages.

HTTP/2:
This allows multiplexed streams, header compression, and persistent connections. In practice, it means gRPC is faster and more efficient than traditional HTTP/1.1 used in REST APIs.

Here’s what the workflow looks like:

You define a service and its methods in a .proto file.

You generate client and server code from that file.

Your client can now call methods as if they were local functions even though they’re running on a remote server.

// Instead of calling:
GET /users/123

// and getting back a JSON blob, with gRPC, you’d write:

rpc GetUser (UserRequest) returns (UserResponse);

// and then call GetUser(userId) like a normal function.

This approach makes communication between services faster, more structured, and easier to maintain especially in large, complex systems.

But gRPC isn’t just about speed. It’s about consistency, tooling, and the confidence that what your client expects is exactly what your server delivers.

gRPC vs REST: The Real Differences
gRPC and REST might seem like two ways of doing the same thing getting data from one service to another. But under the hood, they work in very different ways. Understanding those differences is key to deciding when gRPC makes sense for your stack.

Let’s break down the major contrasts.

REST v/s gRPC

When gRPC works better
gRPC isn’t a silver bullet, but in the right conditions, it’s a serious upgrade over REST. Here’s where it really earns its place.

Microservices at scale : When you have dozens or hundreds of microservices talking to each other, gRPC provides a clear, structured way to define and maintain those interactions.

Polyglot Systems : Got services in Go, clients in Python, and some legacy modules in C++? gRPC lets them all speak the same language that’s Protocol Buffers. It doesn’t care what language your service is written in. It just works.

High-Performance Requirements : Speed matters. gRPC’s binary encoding (via Protobuf) and HTTP/2-based transport make it significantly faster than REST for both latency and payload size. If your app demands low latency say, for video streaming, financial transactions, or IoT sensors then gRPC is a great fit.

gRPC supports native streaming:

Client streaming: send a stream of data to the server.
Server streaming: get a stream of responses back.

Bidirectional streaming: both happen at once.

This makes it ideal for chat apps, live dashboards, gaming backends, and real-time analytics.

Clear API Contracts and Strong Tooling : In gRPC, your .proto file is the single source of truth. You don’t just write docs you write definitions that generate client and server code, API docs, mocks, and more.

Internal APIs (Not Public Ones) : gRPC isn’t designed for browser-facing, public APIs. But for service-to-service communication inside your infrastructure. It’s how companies like Google and Netflix handle billions of internal calls per day.

In short, gRPC shines when you need performance, structure, and scale—especially behind the scenes where services talk to each other, not to browsers.

Where gRPC doesn’t work
For all its strengths, gRPC isn’t perfect. Like any tool, it has trade-offs and knowing them is key to making the right choice for your project.

1. Limited Browser Support

gRPC doesn’t run natively in most browsers because it uses HTTP/2 with binary encoding, which browsers don’t fully support. While gRPC-Web exists, it requires a proxy to translate between gRPC and HTTP/1.1/JSON.

Why it matters: If you’re building a public-facing web app, you’ll likely need workarounds or you might be better off sticking with REST.

2. Debugging and Tooling Complexity

Debugging gRPC isn’t as straightforward as REST. You can’t just pop open a browser and test an endpoint. You’ll need specialised tools like grpcurl, Postman’s gRPC support, or language-specific clients.

Why it matters: Developers used to the simplicity of curl or browser-based testing might find gRPC’s tooling less approachable at first.

3. Binary Format = Less Human-Friendly

Protobuf is efficient, but not readable. You can’t quickly glance at a response in the terminal or browser like you can with JSON. This adds friction for quick debugging or inspection.

4. Overkill for Simple APIs

If you’re building a small app or a handful of endpoints, gRPC might be over-engineering. The setup, learning, and tooling might not justify the gains especially if performance isn’t a bottleneck.

gRPC is powerful, but it’s not a drop-in replacement for REST. It’s designed for systems that need efficiency, structure, and scale not for every single web API.

Real-World Use Cases
Google invented gRPC and has used it internally for years. Nearly all of their internal APIs are powered by gRPC, running over their internal RPC framework called Stubby. It’s part of how they handle massive inter-service communication across data centres.

Netflix uses gRPC to manage service-to-service communication in its microservice-heavy architecture. Their move to gRPC helped improve the performance of high-throughput systems, like those used for playback and metadata services.
ref: Netflix Ribbon

CockroachDB distributed SQL database uses gRPC for internal node-to-node communication. The performance and binary efficiency of gRPC are critical for the kind of speed and resilience CockroachDB promises.
ref: CockroachDB blog

Why These Examples Matter

These aren’t niche edge cases. These are companies where scale, speed, and maintainability aren’t “nice-to-haves” they’re dealbreakers. The fact that they’ve standardised on gRPC speaks volumes about its real-world utility.

Final Thoughts

gRPC isn’t just a performance boost or a trendy tech term, it’s a reflection of how modern systems are evolving. As we move towards increasingly distributed, real-time, and language-diverse architectures, tools like gRPC become more than nice-to-haves. They become essentials.

That said, it’s not a one-size-fits-all solution. REST is still a solid choice for public APIs, browser-based clients, and simpler use cases. But if you’re building a system with internal services, cross-language support, high-throughput demands, or real-time communication, gRPC might just be the shift your architecture needs.

In the end, understanding the trade-offs speed vs simplicity, structure vs flexibility. Hopefully, this deep dive gave you a clear lens on when gRPC is worth your attention and when it’s not.

Beyond REST: How to Choose Between gRPC, GraphQL, Events, and More

Anil BT — Fri, 11 Jul 2025 15:07:18 +0000

When REST Stops Being Enough

At first, REST felt like the perfect choice.

Our first micro service was straightforward just JSON over HTTP. Frontend devs loved how easy it was to use. Backend engineers appreciated the simplicity. It seemed REST could do no wrong.

But our systems grew. Suddenly REST wasn’t enough. Each new client added complexity. Endpoints got crowded, fetching turned chatty, versioning politics surfaced, and deployments frequently disrupted existing users.

We’d reached REST’s breaking point but not because it was bad, but because we needed it to handle scenarios it wasn't built for.

We realized REST was just one of several powerful API paradigms. Our journey led us beyond REST, exploring GraphQL, gRPC, and event-driven architectures. Here's what we discovered and how you can pick the right tool at the right time.

for example: Below diagram shows a client requesting user data via clearly defined endpoints. Data travels back synchronously in simple JSON.

// REST Call
GET /users/123
Response → {id:123, name:"John", email:"john@example.com"}

GraphQL: Frontend Flexibility

REST has fixed endpoints. The backend decides what data clients can access. But what if your frontend needs to combine data from multiple services to render a single screen?

We had this exact issue and dashboard needing data from five distinct services. REST calls piled up quickly, adding complexity and latency.

GraphQL solved that. It reversed the control. Instead of backends deciding data structures, frontends could precisely define their data queries. One clear request gave us exactly what we needed.

But freedom always comes at a price. GraphQL forced us to carefully optimize backend resolvers and watch out for query complexity.

Ideal For:

Complex UIs needing flexible data shaping

Reducing frontend-backend friction and roundtrips

for example: Below diagram shows client fetches customized data from multiple services in one query, reducing multiple round trips and excess data.

// GraphQL Query
query {
  user(id: "123") {
    name
    orders(limit: 3) {
      id
      total
    }
  }
}

gRPC: Fast Internal Pipes

Internally, things moved fast and really fast. One of our billing processes was making over 100,000 REST calls per minute. REST’s overhead was killing performance.

Switching to gRPC drastically cut latency nearly halving it overnight. Protocol Buffers streamlined payloads into efficient binaries, and schema-first contracts made APIs clearer.

However, gRPC wasn't as intuitive as REST. Debugging required more advanced tooling, and onboarding new developers became a bit harder.

Ideal For:

High-performance, internal microservice communication

Latency-sensitive use-cases

for example: Below diagram illustrates internal services communicating rapidly using lightweight binary payloads and well-defined schemas.

// gRPC Service Definition
service BillingService {
  rpc GetInvoice (InvoiceRequest) returns (InvoiceResponse);
}

Event-Driven: Decoupling at Scale

One day, a simple missed webhook triggered cascading failures across our system. Tight coupling was dangerous, and REST couldn’t fix that.

We shifted towards Kafka and event-driven architecture, enabling loose coupling through asynchronous messaging. When a new user signed up, events triggered parallel, independent processes: sending emails, initiating billing, and logging analytics without direct inter-service calls.

Still, this flexibility introduced complexity. Monitoring asynchronous chains demanded new observability strategies. Guaranteeing event order and handling duplicates took serious effort.

Ideal For:

Decoupled services with asynchronous workflows

High scalability, fault tolerance scenarios

for example: Below diagram shows user signup publishes events asynchronously, triggering multiple independent services without direct coupling.

// Event-driven: Publishing an Event
on userSignup(userId):
  kafka.publish("user.signup", { userId: userId })

// Event-driven: Subscribing to an Event
kafka.subscribe("user.signup", event => {
  sendWelcomeEmail(event.userId);
  initiateBilling(event.userId);
})

REST: Simplicity Still Matters

Despite everything, REST remained useful. Public-facing APIs, simple CRUD operations, and straightforward integrations still benefited greatly from REST's clarity.

We didn’t abandon REST, we just became smarter about when and how to use it.

Ideal For:

Public-facing APIs with clear documentation

Simple, predictable data exchanges

Conclusion: Architecture Defines Your Company

Moving beyond REST didn't mean discarding it entirely. it meant carefully complementing it. Every API strategy reflects your organization's priorities, team structures, and scaling requirements.

Ultimately, choosing between REST, GraphQL, gRPC, and event-driven models isn't about selecting the best paradigm universally, but rather identifying the ideal tool for each unique situation.

Our journey began with REST, but it evolved as we recognized our growing needs. What's yours?

The Two C's: Clearing Up “Consistency” in ACID vs CAP

Anil BT — Fri, 11 Jul 2025 14:57:26 +0000

“Wait… isn’t consistency just consistency?”

Not quite - and that’s where many developers get tripped up.

If you’ve ever tried to wrap your head around ACID and CAP Theorem, you’ve probably run into the term consistency in both. But despite the shared name, they mean very different things depending on the context.

In this post, we’ll break down what Consistency means in ACID vs CAP, and why understanding the difference is key when you’re designing, using, or scaling a system.

C in ACID: Data Integrity Within a Database

Let’s start with ACID, which stands for:

Atomicity
Consistency
Isolation
Durability

These properties are guarantees provided by relational databases (like PostgreSQL or MySQL) to ensure that transactions are processed reliably.

So what does Consistency mean here?
Consistency in ACID means:

“The database goes from one valid state to another.”

This ensures that all business rules, constraints, and triggers are respected. If a transaction violates any rule (like a foreign key constraint), the entire transaction is rolled back — no partial updates, no funny business.

Example:

If you’re transferring ₹100 from Account A to Account B, the database ensures that:

Account A is debited ₹100
Account B is credited ₹100

And no money vanishes or appears out of thin air

If something fails halfway, the system rolls it all back - keeping your data consistent.

C in CAP: Agreement Across a Distributed System
Now let’s jump to the CAP Theorem, which is about distributed systems and tradeoffs. CAP stands for:

Consistency

Availability

Partition tolerance

According to the theorem, in the face of a network partition, you can only guarantee two out of three properties.

So what is Consistency in this context?

Consistency in CAP means:
“Every node sees the same data at the same time.”

In a distributed system, multiple nodes may store copies of your data. CAP Consistency ensures that when you read from any node, you get the most recent write — no stale data, no surprises.

Example:

Imagine you’re posting a comment on a blog, and your comment shows up instantly on your device. If someone else visits the blog a second later, CAP Consistency guarantees they see it too - even if they hit a different server.

Key Difference at a Glance
Context:
In ACID, consistency applies to single-node database transactions (like in PostgreSQL or MySQL).
In CAP, consistency is about distributed systems where data lives on multiple nodes.

Focus:
In ACID, consistency ensures data integrity, meaning your data respects all defined rules (like foreign keys, triggers, constraints).

In CAP, consistency ensures that every node in the system reflects the same data - you won’t read outdated or conflicting values, even if requests go to different servers.

Failure Handling:

In ACID, if something breaks during a transaction, the system will roll it all back, preserving a clean, valid state.

In CAP, in case of a network partition or failure, systems must choose between being available or remaining consistent - leading to possible stale reads if consistency is sacrificed.

Real-World Example:

In ACID, Transferring money between two bank accounts - both the debit and credit must succeed together.

In CAP, Posting a comment on a social app - and expecting it to show up immediately for every user, regardless of which server they hit.

Why It Matters
When you’re designing systems, especially microservices or distributed architectures, understanding the two types of consistency helps you make smarter trade-offs.

If you’re using a traditional SQL database, ACID consistency helps maintain trustworthy, validated data.

If you’re scaling out with NoSQL or distributed data platforms, you’ll likely be making choices around CAP consistency - sometimes trading it for higher availability (like eventual consistency).

Final Thought
The next time someone brings up “consistency” in a system design interview or a team meeting, ask yourself:

“Are we talking about data correctness within a single database or about agreement across distributed nodes?”

It’s a small difference in terminology - but a huge difference in practice.

If this helped clarify the difference, share it with a fellow engineer who’s ever confused the two C’s. And if you’ve got questions or real-world examples, I’d love to hear from you in the comments.