What are the four gRPC method kinds, and which one fits a device that uploads a sample every few seconds for hours?

gRPC methods come in exactly four kinds. The kind is decided by one question asked twice: does the client send a single message or a sequence, and does the server answer with a single message or a sequence? Two binary choices give four shapes, and every method a service declares is exactly one of them. The kind is fixed at declaration time — a caller cannot turn a unary method into a streaming one at the call site. ## The four kinds - **Unary** — the client sends one message, the server answers with one message. This is the shape that reads like an ordinary function call, and it is still the most common one in practice. - **Server-streaming** — the client sends one message, the server answers with a sequence of messages of any length, then ends the call. - **Client-streaming** — the client sends a sequence of messages, the server answers with a single message once that sequence is finished. - **Bidirectional streaming** — both sides send sequences, and neither sequence has to wait on the other. | Kind | Client sends | Server sends | What the generated method gives the caller | |---|---|---|---| | Unary | one message | one message | a request argument, one response value | | Server-streaming | one message | many messages | a request argument, a readable sequence | | Client-streaming | many messages | one message | a writable sequence, one response value | | Bidirectional | many messages | many messages | a writable sequence and a readable sequence | The last column is the practical difference at the call site. A streaming direction is not a bigger message; it is a sequence you write into or read from over time, and the generated signature says so. ## A streaming call is one call The most common misreading is that a streaming method is a convenience wrapper over many calls. It is not. Everything in a streaming call happens inside a **single call**: one call beginning, one sequence of messages in each streaming direction, and exactly **one status at the end** that reports the outcome of the whole thing. Five thousand yield samples uploaded on a client-streaming method are five thousand messages inside one call — not five thousand calls. Two consequences follow immediately: 1. A failure partway through does not fail "one of the messages". It fails the call, and every message already sent belongs to a call that ended badly. 2. The protocol defines **no per-message acknowledgement**. If the application wants one, it has to be a message travelling in the other direction — which means the method kind must *have* another direction, and that is bidirectional streaming. ## Picking a kind for the harvester - The machine samples yield every few metres for six hours and the back office replies once, at the end, with a run summary → **client-streaming**. - The machine sends samples *and* wants calibration corrections back while it is still cutting → **bidirectional streaming**. - The office asks for a finished field's yield map and the server produces it row by row → **server-streaming**. - The machine registers itself, or reports that a run has started → **unary**. Notice that the choice is driven by the *shape of the data flow*, not by how much data there is. A large payload that is ready all at once can still be a unary response; a small trickle produced over hours cannot honestly be one. ## Why not call a unary method in a loop A loop of unary calls is a legitimate design and sometimes the right one, but it is a different design, not the same one written differently. Each iteration is an independent call with its own beginning, its own outcome and its own per-call overhead, and nothing ties the sequence together — the server sees unrelated calls and has to correlate them itself from something in the messages. A single streaming call gives the server one handler invocation that sees the whole sequence in order, and gives the client one outcome to handle instead of thousands. ## What a streaming kind costs - The call is long-lived, so it occupies a server-side handler for its entire life rather than for a few milliseconds. - It ends when that server instance goes away — a restart ends every call in flight, where a loop of short calls simply continues against whatever instance answers next. - One deadline covers the whole call, so the bound has to be sized for the *whole* sequence and not for one message. Naming the four kinds is a first-screen question. Knowing that a stream is one call with one outcome is what the interviewer is actually listening for.