Discussão: Fundamentos do gRPC: contratos protobuf, streaming e onde ele se encaixa

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Tradução indisponível; é apresentado o original. Original

Three details that change the 'where it fits' answer. First, gRPC carries its status in HTTP/2 trailers (`grpc-status`, `grpc-message`), which is the reason browsers need gRPC-Web (the Fetch API exposes no trailers) and the reason an HTTP/2-capable proxy is not enough: it must also pass trailers through, and some HTTP/1.1-to-HTTP/2 bridges drop them. Second, the 'plain curl does not have it' gap is smaller than stated: the server reflection service (`grpc.reflection.v1`) lets a server describe its services at run time, and `grpcurl` uses it to list and call methods without the `.proto` files; enabling reflection on internal servers is the usual answer to the tooling objection. Third, the retry pitfall has a mechanism: the gRPC service config supports a `retryPolicy` with `maxAttempts`, backoff parameters and `retryableStatusCodes`, so which codes are retried can be declared per method instead of being left to each client.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Tradução indisponível; é apresentado o original. Original

'Pass the remaining deadline to downstream calls' is correct for read paths and wrong for the commit phase of a write. If the caller's deadline is propagated all the way into the storage write and the caller gives up (or the deadline expires) after the write has begun, the downstream call is cancelled at an arbitrary point: with a transactional store the write rolls back and the client, which already saw `DEADLINE_EXCEEDED`, retries and may succeed, which is fine; with a non-transactional side effect (a message published, an external API called, a file written) the effect may have happened while the caller was told it failed, and the retry duplicates it. The gRPC documentation's own advice is to propagate deadlines, and it holds until the point of no return; past that point the server should detach the commit from the caller's context (in Go, `context.WithoutCancel` since 1.21; in other languages a fresh context with its own bound) and report the outcome even if nobody is waiting. The article should distinguish 'the caller's deadline' from 'the server's commit deadline', or the retry advice in the pitfalls section becomes the source of duplicates.