前后端跨语言同构——邂逅一场美丽的编程童话

基于 JS 的同构或许你已经尝试过了,甚至已经如火纯青了,然而,倘若现在我们要跨语言进行同构呢?关于这篇文章的背景,我不想赘述。既然要讨论,那开门见山:跨语言同构,是一场美丽的编程童话,做的好,天堂见,做的不好,再也不见。

跨端跨语言同构

首先不可避免的,我们需要为“同构”下一个定义。同构本来是一个数学概念,但是在编程领域,我们可以简单理解为,同构是指在不同平台上使用相同代码实现相同目标(确保一致性)的方案。前后端同构就是在前端和后端使用相同代码(sharing code between the front-end and the back-end),以达到前后端效果一致的方案。它的核心,在于“共用(share)”。至于实现什么目标并不确定,比如在前后端使用同一个 lodash 函数保证处理结果的一致性,比如利用 react 特性实现同构渲染等等。

我们不去探讨哪些东西适合前后端同构,或者哪种方式才叫同构,以及如何实现同构直出。我们直接跳过了概念之争,跳过流于形式的实现过程。我们即将探讨的是,用一种什么方式,能够让我们保证实现相同目标的过程是一致的。即在架构设计上,确保前后端业务逻辑的一致性。在这里,同构是一种设计思想

而且更进一步,我们要探讨,在前后端跨语言场景下,如何利用同构思想解决问题。由于我们所指的前端主要是指 Web 前端,基本上就是使用 JS 语言,这里的跨语言大部分是指后端使用 PHP、Java 等其他语言的场景。传统上,在后端开发中跨语言互调其实我们经常使用,方案也非常多,例如 PHP 去使用 Python 代码,单就这一个问题,也有多套方案实现。不过在本文中,我们理想中的跨语言,本质上和语言无关,我们要找到一种无论在什么语言环境中都能运转的方案。如果我们不想实现一个 JS 中运行 PHP 的 PHPvm,或者一个 Java 中运行 JS 的 JSrunner,那么我们为何不寻找一种基于协议的同构方案呢?

校验逻辑共用

在复杂系统中,表单可能存在较为复杂的字段逻辑,从而带来复杂的校验逻辑。表单校验是任何系统中必备的能力,而且为保证业务准确性和数据安全,前后端都会做校验。我们可以采用一种形式,确保前后端的校验是一致的,没有差错的。

我们首先来解剖校验,它的本质是什么?校验的本质,是将流动的信息体与既定的形状进行匹配,如果信息流动中的体态与既定形状没有补集,那么我们认为给定信息是符合要求的。而这里的既定形状,我认为主要包含两大方面要素:

  • 所需的所有字段总和(多少)
  • 单个字段的取值范围(类型、大小、结构)

所有字段总和是指要完成当前操作,所必备的和可选的字段应该是哪些。如果超出这个总和的部分可能导致数据更新出错;不足这个总和可能导致对象无法创建。在完成字段总和的校验之后,单个字段的值,需要符合规定的逻辑,这里的逻辑就包含该值应该是什么数据类型,值的大小应该在什么范围,以及如果这是一个结构体,应该具备什么结构,具体结构节点上的数据类型又应该是什么。

请注意我上文所提的“形状(shape)”这个概念,形状是可以被描述的。既然可以被描述,那么我们就可以建立自己的描述体系来对我们的校验进行描述,从而抽象出脱离代码的描述文本。

在著名 PHP 框架 Laravel 中就建立了这样的描述体系。我们来看下官方给出的代码示例

/**
 * Store a new blog post.
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $validatedData = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // The blog post is valid...
}

上面代码中 required|unique:posts|max:255 就是关于 title 字段的校验描述文本,而且我们可以很容易理解这一描述文本,只要我们在描述系统中对这种描述表达式加以解释,那么就可以融会贯通,将这种表达方式用在其他校验描述中。

一旦校验可以用文本(而非代码)进行描述,也就意味着可以用文本的形式确定相同字段在前后端的校验逻辑的“形状”,而文本,是我们最喜欢的东西,因为它可以以任何形式在客户端与服务端之间传输。我们要做的,是在服务端和客户端构筑基于不同语言的解析器,一旦两端解析器抹平了平台差异,那么校验描述文本就可以基于 HTTP 跳着舞,确保两端的校验是一致的准确的。

数据结构共享

这里所讲的数据结构不是指计算机数据结构,而是单纯地指结构体对象的形状结构,也就是 JS 对象的结构。在前后端交互时,我们经常需要前端对后台吐出的数据结构和数据类型进行检查,后端也需要对前端提交的数据进行检查,这些传输在网络中的数据,不是我们一句“上 typescript”就可以解决的。

让我们回到描述文本。

既然我们已经隐约觉得,文本是我们的大杀器,为什么我们不尝试将这一发现试验在前后端数据结构的一致性上呢?如果我们可以用文本方式,提前描述后端返回的数据的形状,那么前端就可以校验后端吐出的真实数据是否符合这个形状。这件事我们不一定要在正式环境做,在开发和测试阶段我们就可以利用这一特性,检查后端吐出数据的边界,避免上了正式环境才来互怼。

有人可能会说:有什么是一份 API 文档解决不了的呢?如果真有,就再来一份文档注释。嗯!很有道理,但太敷衍。在 API 这件事上,文档只能解决一件事,就是定调,走不走音,节奏乱不乱,完全控制不了。

GraphQL 虽然被定义为一门独立的前后端接口查询语言,但是,在事实上,我们在使用时仍然是以描述文本的形式在前后端之间传输这段描述,前端提交这段描述后,后端返回基于描述的结果数据。基于 GraphQL 的系统,提前约定了前后端在数据结构上的一致性,从协议层面解决了数据结构的共享。不过,GraphQL 还是会有一些问题,目前来讲核心问题在于成本高昂,它需要复杂的部署,才能让开发者读懂,才能让后端系统按约定输出,受到已经具有成熟接口开发经验的后端开发者的抵触。

回到描述文本的思路上来。如果描述文本能够准确的生成易读 API 文档的同时,还能生成前端数据校验检查器,更进一步生成 Mock 数据,并且基于 Mock 数据实现自动化测试,是不是更有意思?没错,这件事其实我已经做完了,我创建了一个叫 tyshemo 的项目,它为前端提供了一个运行时的类型与结构检查工具,同时,基于它的描述能力,上述说的文档功能、Mock 功能、自动化测试功能,也轻松实现了。为什么可以?因为在类型系统的构建上,它遵循“描述”系统,而非“约定”系统。所谓描述系统,是基于已知信息,推演更多信息;而约定系统,则是基于共识,框定行为范围。具体举个例子,虽然都是对类型进行检查,TypeScript 是描述系统,而 prop-types 是约定系统

在前后端共同开发过程中,使用一套描述系统之所以难以实施,在于没有共通语言进行描述。而我,找到了这个共通语言:JSON。

“PHP 不是世界上最好的语言,JSON 才是”。虽说 JSON 最大的问题是没有注释,但是作为描述语言,它本身就是用于描述的,它本身就有注释性,给注释加注释说不通呀!而使用 JSON 的最大好处,除了前后端开发者都能看懂外,它还可以轻易的在 HTTP 中传输,几乎没有什么约束。

{
  "name": "string",
  "age": "number",
  "body": {
    "head": "boolean",
    "hand": {
      "left": "boolean",
      "right": "boolean"
    }
  }
}

虽然上面的描述有点细思极恐,但我相信,无论是刚入编程的新萌,还是梭哈多年的老鸟,都能用自己的膝跳反射读懂这一串 JSON 所描述的内容。现在,我们把它作为后端 API 接口返回的数据描述,我可以用小拇指就能想出如何将它解析为可被用于类型校验的 JS 程序,以及基于数据类型生成 Mock 数据的 express 中间价,至于文档,哦,你还需要一个在线文档吗?通过这套方案提前管理前后端在接口输出结构上的一致性,比 GraphQL 方案好的地方在于,这套方案不需要后端改变现有编程方案,只需要人为参与一份 JSON 的维护即可(前后端共建),这份 JSON 即我们所需要的“同构”,无论后端使用什么语言开发,都不影响在接口数据结构一致性上的实现方式。当然,在条件允许的情况下,后端接口可以根据描述返回必要的字段,组装合适的结构,裁剪不必要的字段​,达到和 GraphQL一样的效果(但事实上,后端应该在开发时对照着 JSON 所描述的结构,直接给出结果)。​

等一等,这似乎也不满足我们的一些需求啊!

描述系统的缺陷是,无法简单快速的完成某些复杂结构的说明,这有的时候导致我们很困惑。但是,我想说的是,约定系统并不被禁止,当你无法描述一些东西的时候,我们可以约定它,我们可以约定类型逻辑,甚至约定类型本身,比如:

{
  "name": "?string",
  "age": "number|numeric",
  "parents": "(Person,Person)"
}

我们用符号来约定一些规则,用大写开头的单词约定一些可能应该具备深层结构的对象或实例。不冲突,描述和约定并不冲突。我们要做的,是构筑前后端基于不同语言的解析器,以支撑起我们想要的多语言同构的美丽童话。

领域模型共建

无论是校验逻辑,还是数据结构,它们都太单调了,它们是静态的,虽说有点意思,却无法解决我们实际编程中所面临的业务问题。我们所面临的问题,多半是“有状态”问题。静态规则我写一个正则就可以解析了,可是,当我们的业务在运行中时,应用的状态在变,而这些变化的东西,可能会影响所有上述静态的规则。

举个例子,当 a 字段为 0 时,b 字段要使用 X 规则校验,而如果 a 规则为 1 时,b 字段要使用 Y 规则进行校验。这……再一个例子,后端返回的接口中,当 a 字段为 0 时,b 字段的类型为 string,但当 a 字段为 1 时,b 字段返回的类型为 number。这……要用纯文本描述,还得把业务特殊性给兜住,办不到……办不到……

等等,真的办不到吗?

用静态的方式,概括动态的上下文,这件事我们没做过吗?在前端开发中,我们天天在做。“实例”来自“类”,而“类”不就是静态的吗?或者,“接口”不就是静态的吗?当然,“接口”本身并不包含动态上下文的全部描述,只有我们“实现接口”之后,我们才得到了一个完整的描述,结构体应该具备什么属性成员,它的方法成员将会带来哪些副作用等等。

再往上走,我们的业务在运行时所制造的状态变化,是按照什么描述而发生的呢?

我们用领域模型描述领域对象的业务逻辑。领域模型是静态的,不变的,它描述了一个领域对象在运行时将拥有哪些属性,当操作领域对象的方法时,将会带来哪些副作用(变化)。我们阅读领域模型,便知道该业务拥有什么,能干什么,不拥有什么,不能干什么。不过,不得不说的是,我们阅读领域模型,所得到的信息是不连贯的,我们知道领域对象的能力,但我们不能知道在运行时,由于什么环境让它释放了这种能力,不同属性和方法之间需要通过什么操作逻辑进行前后顺序关联。总而言之,领域模型是基于描述的抽象体,是我们业务流转的核心和基础。

你可能会埋怨:我们用得着领域模型吗?前端需要领域模型吗?

需要的。当你需要管理复杂的业务流转的时候,你务必需要分清楚,当前流转中的业务,它是对什么领域对象在操作。而只有拥有领域模型,你才能对你所操作的对象心知肚明。提高前端开发的整体门槛,是保障前端工程稳定可靠的途径之一。我已经厌倦了把代码写给新手看,“新人接手才能更快上手”的逻辑!为什么我们的高校老师会说,学前端只要会点 jQuery 就可以走遍天下了?因为我们的项目通过降低编程结构的前瞻性,牺牲业务逻辑的抽象性,来成全新人立即上手的便捷性。为什么工厂工人需要集中培训一个月,而到了前端这里就立即上手开始撸?如果一个项目任何人都可以立即上手开始撸,那对于一知半解的新人,随手写句烂代码,暗暗庆幸“效果出来了”,岂不是高楼少砖,飞机缺钉。新人加入团队,不应该由老成员低下身,配合新成员写效率低下的,以界面效果为导向的流水账代码,而应该是新成员仰起头,通过学习和研究项目的编程结构和领域模型,掌握项目的前瞻性和抽象性,之后才开始上手接触业务编写。

让我们回到同构。

既然领域模型是基于描述的,那么我们就可以延续我们前面提出的同构方式。JSON 为我们提供了共通的描述语言。而领域模型又是静态的,岂不是我们可以通过 JSON 来描述领域模型?

{
  "schema": {
    "age": {
      "default": 0,
      "type": "number",
      "validators": [
        {
          "validate(value)": "value > 0",
          "message": "年龄必须大于0"
        }
      ]
    },
  },
  "methods": {
    "grow()": "age ++"
  }
}

我用上面的 JSON 描述了一个模型,该模型包含一个 age 属性和 grow 方法。age 属性默认值为 0,数值类型,且在校验时要求值大于 0,否则会给出提示文案。grow 方法是使得 age 属性自加。我们并不知道,什么时候会发生校验,也不知道什么时候 grow 会被调用,然而,我们却读懂了这个模型所包含的一切。

前后端使用同一个领域模型未尝不可,但是由于运行环境的差异,前后端领域模型还是会比较大的不同。以前文的 unique:posts 这个校验规则为例,在后端将记录插入到数据库之前,需要检查当前记录的 title 字段是否已经被其他记录占用了。这一条规则几乎不能被前端所直接使用,因为后端不可能把所有记录的 title 一次性返回给前端,唯一可行的比较好的体验,是用户输入 title 的时候,就立即通过 ajax 交互,反馈当前 title 是否可用。这个例子说明,前后端共用同一个模型,很多情况下是不行的。但是,前端所使用的模型,却可以来自后端,它可以是后端模型的子集,或者后端处理过后的优化模型。通过 JSON 的方式,这一模型被传送给前端。

但如果我们能够解释模型的 JSON,那么我们就能实例化模型,得到运行时的实体对象。而这个对象,和我们用代码本身写死的对象,并无二致。通过文本描述,在运行时得到模型实体,并进行进一步操作,这是一种典型的反射思想。我们若能在我们特有的业务系统中实现这一套反射接口,或许看上去复杂的问题也变得非常简单。

在 HTTP 的两端,虽然运行的代码不同,却因为一份基于文本描述的 JSON,可以最大限度的保证在大部分业务逻辑上,它们是一致的。我们要做的,是构筑前后端基于不同语言的转换器和解析器,实现前端反射机制,确保业务尽可能准确,房子就可以修的越高,飞机就可以飞的更久。

TDL 驱动业务自定义

TDL(Transfer Description Language)指基于传输协议的描述语言,即通过后端发送用描述语言编写的描述文本给前端,由前端解释该描述文本并创建运行时对象。和从后台加载真实脚本到前端进行执行不同,TDL 需要先接收再解释后执行。加载脚本是不够安全的,前端并不能确保动态传输的脚本是否安全,但 TDL 是安全的。总的来说,我们前面提到的通过 JSON 发送领域模型给前端使用,本质上是一种 TDL。

业务自定义是大部分系统所想要的美好构想。例如自定义权限逻辑、自定义表单、自定义布局和交互……

我们可以想象,存在这样一种前端应用,它本身没有任何业务逻辑的代码实现,它是一个壳,它是一个 TDL 的运行器,所有的业务逻辑都由后端决定,并通过 TDL 动态执行。这样的应用其实很常见,以一个在线excel表格为例,它具备排序、字段筛选、搜索、格式化、表头固定、栏固定、字体颜色、表达式等等特性,而相同的一个前端代码,却要完成无数用户的无数场景,怎么做到的?就是通过 TDL,将所有这些用以表现的描述,随表格数据一起通过接口返回。前端仅仅是一个解释器和交互呈现装置,不需要业务逻辑,所有的业务逻辑通过 TDL 传输,并通过前后端的约定,加以解释。

著名的框架 strapi 拥有无限自定义的能力,它通过巧妙的架构,实现业务自定义配置化。这和我们将业务写在代码中完全不同,写死在代码中的业务,一旦稍有改动,就需要完成复杂的发版流程。而基于自定义配置化的业务,业务的变动只需要通过在线手动配置,即可轻松修改。它在界面上将业务的属性、逻辑,通过用户交互完成逻辑关联,将这种关联抽象为描述信息,存储在数据库中,需要的时候,从数据库中读取出来,加以解释。当这些配置被存储在数据库中时,仅仅是一些描述文本,但当它们被代码解释并运行时,就组建起极为强大的业务能力。自定义,是代码工程的最高境界,它看似是后端问题,实质是前端问题。当这些配置以 TDL 发送给前端,也可以让前端同时具备极为强大的业务能力。

TDL 还能帮前端省代码量,让前端专注于表现逻辑,而非业务逻辑。对于前端而言,业务本身并不重要,重要的是可以对传输的描述文本实现完整解释。一旦 TDL 运行起来,任何业务都可以在前端表现出来,因为前端并不需要知道业务本身,而是需要解释用于描述业务的 TDL 的能力。如此一来,同一套前端代码,可以适用于千变万化的业务需求,只要它们的 TDL 遵循相同语法。

当然,撰写 TDL 解释器需要花费一些精力,但得到的收益未尝不是一劳永逸。我们要做的,是在前后端之间建立起 TDL 桥梁,构筑前端与后端对 TDL 的输出和解释,确保在前端与业务解耦,通过解释器完成所有业务逻辑的指令,这样,前端从复杂业务中被解脱出来,让表现层的东西更优雅,更从容不迫。

结束语

从前后端同构讲起,我们以校验逻辑的描述文本、数据类型和结构的 JSON 描述、领域模型的反射、TDL 为切入口,一层一层的去探讨探讨前后端跨语言同构。不过,从本质上讲,这里的“同构”和我们传统意义的基于代码共享(使用同一份代码)的同构,完全是两回事。这里的同构是,如何在前后端之间,构筑起一个可通过 HTTP 传输描述文件实现业务逻辑后端化,后端专注业务,前端业务解耦,专注表现层,通过 TDL 确保前后端一致性准确性,由于 TDL 不依赖前后端本身的实现语言,因此,可以说是跨语言的,这样的编程方案。但是不要忘记,美丽的东西总是带刺,让前端脱离业务是理想中的好事,前端少了很多事,后端也完全可以自洽业务逻辑,然而,当问题出现的时候,调试难度会上来,由于领域模型实际在后端,而对领域对象的操作在前端,导致一个完整的业务实现,需要完成从后端到前端再回到后端的整个数据流转,前后端耦合增强,在具体问题上可以说又是死循环般无解。但无论如何,我认为这种尝试是值得的,如果没有这种尝试,我们将永远陷在当前复杂的业务逻辑中无法自拔,而当我们尝试了,尝到了甜头,尝到了苦头,才会最终明白,我们确实需要什么,我们也确实不需要什么。

2020-06-26 104

为价值买单

本文价值1.04RMB