gRPC vs HTTP Explained in 3 minutes

Added: 2026-05-17

[00:00:00]Let's break down how gRPC is different from regular HTTP.

[00:00:03]Let's make one thing very clear. gRPC isn't replacing HTTP. In fact, gRPC actually runs on HTTP/2.

[00:00:10]So, to understand gRPC, we first need to understand how HTTP/2 works.

[00:00:14]Let's try to picture a back end of an Uber-style ride app.

[00:00:17]When a rider taps request a ride, the trip service has to make many calls. It calls the driver service to find nearby cars, the pricing service for the fare estimate, also the location service for real-time updates, and the notification service to ping the driver.

[00:00:29]One tap on screen by user can fan out to 15 or 20 internal service calls.

[00:00:33]And these services talk to each other constantly. We're talking about thousands of calls per second.

[00:00:38]Now, if these services talk over HTTP/1.1, things are not very smooth.

[00:00:42]Each connection only handles one request at a time.

[00:00:44]To make things run in parallel, you have to open more connections. But, each new connection means a fresh TCP and TLS handshake, around 100 milliseconds of overhead.

[00:00:53]And if one slow call gets stuck on a connection, everything behind it just waits in line. They call this head-of-line blocking.

[00:00:59]And HTTP/1.1 has one more problem.

[00:01:01]Every request resends the same headers as plain text.

[00:01:05]In a header, you'll have off tokens, trace IDs, user IDs, easily 500 bytes of data per request.

[00:01:10]Now, multiply that by thousands of calls per second. You're wasting bandwidth sending the exact same headers over and over.

[00:01:16]HTTP/2 fixes these problems. In HTTP/2, services keep one connection open between each other and send many requests through it at the same time.

[00:01:24]Each request gets its own stream, its own little channel inside that connection.

[00:01:28]And headers get compressed, too.

[00:01:30]After the first request, both sides keep a shared table. So, every repeat just sends a tiny number pointing to the cached value.

[00:01:36]That 500-byte header becomes a few bytes.

[00:01:38]On top of HTTP/2, gRPC adds two more things.

[00:01:42]First, how the data is packaged.

[00:01:44]Regular HTTP APIs send JSON. JSON is just text, which is easy for humans to read, but it is bulky.

[00:01:50]Instead of JSON, gRPC sends something called Protobuf. It is binary data, several times smaller than JSON, and faster for computers to read.

[00:01:58]When you're moving millions of messages per second between services, it makes a huge difference at scale.

[00:02:03]Second is the contract between the two services.

[00:02:05]With a regular HTTP API, you write down how to call API in some documentation.

[00:02:09]Sooner or later, the docs and the actual code stop matching.

[00:02:12]gRPC fixes this with one file. This is called.proto file.

[00:02:17]For our ride app, that file would say something like, "There's a driver service. It has a find nearby function.

[00:02:22]Give it a rider's location and it returns a list of nearby drivers."

[00:02:25]That single file becomes the agreement both services follow.

[00:02:28]From that one file, gRPC writes both the client code and the server code for you in whatever language you want.

[00:02:33]So, when the trip service needs nearby drivers, it just calls find nearby with the rider's coordinates, like calling any regular function in your code.

[00:02:40]Behind the scenes, gRPC turns that function call into a network request to the driver service.

[00:02:44]The call looks local, but it's actually going across the network. And that's what RPC means, remote procedure call.

[00:02:50]So, where do you use gRPC?

[00:02:52]You should use gRPC between your own back-end services.

[00:02:55]Browsers can't speak gRPC directly, so use regular HTTP for browser traffic.