gRPC Basics — Why Not REST

There is a moment in every developer's life when a technology that seemed perfectly adequate suddenly reveals itself as the bottleneck. Not broken. Not wrong. Just slow enough, just limited enough, that it is now the thing standing between you and the next level of performance. For me, that technology is REST.

REST has been the backbone of my bot's communication with the Solana blockchain. JSON payloads over HTTP. Request-response. Poll for updates, parse the response, act on the data. It works. It has always worked. Millions of applications across the internet run on REST, and they run fine. But "fine" is a dangerous word in the MEV world, because "fine" means "not fast enough to win."

The difference is something like the difference between texting and sending postal mail. Both deliver messages. Both are reliable. Both get the job done eventually. But when you need a response in the next three seconds, you do not reach for an envelope and a stamp. You reach for your phone. REST is the postal mail of API communication — structured, well-understood, universally supported, and too slow for a conversation that is happening in real time.

The Weight of JSON

Every REST request my bot makes carries a payload formatted in JSON. JSON is human-readable, which is its greatest strength and its most expensive weakness. When I send a request to an RPC endpoint, asking for account data, the response comes back as a blob of text. Field names are spelled out in full. Strings are quoted. Numbers are rendered as ASCII characters. Nested objects add layers of curly braces and indentation. The data itself might be a hundred bytes of useful information, but the JSON wrapper around it is three hundred bytes of structural overhead.

This is the difference between a handwritten letter and shorthand. A handwritten letter spells everything out: "Dear recipient, I am writing to inform you that the balance of your account is one thousand and forty-seven dollars and thirty-two cents. Please find attached the relevant documentation." Shorthand says: "bal: 1047.32." Same information. A fraction of the space.

Protocol Buffers — Protobuf, the serialization format that gRPC uses — is the shorthand version. Instead of self-describing text where every field carries its own name and type, Protobuf uses a pre-agreed schema. Both the sender and receiver know the structure of the message before it is sent. The sender writes the data as a compact binary representation — just the values, in the order the schema specifies. The receiver reads the binary blob, applies the same schema, and reconstructs the full message with every field, type, and name intact.

The size difference is not subtle. In some benchmarks comparing equivalent payloads, Protobuf binary messages are approximately five to ten times smaller than their JSON equivalents, though results vary by data type and schema complexity. For a single request, that difference is trivial. For a bot that sends and receives thousands of messages per second, it is the difference between a garden hose and a fire hydrant. Every byte eliminated is CPU time saved on serialization. Every byte eliminated is network bandwidth reclaimed. Every byte eliminated is latency reduced.

And latency reduction is the only currency that matters in MEV.

HTTP/2 — The Foundation Nobody Talks About

gRPC runs on HTTP/2. This seems like an implementation detail — a footnote in the architecture diagram, something you nod at and move past. But understanding HTTP/2 is essential to understanding why gRPC is not just "REST with binary payloads." The transport layer changes the game in ways that the serialization format alone cannot.

Traditional REST runs on HTTP/1.1. In HTTP/1.1, every request-response pair is a sequential transaction on its own connection. If your bot needs to fetch account data for five different pools simultaneously, it either opens five separate connections or it sends five requests sequentially on a single connection, waiting for each response before sending the next. This is a fundamental constraint built into the protocol. One request. One response. Then the next.

HTTP/2 introduces multiplexing. A single connection can carry multiple streams simultaneously. My bot can send five requests, ten requests, fifty requests — all at the same time, on the same connection, interleaved at the frame level. The responses come back in whatever order they complete, not in the order they were sent. There is no head-of-line blocking, where a slow response to request number three holds up the responses to requests four through ten that are already ready.

Think of it like a highway versus a single-lane road. HTTP/1.1 is a one-lane road with stoplights at every intersection. One car goes through, the light turns red, the next car waits. HTTP/2 is a multi-lane highway. Cars enter from different on-ramps, travel at different speeds, exit at different off-ramps, and none of them need to wait for the car in front to reach its destination before they can proceed.

For my bot, this means something concrete: connection efficiency. Instead of maintaining a pool of HTTP connections to handle concurrent requests — each connection consuming memory, each connection requiring its own TCP handshake, each connection adding overhead — a single HTTP/2 connection handles all of them. The connection is opened once, the TLS handshake happens once, and then thousands of request-response pairs flow through that single pipe.

HTTP/2 also compresses headers using a scheme called HPACK. In HTTP/1.1, every request sends the full set of headers — content type, authorization, accept encoding, user agent, host — as plaintext strings. When you are making a thousand requests per second to the same endpoint, those headers are identical every time, and you are paying the bandwidth cost of transmitting them every time. HPACK maintains a table of previously seen headers on both sides of the connection. After the first request, subsequent requests reference the table index instead of retransmitting the full header. A header that was fifty bytes becomes two or three bytes.

These are not theoretical improvements. They are architectural differences that compound at scale.

Streaming — The Real Reason gRPC Matters

Everything I have described so far — binary payloads, multiplexing, header compression — makes gRPC faster than REST. But faster is a quantitative improvement. Streaming is a qualitative one. It changes what is possible.

gRPC supports four communication patterns. The first is unary — a single request followed by a single response. This is functionally identical to REST, just faster. The second is server streaming — the client sends a single request, and the server sends back a stream of responses over time. The third is client streaming — the client sends a stream of requests, and the server responds once with a single reply. The fourth is bidirectional streaming — both client and server send streams of messages to each other simultaneously, on the same connection.

Server streaming is the pattern that changes everything for an MEV bot. Here is why.

With REST, getting real-time data requires polling. My bot sends a request: "What is the current state of this account?" The server responds. My bot waits — maybe fifty milliseconds, maybe a hundred — then sends the same request again. "What is the current state of this account?" The server responds. Wait. Ask again. Wait. Ask again. This is like refreshing a webpage over and over to see if there are new comments. It works, but it is wasteful. Most of the time, the state has not changed, and the request-response cycle was wasted bandwidth and wasted time. And when the state does change, my bot does not learn about it until the next polling cycle, which might be fifty or a hundred milliseconds later.

With server streaming, the dynamic reverses. My bot opens a stream and says: "Tell me whenever this account changes." The server acknowledges the subscription and holds the stream open. When the account state changes, the server pushes the update immediately — no waiting for the client to ask. The data arrives at my bot the moment it exists, not at the next polling interval.

The difference is like the difference between live TV and a DVR. With live TV, the event happens and you see it immediately. There is no delay between reality and your screen. With a DVR, you are always watching something that already happened — maybe seconds ago, maybe minutes ago, but never now. Polling is the DVR. Streaming is live TV. And in MEV, where an arbitrage opportunity might exist for less than four hundred milliseconds, the difference between "live" and "seconds ago" is the difference between profit and nothing.

gRPC vs. WebSocket — Why Not Just Use What Already Works

This is a reasonable question. WebSocket already provides persistent, bidirectional communication. I am already using WebSocket connections for some real-time Solana data. So why does gRPC matter when WebSocket already exists?

The answer is structure.

A WebSocket connection is a raw pipe. Once the initial HTTP handshake upgrades the connection to WebSocket, the protocol gets out of the way entirely. You can send anything — JSON, binary, plain text, Base64-encoded images — and the protocol does not care. It just delivers bytes. There is no built-in concept of multiple concurrent conversations on a single connection. There is no built-in flow control to prevent a fast sender from overwhelming a slow receiver. There is no built-in mechanism for deadlines or timeouts. These are all things you have to build yourself, on top of the raw pipe.

gRPC, by contrast, builds all of this into the protocol. Multiplexing means multiple independent streams on a single connection, each with its own identity and lifecycle. Flow control is built into HTTP/2 at the frame level — a slow consumer automatically signals the fast producer to back off. Deadlines allow the client to specify "if you have not responded in 500 milliseconds, cancel the request" — and the server receives that deadline and can stop doing work it knows will be wasted. Error handling is structured, with typed status codes that mean the same thing across every implementation.

Think of the difference between a spreadsheet and a handwritten ledger. A handwritten ledger can contain anything — you can write whatever you want, in whatever format you want, wherever you want on the page. That flexibility is sometimes useful. But a spreadsheet gives you cells, columns, formulas, data types, validation rules. The structure constrains you, but it also protects you from entire categories of errors. You cannot accidentally put a date in a number column. You cannot accidentally overwrite a formula with a typo. The structure does the bookkeeping for you.

WebSocket is the handwritten ledger. gRPC is the spreadsheet. For a system that needs to manage dozens of concurrent data streams, handle backpressure, enforce timeouts, and recover gracefully from failures, the built-in structure of gRPC eliminates entire categories of bugs that a WebSocket-based system would need to handle manually.

The .proto Contract

One of the most practically significant differences between gRPC and REST is how interfaces are defined.

In REST, the API contract is typically documented in a README, a wiki page, or an OpenAPI specification file. The server defines what endpoints exist, what parameters they accept, and what responses they return. The client reads this documentation and writes code to match. If the documentation is wrong, the client discovers it at runtime — when a request fails, a field is missing, or a response has an unexpected structure. If the documentation is incomplete, the client discovers the gaps by trial and error.

This is like a contract written on a napkin. Both parties think they agree, but there is no mechanism to ensure they actually agree until something goes wrong.

gRPC uses .proto files — Protocol Buffer definition files — as the contract. A .proto file is a machine-readable schema that defines every service, every method, and every message type. Field names, field numbers, data types, required versus optional — everything is specified in a formal grammar that can be parsed by tools.

From this .proto file, code is generated automatically. In Python, the protoc compiler produces classes and stubs. In Rust, prost or tonic generates types and traits. In Go, Java, C++ — every supported language has its own code generator that reads the same .proto file and produces idiomatic code for that language.

The result is type safety at compile time, not at runtime. If the server adds a new field to a response message, the .proto file is updated, the client regenerates its code, and the compiler tells the client exactly where it needs to handle the new field. If the server changes a field type from int32 to int64, the compiler catches the mismatch before a single byte is transmitted. If the client tries to call a method with the wrong argument types, the code does not compile.

Compare this to JSON over REST, where a field that should be a number might arrive as a string, a field that should always be present might be missing, and a new field added by the server might go completely unnoticed by the client until it causes a subtle bug three layers deep in the parsing logic. With JSON, the data is self-describing, which means the data describes itself — but nobody validates the description until you actually try to use it.

The .proto contract eliminates an entire category of bugs: format mismatches between client and server. When the contract is the code and the code is the contract, there is no gap between what the documentation says and what the implementation does.

Where REST Still Wins

It would be dishonest to present gRPC as a universal replacement for REST. It is not. REST has legitimate strengths that gRPC does not match.

Browser support is the most obvious one. gRPC runs on HTTP/2 with binary payloads. Web browsers expect HTTP/1.1 or HTTP/2 with text-based content. While gRPC-Web exists as a compatibility layer, it adds complexity and loses some of gRPC's advantages. For public-facing APIs that need to be consumed by JavaScript in a browser, REST with JSON remains the practical choice.

Simplicity is another. A REST API can be tested with curl, a browser address bar, or any HTTP client. The payload is readable text. The headers are readable text. Debugging is straightforward because everything is visible in plain ASCII. A gRPC call requires specialized tooling — grpcurl, Postman with gRPC support, or custom client code. The binary payloads are opaque without the .proto schema to decode them. For external APIs meant to be consumed by third-party developers who just want to integrate quickly, REST's simplicity is a genuine advantage.

The pattern that emerges across the industry is "REST outside, gRPC inside." Public APIs exposed to external consumers use REST for accessibility. Internal service-to-service communication uses gRPC for performance. The boundary between "outside" and "inside" is determined by who is consuming the API and what their constraints are.

For an MEV bot, everything is "inside." My bot is not a public API. It is not consumed by browsers. It is not consumed by third-party developers. It is a performance-critical system that communicates with infrastructure services over private connections. Every advantage of REST — readability, browser support, ease of testing — is irrelevant to this use case. And every advantage of gRPC — binary efficiency, multiplexing, streaming, type safety — is directly relevant.

The Performance Gap

How much faster is gRPC than REST in practice? The answer depends on the workload, the network conditions, and the implementation details, so I am wary of quoting specific numbers as universal truths. But benchmarks from various sources provide a general picture.

For simple unary calls — single request, single response — gRPC is approximately three to four times faster than equivalent REST calls in some benchmarks. The gains come from binary serialization (faster encoding and decoding), header compression (less data on the wire), and connection reuse (no per-request handshake overhead).

For high-throughput scenarios with many concurrent requests, the multiplexing advantage widens the gap. Some benchmarks report seven to ten times the throughput of REST under heavy load, though these numbers are highly dependent on the specific test configuration. The multiplexing advantage compounds because HTTP/2 eliminates the connection overhead that becomes the dominant bottleneck in HTTP/1.1 under concurrency.

For streaming workloads, the comparison breaks down entirely because REST does not have a native streaming equivalent. You can approximate it with polling, with Server-Sent Events, or with a separate WebSocket connection, but each of those is a workaround with its own overhead and complexity. gRPC streaming is built into the protocol, and comparing it to a REST-based approximation is not a fair comparison — it is a category difference.

In the context of MEV, where the difference between receiving data one millisecond earlier and one millisecond later determines whether an opportunity is actionable, even the conservative "three to four times faster" estimate for unary calls represents a meaningful edge. And the streaming capability is not an edge — it is a prerequisite. Some data simply cannot be consumed efficiently through polling. The data arrives too fast, changes too frequently, and ages too quickly. Streaming is the only viable pattern.

What Changes for My Bot

Moving from REST to gRPC is not a cosmetic upgrade. It is a plumbing renovation. The external behavior of the bot might look similar — it still receives data, evaluates opportunities, and submits transactions. But the internal mechanics of how data enters the system change fundamentally.

With REST, data acquisition is pull-based. The bot decides when to ask for data, asks, and processes the response. The bot controls the timing. The bot controls the frequency. And the bot pays the latency cost of each round trip.

With gRPC streaming, data acquisition becomes push-based. The bot subscribes once, and data arrives whenever it changes. The bot does not control the timing — the data arrives when it arrives, which is as soon as it exists. The bot's job shifts from "pull data at the right time" to "process data as fast as it arrives."

This is a fundamental architectural shift. Pull-based systems are simpler to reason about because the bot controls the flow. Push-based systems are harder to reason about because the data controls the flow, and the bot must be prepared to handle data at whatever rate it arrives — including bursts, including gaps, including out-of-order delivery for different streams.

But the performance advantage is non-negotiable. In the MEV ecosystem, the infrastructure providers offer gRPC interfaces specifically because they understand that REST is insufficient for the latency requirements. The data is there. The streams are there. The protocol is there. The question is not whether to adopt gRPC but how to adopt it without introducing new failure modes in the process.

The .proto files define the contract. The code generators produce the client stubs. The HTTP/2 connection carries the streams. The binary payloads minimize the overhead. Each piece is well-defined, well-documented, and well-tested individually.

The challenge, as always, is in the integration — making all the pieces work together in a system that must run continuously, handle errors gracefully, and never miss a beat. That is where theory meets practice, and where reading about gRPC gives way to actually building with it.