Challenge 3: REST Handler vs. gRPC Method — Possible Solution
====================================================================

A REST route handler typically has to do several things by hand before
it ever reaches the actual business logic: parse the raw request body
(often JSON text) into a usable object, validate that the parsed data
actually matches the expected shape and types, and — after computing a
result — manually serialize the response back into JSON with the
correct headers/status code. All of this "plumbing" work is written
and maintained as part of the handler's own code, even though it's
largely mechanical and repeats across nearly every endpoint.

A gRPC method implementation skips essentially all of that plumbing,
because it was already handled by protoc's generated code (per
Challenge 2): the incoming request arrives ALREADY deserialized into a
typed object matching the .proto schema exactly, and returning a
response (via callback or return value, depending on the language)
is automatically serialized back into Protobuf binary by the generated
server code. The method body is left with essentially nothing to do
except the actual decision-making logic — the same logic a REST
handler would also need, minus everything REST makes it handle
manually around that logic.

This is exactly the trade this chapter's comparison box named: gRPC
doesn't make the underlying business logic simpler — it eliminates
the repetitive, largely mechanical parsing/validation/serialization
code that would otherwise surround that logic in a REST handler,
because the schema-first .proto contract (Chapter 2) already generated
all of it.