Ecosystem & Advanced

เลยจาก happy path

มาถึงตรงนี้คุณออกแบบ schema, นิยาม service, implement, stream และทำ security ได้แล้ว โมดูลสุดท้ายนี้พูดถึงทุกอย่างที่อยู่รอบ ๆ core นั้น — ความจริงที่ว่า gRPC service ของคุณแทบไม่เคยอยู่ตัวเดียว

browser พูด gRPC แบบ native ไม่ได้ client บางตัวยังอยากได้ REST กับ JSON API ของคุณจะอยู่นานกว่า version แรกเสมอ และ service ทั้ง fleet ต้อง observe กับ test ได้ แต่ละเรื่องมีเครื่องมือที่แก้ปัญหาไว้แล้ว และโมดูลนี้จะพาไปดูทีละอัน

โมดูลนี้ครอบคลุมอะไรบ้าง

บทเรียน	สิ่งที่คุณจะได้เรียนรู้
gRPC-Web	ทำไม browser ต้องมี proxy, gRPC-Web protocol และ Connect
gRPC-Gateway & transcoding	เปิด REST/JSON facade จาก `.proto` เดียวกัน
Versioning & evolution	package แบบมี version, additive vs breaking change, `buf breaking`
Observability & testing	reflection, tracing/metrics และ in-process testing

หน้าตาของ deployment จริง

ระบบ gRPC บน production มักไม่ได้หน้าตาแบบ “client เรียก server ตัวเดียว” แต่เป็น ecosystem เล็ก ๆ ของตัวแปลและตัว observe:

flowchart TB
  browser["browser
(gRPC-Web)"] --> proxy["proxy /
transcoder"]
  rest["REST client
(JSON)"] --> proxy
  proxy --> core["gRPC services
(v1, v2)"]
  svc["other gRPC
services"] --> core
  core --> obs["interceptors →
metrics · traces · logs"]

gRPC core เดียว มีทางเข้าออกหลายทาง

.proto ที่คุณเขียนยังเป็น single source of truth อยู่ ทุกอย่างตรงนี้ — web client, REST gateway, API version ถัดไป, tracing — ล้วนแขวนอยู่บน contract เดียวกันนั้น