Rethink JSONSpec

Rethink JSONSpec

JSONSpec

  1. JSONSpec: Build a well-typed Web
  2. JSONSpec: Build an enhanced service
  3. JSONSpec: TypeSpec - Typescript-based JSONSpec
  4. JSONSpec: Workflow as a Service
  5. JSONSpec: AST as a Service
  6. JSONSpec: Data Driven Design
  7. JSONSpec: Next step
  8. JSONSpec: GraphQL
  9. JSONSpec: Why spec

这个目录里的是一系列我个人于2015年5月到8月之间发表的关于Web接口、服务和后端应用设计的一系列文章。这个思考过程也逐渐影响了我工作中所使用和坚持的一些实践,比如 Schema First,比如偏好强类型和显示标注的接口设计,比如使用从 RAML / Swagger 到 GraphQL 这些框架和工具。

实践证明这也是一个明显的趋势,从Web端TypeScript的逐步火热,到Schema First的设计逐渐流行,都说明了,类型、Specification等在编程活动中起到了非常重要的作用:建模、验证和生成代码以及测试工具,都有各种对应的轮子。我个人也挖了不少坑来辅助这件事儿。(见对应文章 Why Spec)

但目前这块儿还是不够非常的完善,比如一个理想的过程是,我定义好了的schema,对应其实已经可以把业务数据和处理过程也能加进去(就是Workflow as a service和AST as a service中提到的),这样整个后端过程其实都是非常灵活可配接的了。然后接下来我们要考虑的是如何把数据绑定在前端,去展示给终端用户:这个过程,在这段时间的实践来看,也可以逐步做成自动的。

新思路

这样我们来看一下一个应用的处理过程,可以分为以下几部分:

由此其实我们也能导出一个应用的实现过程:

  1. 设计Schema
  2. 链接输入、输出、数据源
  3. 设计处理管线
  4. 扩展schema,回到 1

这样应用所有部分的内容,都是由不同地方的“数据”组合起来的。所有的处理流程,都是某一个简单的处理管线过程。比如如果我们需要加一条数据处理的流程,聚合每天的事务数据得到一个处理结果,那这部分获取 + 转换的过程,几乎就可以复用之前管线的过程。

基础设施

于是我们发现还有这些东西是需要的,一个自动建模的工具、一个管理和动态配接管线的框架以及一个验证工具。

可能这就是接下来要做的事情了。

2019-04-29