gRPC vs REST 选型

没有银弹：gRPC 擅服务间高性能与强契约；REST 在公开 API、缓存、浏览器与团队熟悉度上往往更优。 CodeRoadMap ** deliberately 选择 REST 作为主 API**。

学习目标

• 列出 gRPC 优势与代价
• 理解内网 RPC 与对外 REST 的分层模式
• 能向团队解释本站为何保持 /tracks REST

核心内容

对比矩阵

维度	REST（本站）	gRPC（lab 微服务）
学习曲线	低，HTTP + JSON	中，proto + stub + HTTP/2
浏览器	原生 fetch	需 Gateway / gRPC-Web
序列化	JSON 可读	Protobuf 紧凑
契约	OpenAPI	.proto 编译期检查
CDN/缓存	GET /tracks 易缓存	不适合公网 GET 缓存
流式	SSE/WebSocket 另议	内置 streaming
可观测	路径即指标	需 grpc 拦截器

CodeRoadMap 选 REST 的理由

1. 资源清晰：track、lesson 与 URL /tracks/{slug}/lessons/{lessonSlug} 一一对应，nextjs-essentials RSC 与 SEO 友好
2. 只读为主：课程站点写操作少，gRPC 低延迟优势不明显
3. 栈统一：spring-boot-essentials 团队已有 @RestController、OpenAPI、JWT
4. 客户端简单：无需 protoc、无 Gateway 运维
5. 与 GraphQL 立场一致：gql-rest——扩展协议学而不替

何时引入 gRPC

• 微服务间 QPS 高、payload 大（配合 spring-cloud-essentials）
• 多语言团队共享 .proto
• 强类型演进、双向 streaming

可 REST 对外 + gRPC 对内：BFF 暴露 /tracks，内部 TrackService gRPC——本 track lab 演练此分层，不迁移生产主路径。

练习

• 为你熟悉项目写 3 条「选 REST」和 2 条「可考虑 gRPC」理由
• 画架构：platform → REST vs platform → gRPC mesh
• 阅读 ，列出若改 gRPC 需迁移的 endpoint