gRPC vs REST: Building a Ride-Sharing App Backend! 🚀

Added: 2026-05-28

[00:00:00]Let's compare gRPC with RESTful APIs.

[00:00:02]Picture the back end of a ride-sharing app like Uber. 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:16]Let's see how gRPC and a RESTful API each handle it.

[00:00:19]With a RESTful API, the trip service makes an HTTP call to driver service, something like post/drivers/nearby with a JSON body carrying the rider's details like latitude, longitude, and search radius.

[00:00:30]Driver service replies with a JSON array of nearby drivers. You can curl this endpoint from your laptop and read the response. Basically, anyone on the team can debug it without any special tool.

[00:00:38]That's the biggest strength of REST API.

[00:00:40]Everything is human-readable text. But here's the thing. We are using JSON here, and JSON response is bulky. A list of 50 nearby drivers easily becomes 10 kilobytes of text, and every request resends the same details like auth headers, trace IDs, and user IDs. This is around 500 bytes of plain text overhead on every single call.

[00:00:57]Now, multiply that by thousands of trips per second across thousands of services.

[00:01:01]It's definitely not very efficient.

[00:01:03]With gRPC, that same find nearby call sends Protobuf instead of JSON. Same 50 drivers probably need only 2 kilobytes instead of 10 kilobytes. Because gRPC runs on HTTP/2, headers get compressed, too. After the first call, repeat headers shrink down to a few bytes. At Uber scale, that makes a huge difference.

[00:01:20]Now, let's talk about the contract. With a RESTful API, the agreement between trip service and driver service lives in documentation. This documentation can be an OpenAPI spec, maybe a Confluence page, or something else. And honestly, the docs in the code stop matching the moment someone is in a rush.

[00:01:34]gRPC handles the contract with the dot proto file. One file says, "Driver service has a find nearby function. It takes a location as input, and then returns a list of drivers."

[00:01:43]Both teams generate their client and server code from that same file. If driver service changes the contract, the trip service's code literally won't compile until it updates. The contract isn't documentation here. It's actually enforced by the compiler.

[00:01:55]gRPC and REST also differ in streaming.

[00:01:57]For our ride app, the location service has to push the driver's GPS coordinates to the rider's phone every 2 seconds.

[00:02:02]With REST, you either pull the endpoint every 2 seconds, which is resource-heavy, or you rely on WebSockets, which is basically a second protocol running alongside your API.

[00:02:10]With gRPC, you get streaming already built in. The location service opens one stream and pushes updates as they happen over the same connection it was already using.

[00:02:17]But there is one part people don't pay attention to. The rider's phone and the rider's browser can't speak gRPC directly. Browsers don't expose HTTP two streams to JavaScript the way gRPC needs them. So, even at companies that love gRPC, the mobile app and the website still call a RESTful API.

[00:02:32]That REST endpoint then turns around and calls the internal services over gRPC.

[00:02:36]So, which one wins? Honestly, neither does. Most real companies use both. gRPC sits in the internal communication, where trip service, driver service, and pricing service talk to each other at scale.

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