正文
-
最后 API 部署上线，客户端打包发布。
后续 API 如果要进行不引入 breaking change（接口没有语义上的修改，没有删除，只有添加和弃用声明）的修改：
-
前后端工程师和产品经理一起修改/审核已有的 OpenAPI v3 spec，敲定新的 API 的接口。
-
后端工程师根据修改后的 spec 生成新的 API 代码，开始后端的开发和 UT。
-
前端工程师用
awesome_api
生成新的 client SDK，运行 mocking server，然后引入 cient SDK，开发前端功能，进行 UT。
-
两端集成测试。
-
API 部署上线，客户端打包发布。
按照这个流程，以及前文所述 Quenya 子项目的结构，我们可以绘制一个 Quenya 各个子项目之间，以及子项目和用户的 API app / client app 之间的关系图：
我先不一一解释图中的要素，请你自己花个 5-10 分钟思考一下为什么各个项目间是这样一种关系。代码生成属于元编程（meta programming）的范畴，就像代数（Algebra）之于算术（Arithmatic），是进一步的抽象。所以我们想要理解这种抽象，需要先看一个具体的 API 项目是如何架构的，回过头来再想为了得到这样的架构，我们需要怎么做。
API 项目的架构
一个 HTTP API Server 主要是由几部分构成的：
-
Router（路由）：预先定义好的一张路由表，它决定如何分发流量。一般而言，REST API 的路由根据请求路径（request path）来完成。
-
Middleware（中间件）：在请求被路由前，可能会运行一系列的中间件对请求做预处理。
-
Handlers（路由的处理函数）：每条路由会有一个到多个路由处理函数，它们依次处理请求（Request）对象，并更新响应（Response）对象。
-
Hooks（钩子）：在 API 的整个处理流程中，开发者可以插入一些钩子函数，以便在特定的上下文完成一些特殊处理。比如
before_send
就是一个很重要的钩子，我们常常用其来做一些日志处理，性能分析等。
用图像表示更直观一下：
这里为了示意，我放了两个 hooks：
before_routing
和
before_send
。我们不必纠结 hooks 是否足够，是否需要
after_routing
，
after_send
等，这个不重要。事实上用的最多的 hook 是
before_send
，其它的随需而设即可。
