前段时间写过一个库 tyshemo，主要用于在运行时对数据进行检查，特别针对后台接口返回的数据进行检查，做到对后台返回数据类型和格式的实时监控。后来，在工作中，遇到前端界面写完了，后台接口没出，不得不等着后台写完接口后在联调的尴尬场景，于是就想，能否前端同学先写好一个文档，后端同学按照该文档输出？（使用 graghql 的同学请撤离）
想到这个点之后，我就思考，既然我写了一个类型描述系统，为何不直接将这个描述系统的实例，转化为描述文本呢？例如：
import { Dict } from 'tyshemo'
export const BookType = new Dict({
name: String,
price: Number,
})
// 使用方法：BookType.assert(book)
为什么我不能直接输出一个文本：
{
name: string,
price: number,
}
这样非常清晰，前后端，甚至任何人都能知道我的一个数据结果和它每个节点（字段）的类型都一目了然。
于是我开发了一个 Parser，用于将类型实例，转化为描述对象，通过 JSON.stringify 就可以转化为描述文本。同时 Parser 还可以将描述对象返回去转化为可以用来做类型检查的实例。这样，前后端实现了可传输类型检查的描述对象，如果后端是通过 nodejs 实现的，那么传输这个描述对象，就可以在前后端都运行它。
通过 Parser，我想到，可以把前端写好的类型实例，转化为文档输出，在后端同学没有动工之前，前端写好实例，输出描述文本，和后端同学一起过目讨论，确认无误后，前端按照这个结构开发即可，后端同学对照这个结构和类型约束输出接口数据。
但是，单纯有了约定，并不能满足前端同学对数据的需求，因为没有数据就不能渲染界面，无法进行下一步的操作，总不能在脑海中想象结果吧。于是，我想，既然数据的类型是确定的，那么，就可以通过一些随机算法，按照数据类型输出对应的值。于是，我撰写了 Mocker 用来生成这样的数据。
import { Parser, Mocker } from 'tyshemo'
import some from './some.type.js'
const parser = new Parser()
const desc = parser.describe(some)
const mocker = new Mocker()
const mock = mocker.mock(some)
但是，这样的工作方法太过原始了，有没有一个办法，可以更好的表达一个工作的流程呢？
我决定写一个基于 express 的服务，配置所有 api 接口的详细信息，启动这个服务之后，就可以在浏览器中看到对应的接口文档，或者启动服务后，可以将前端的接口指向 mock 服务的地址，让后台返回 mock 数据。用了一个周末，我写完了 tyshemo-service，虽然界面不怎么好看，但是功能实现了。
import TyshemoService from 'tyshemo-service'
import { BookRequestType, BookResponseType } from './book.type.js'
const server = new TyshemoService({
basePath: '/api/v2',
errorMapping: {
10001: '数据库连接错误',
10002: 'xx错误',
},
data: [
{
name: '第一组接口',
items: [
{
name: '第一个接口',
description: '这个接口是用来干嘛的？',
method: 'get',
path: '/book/:id',
request: BookRequestType,
response: BookResponseType,
},
],
},
],
})
server.doc({ port: 3001 }) // 启动文档服务器
其中 BookRequestType 描述了请求参数的类型。由于这里的 method 是 get，所以，请求参数实际上表达的是 searchQueryParams 的字段及其类型。如果是 post 则会是 postBody 的字段类型及其结构。BookResponseType 描述了返回结果的数据结构，以及每个字段的数据类型。需要注意的是，实际上，在前端代码中 BookRequestType 都是可以直接使用的，例如，在请求 book 的 ajax 返回结果处，调用 Ty.expect(data).to.be(BookResponseType) 来检查 ajax 返回结果是否符合预期。
上面的代码，让 nodejs 在本地 3001 端口起了一个文档服务，浏览器打开，就可以看到文档。让后端同学访问你本地起的这个页面，就可以让他对照文档进行接口输出啦。
开启 mock 服务，你需要使用下面的代码：
server.mock({ port: 3002 })
将本地开发的代理，指向 3002 端口，就可以 ajax 请求到 mock 服务器就可以了。具体配置，你可以去 tyshemo-service 的仓库阅读更多配置细节。
之后，我又想，我还可以起一个服务，让前端同学去监控后端同学写好的接口，是否符合类型和结构要求。因为我们传入了 request 对应的类型，所以用它来 mock 一个请求数据也很简单。
server.data[0].items[0].test = [
{
frequency: 6000, // 6 秒一次
name: '测试用例1',
params: { id: 123 }, // 替换 path 中的参数
request: { price: 12 }, // 指定请求参数中的部分字段
},
]
server.test({ port: 3003, target: 'http://some.com:8008' })
打开本地 3003 的网页，可以看到一个测试页面，这个测试页面虽然丑陋，但是它可以帮助前端开发去监测后台接口是否是按照文档输出内容的。
通过上述一通操作，就可以让前端在没有什么成本的情况下快速完成自己的开发了。
最后留个悬念，既然我们能把接口的配置都集中在这里了，我们是否还可以提供更集成的方案，把前端的 ajax 也集成进来，也就是说，对于单一一个接口，前端需要写好该接口的各种请求配置、类型、测试等信息。需要发 ajax 的时候，调用某个方法得到数据，同时干完数据类型的检查。需要文档和 mock 的时候，启用服务。这样的方案，也不是不可行。
