GraphQL Federation CapstoneGraphQL Federation Capstone
对应 graphql-federation-practice 这个真实项目：一个 Apollo Federation subgraph（Node.js）加一个 Spring Boot REST 微服务，再加两道书面题。从「GraphQL 是什么」讲到能在空目录里重建整个 subgraph。Built on the real project graphql-federation-practice: one Apollo Federation subgraph (Node.js), one Spring Boot REST microservice, and two written questions. It starts at what GraphQL is and ends with rebuilding the whole subgraph in an empty directory.
Task 1 考 GraphQL 与 Federation 的基本功：schema 的可空性怎么决定 resolver 的兜底、parent 从哪来、entity 与 @key、DataLoader 防 N+1、结构化错误与 correlation id。Task 2 考 REST 语义：状态码选对没有、异常该谁处理。两道书面题考的是「有没有在真实系统里想过延迟传播和生产配置」。贯穿全题的隐性考点是「能不能核对而不是猜」—— starter 里有三处人为埋雷。Task 1 covers the basics of GraphQL and Federation: how a nullable field in the schema decides what the resolver returns as a fallback, where parent comes from, entity and @key, using DataLoader to avoid N+1, and structured errors with a correlation id. Task 2 covers what the REST rules require: whether the status codes are right, and who should handle the exceptions. The two written questions ask whether you have thought about how delay spreads and how a service is configured in production. One point runs through the whole exam: can you check instead of guess — the starter has three bugs planted on purpose.
graphql-federation-practice参考项目。本机实测基线：subgraph 6 failed / 4 passed，Java 5 run / 2 failuresReference project. Measured baseline: subgraph 6 failed / 4 passed, Java 5 run / 2 failures
graphql-federation-practice建议先过一遍Work through 地基 · 项目与语言。如果你已经会 npm、会读 package.json，可以直接开始这一门。 first. If you already know npm and can read a package.json, start here directly.
| 真实项目里的任务Task in the real project | DrillLab 讲到哪Where DrillLab covers it | 有测试Tested |
|---|---|---|
| Task 1 · User.orders | 完整讲解 + entity 数据流图 + 填空 + L3 自写 + 从零重写 | 有Yes |
| Task 1 · Order.shippingInfo（要求用 DataLoader） | N+1 与 DataLoader 专章 + 填空 + Debug Lab | 有Yes |
| Task 1 · Query.orders | 与 Query.order 对比讲解 + 填空 + L3 自写 | 有Yes |
| Task 1 · Query.order（README 没提、也没有测试） | 专门指出并完整实现，用上了给好的 ORDER_NOT_FOUND | 无No |
| 埋雷 1 · createOrderLoader 调了不存在的 getOrderById | DataLoader 那节点出 + 独立 Debug Lab | 有Yes |
| 埋雷 2 · createOrder 用了不存在的 orderAPI、签名错、缺 price | 埋雷专章逐条拆解 + Debug Lab | 有Yes |
| 埋雷 3 · catch 把 INVALID_INPUT 吞成 SERVICE_ERROR | 贯穿四个 resolver 的模式讲解 + 独立 Debug Lab | 有Yes |
| Task 2 · 六个 Spring 端点（含 201 / 204 / 400 / 404） | Spring 基础 + 逐端点讲解 + 填空 + L3 自写 + 从零重写 | 有Yes |
| Task 2 · 六个端点全 return null 也能过 3/5 测试 | 实测数据 + 手动 curl 自检清单 + Debug Lab | 有Yes |
| 书面题 1 · User subgraph 高延迟的影响与缓存策略 | 传导路径分析 + 完整参考答案 + 答题结构模板 | 无No |
| 书面题 2 · application.properties 的生产隐患 | 六面排查清单 + 六个问题的完整参考答案 + L3 练习 | 无No |
schema、type、field、query、resolver、非空与列表。全部用 node-subgraph 的真实 schema.graphql 当例子 —— 这份 schema 的每个细节后面都会变成考点。schema, type, field, query, resolver, non-null and lists. Every example is the real schema.graphql from node-subgraph, and every detail in that schema turns into an exam point later.
为什么要拆、subgraph 是什么、entity 和 @key 在解决什么问题、Router 怎么把碎片缝起来、DataLoader 为什么必须出现。Why one schema gets split up, what a subgraph is, what problem entity and @key solve, how the Router joins the pieces back into a single schema, and why DataLoader is needed.
四个 TODO 加三处埋雷。每个 TODO 都走同一套流程：读题 → 考什么 → 先想再写 → 分步实现 → 完整答案 → 为什么成立 → 常见错法 → 迁移。Four TODOs plus three planted bugs. Every TODO follows the same steps: read the task, see what it tests, think before writing, build it step by step, read the full answer, understand why it works, look at the common mistakes, then reuse the pattern elsewhere.
六个端点，业务逻辑全都给好了。真正考的是「HTTP 状态码选对了吗」和「异常该谁处理」—— 而这两点恰好是那五个测试只抓住一半的地方。Six endpoints, with all the business logic already written for you. What is really tested is whether you picked the right HTTP status code and who should handle the exceptions — and those are exactly the two things the five tests only check partly.
QUESTIONS.md 里的两道题。它们不考代码，考的是「你有没有在真实系统里想过这些问题」。这一节给出思考框架和一份可以照着写的参考答案。The two questions in QUESTIONS.md. They do not test code. They test whether you have thought about these problems in a real system. This module gives a structure for thinking them through, plus one reference answer you can follow.
把 GraphQL 和 Spring 两边的典型故障集中练一遍，然后在没有答案的情况下从空目录重建整个 subgraph 和整个控制器。Practice the common failures on both the GraphQL side and the Spring side in one place, then rebuild the whole subgraph and the whole controller from an empty directory, with no answer to look at.
图书评论 subgraph。它既不拥有 Author 也不拥有 Book —— 两者都由 Catalog subgraph 提供，本服务只往它们身上挂 reviews 和 averageRating。Book 用的是复合 key（isbn + edition），这是真实项目里很常见、但比单字段 key 更容易写错的情况。