Challenge 3: Synthesize the Course's gRPC-vs-REST Thread — Possible Solution
====================================================================

gRPC was built from the start (Chapter 1) for service-to-service
communication within a single organization's own infrastructure — its
performance advantages (HTTP/2 multiplexing, compact binary Protobuf)
and its schema-first contract matter most when BOTH ends of a call are
code the same team controls and can regenerate together. Chapter 7
builds directly on that assumption: mutual TLS lets two internal
services each prove their identity via certificates, a security model
that makes perfect sense when every service is a known, managed entity
inside a trusted network — but has no equivalent for an anonymous
public client. This chapter adds the operational layer on top: service
discovery and load balancing across many internal instances, again
assuming the client is itself part of the same managed infrastructure
that knows how to do resolver-based lookups or talk to an internal
proxy.

None of this holds for a public API a mobile app calls directly. A
mobile app can't run gRPC natively without a translation proxy
(gRPC-Web, Chapter 1's gotcha) — an extra piece of infrastructure with
no real gRPC-to-gRPC benefit at the browser/app end. It has no
certificate identity to present for mTLS the way an internal service
does, so it falls back to a human-authentication model (bearer tokens)
that REST or GraphQL support just as naturally, without any of gRPC's
extra tooling requirements. And it has no reason to run resolver logic
or talk to an internal service-discovery system — it just needs one
stable, well-documented public endpoint, which is exactly what REST
and GraphQL are already optimized to provide. gRPC's strengths are
real, but they're strengths for a trust boundary a public mobile
client was never inside of.