RPC and gRPC Explained: Protobuf, HTTP/2, When to Use

Remote procedure calls in plain words: gRPC proto files, protobuf vs JSON size, HTTP/2 streaming, and why gRPC is used between internal services rather than…

RPC and gRPC: common questions

Why is gRPC faster than REST with JSON?

It sends Protocol Buffers, a compact binary format that uses field numbers instead of names and needs no text parsing, over HTTP/2, which reuses one connection for many calls and supports streaming.

Why not use gRPC for a public API?

Browsers cannot call gRPC directly without a translating proxy, and outside developers expect JSON over HTTP they can read and test easily. Keep REST outside and gRPC inside.

Related chapters

Keep learning

Overview

Lab: the same event, sent as JSON and as protobuf

The idea: call a function that lives somewhere else

REST thinks in things GET /events/123POST /events/123/bookings RPC thinks in actions GetEvent(id: 123)CreateBooking(eventId: 123, seats: […]) Neither is wrong. Actions feel natural inside a company where one team owns the booking service and another calls it like a library.

gRPC: the version most companies use

gRPC was made at Google and is now free for anyone. It has three parts. First, both teams agree on a contract file (a .proto file) that lists the functions and the exact fields of each message: gRPC also runs on HTTP/2, which lets many calls share one open connection and lets a call stream: send or receive a flow of messages instead of one. Facebook’s Thrift is an older tool built on the same idea.

Where it sits in a real system

The usual shape is REST (or GraphQL) on the outside and gRPC on the inside: Phone / browser speaks JSON REST: POST /events/123/bookings public API API gateway front door gRPC: CreateBooking(…) internal call Booking service then gRPC to payment The outside world sees REST. Behind the gateway, services call each other with gRPC. Why not use gRPC everywhere? Because browsers can’t call it directly without an extra translating proxy, and outside developers expect plain JSON over HTTP. Pick RPC when Avoid it when Browsers or outside companies call it directly. They want JSON they can read and test with simple tools.

All three side by side

RPC (gRPC) thinks in things (resources) the shape of data actions (functions) one URL per thing one URL for all data format protobuf (binary) best for public APIs, simple apps many screens, different needs service to service weak spot extra trips per screen caching, N+1, permissions browsers can’t call it easily

In the interview

Interviewers usually want only the public API on the board. Internal calls are not drawn as endpoints. Mention gRPC in one line when you draw the services: “The client-facing API is REST. Between the booking service and the payment service I’d use gRPC: both are ours, it’s fast, and the proto file gives us a typed contract.” That covers which style. The next chapter is about how well you design inside it: nine habits that separate a clean API from a messy one. Spotify’s Player endpoints read like remote commands: play, pause, next, with no ordering guarantee. The Player API

More courses

Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
React from open source with patterns — Patterns extracted from Material UI, Radix, React Aria, React Hook Form, Redux Toolkit, TanStack, and Next.js — not slides about hooks.
Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
Build a real API with NestJS — One ticket-booking API, built in order: a plain Node server first, then NestJS modules, validation, a real database, and the features real clients lean on.
Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
AI engineering for software engineers — Eight free reads, in order, for software engineers moving into AI: when to build an agent, how to build one, how to test it, and how the model works underneath.
Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
TypeScript in depth — The type system as a design tool. Inference, narrowing, generics, and the errors that mean the model is wrong — not a catalog of utility types.
CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
Accessibility — Foundations first (WCAG in plain words, semantic HTML, lists, alt text), then hands-on HTML labs, a full pass of WAI-ARIA 1.3, and a final fix-the-page challenge.
Docker — What an image is, why layers cache, and how containers find each other on a network.
Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.
Kubernetes — Kubernetes from zero to operators: why it exists, Pods, Deployments and Services, then configuration, networking, storage, scheduling, scaling and security.