关于云原生:疯了吧这帮人居然用-Go-写前端一

作者 ｜ 郑嘉涛（羣青）
起源 ｜ 尔达 Erda 公众号
​

无一例外，谈到前后端拆散“必然”是 RESTful API，算是定式了。但咱们晓得 REST 在资源划分上的设计总是与 UI 天壤之别，大量专用、特异、乖僻的接口就像永远拾不尽的菌菇，你费劲根除它们，但一场雷雨便又枯树复披。另一方面接口越来越通用，最初却只剩下 CRUD，美其名曰后端只思考稳固和性能，大量业务逻辑却全权“丢”给了前端，不禁让人狐疑，这真的是前后端拆散了吗？

Erda 作为企业一站式云原生 PaaS 平台，也存在着大量面向应用交互的布局各色的界面：从集体后盾到部署总览再到我的项目设置；从集群治理到监控大盘再到成员治理。咱们从 REST 开始做起，但也逐步发生变化。本文将从头讲述咱们如何从的确问题切入，逐渐建设和欠缺 Erda 的前后端拆散框架。
​
因为整个框架牵涉到太多内容，所以我打算以系列文章的模式来进行具体解读。本文次要介绍其产生的原因以及设计思路，更多相干的细节会在后续文章中进行开展，包含但不限于：
​

• 框架实现细节
• 应用框架后测试如何开展？
• 稳定性和工程治理
• ······

简要介绍一下本文的次要构造：
​

• 奢侈的想法
• 交互 vs 业务
• 回归经典
• 组件及协定

后面三个局部次要介绍了咱们建设框架的背景以及计划剖析，“组件及协定”局部则整体论述了框架的外围设计理念。如果你赶时间，倡议间接浏览“组件及协定”局部。
​

奢侈的想法

所有软件公司都会遇到的窘境，那就是分工。老派开发者会崇奉单打独斗全栈的能力，但软件变得复杂之后，分工是不可避免的，而最为显著的就是前后端的分工。

Erda 的前端资源始终是紧缺的，最夸大的时候前后端比例能够达到 1:8，大部分状况下，工程的瓶颈在于前端。咱们很奢侈的认为，扭转这个场面须要后端承当更多的工作，以开释前端的人力。
​

交互 vs 业务

所谓前后端的分工，从根本上来说是交互和业务的划分。

下图是最通用的场景，前端关注视觉、体验等，后端关注 CRUD、平安、稳固等。而业务流程、权限等则是散落在前端和后端，咱们很难说分明一个具体的业务逻辑到底是前端实现的，还是后端实现的。

由上文形容能够预感，这样的划分会导致一些问题：
​

• 重复性工作：进而零碎开发会在某些地位产生忽略（比方前端实现了鉴权，导致后端的鉴权逻辑得不到很好的验证）。
• 前后端对接面积大：带来沟通老本，往往这个老本由前端同学承当，这也是前端资源短缺的起因之一。

试想一下，你是否常常会看到这样的场景：后端写完接口后拍拍屁股走人，独留下前端默默猜想接口的参数意义。包含起初测试出的 BUG，也“总”被认为是前端的问题。

面对下面的问题，业界也存在很多种解决办法，比方采纳 NodeJS：

如上图所示，通过 js 实现来囊括业务流程、权限等逻辑。使得这些逻辑事实上全副纳入前端领域，而后端则被空心化，也就只剩下大家相熟的 CRUD。

这种做法在某种程度上是高效的，也合乎前端界“大一统”的思潮，但对于前端资源有余的现状来讲，该动作无疑是雪上加霜。

同时，也有激进派会采纳低代码平台“一劳永逸”，罗唆不须要前端开发，基于平台的配置和大量的后端流程代码好像出现了一个可能的将来：

不过现有的低代码平台大多仍处于倒退阶段，齐全摒弃前端则会导致交互或者 UI 出现比拟死板和固定，简略来讲就是不够“炫酷”。这也是为什么目前低代码平台大多撑持的是中后盾零碎。

咱们看到业界也有走“复旧”路线的，比方 hey.com 就是如此（https://www.hey.com/how-it-works/）：

所谓“复旧”，指的是页面逻辑大量使用后端渲染，前端只用大量简略的代码（css，js）实现交互细节。就好比古早的 php 以及 jsp 等开发模式，基本上所有的业务逻辑都实现在后端。能够说这种实际是当下对前端框架越来越宏大、nodejs 流行现状的一种“叛变”。

不过咱们也欣慰的看到，即便是所谓“过期”的开发模式，开发出的依然是蕴含当代审美的“炫酷”产品、仍有着非常卓越的交互体验。

全栈的可取之处

hey.com 所用的开发模式，从某种角度上看也能够认为是全栈。

一个人开发前端和后端，这件事件有很大的诱惑力。这也意味着：
​

• 前后端的沟通老本大量缩小，即便前后端都须要熟知业务细节。
• 接口调试老本大量缩小，即便接口设计通过充沛的评审。
• 放到更久远的角度，性能变更和迭代的老本也趋于缩小。

然而，全栈的要求过高，集体很难做到前后端都精通。不过这种一个人负责到底的思维，倒是十分可取。
​

回归经典

Web 的根底是 HTTP。HTTP 申请的指标（target）是资源（resource）。咱们拜访的所有页面都是资源，页面的链接则是资源定位符（URI）。
​
如下图所示，整个流程是这样的：
​

1. 浏览器发动申请，当申请失去解决，服务端传输数据给浏览器以出现界面（这个数据个别为 HTML，一种形容出现形式的语言）。
2. 以表单为例，在出现为表单的界面上进行操作，依照协定和浏览器的实现，则会发动一次新的资源申请（HTTP）。
3. 这次申请须要服务器进行资源更改，胜利后则会从新返回数据给浏览器以出现批改后的界面。

  Name:
  
  

传统的 web 只有最低限度的弹窗、确认、scroll 等浏览器定义的交互元素，提交（submit）则是交互的终结。不过，随着 web 和 js 的倒退，交互有了更多的可能，同时 html5、css3 也为交互提供了更大的根底。

当初，咱们最直观的感触就是网站越来越“炫酷”了，同时也越来越“重”了。站在开发者的角度，前端 js 工程的打包速度甚至比后端工程还要更慢。

有没有一种可能，让咱们所有的技术都回归到经典 web，回归到面向资源（resource）进行操作，回归到上个世纪从新思考交互？咱们进而能够裁减浏览器的交互元素，而不必通过 js 框架实现简单交互；裁减 HTTP 申请使其更适应浏览器出现和交互。

举个例子，咱们正要开发一个工作看板，如果浏览器曾经提供了一个通用的看板交互元素，咱们是不是就能够像应用表单 form 一样，只须要利用这个交互元素再“配置”上业务信息，就可能在不应用额定 js 的状况下，实现这个性能呢？

基于以上，咱们得出了这样的构思：

1. 积淀出一个通用的组件库（来裁减浏览器交互元素），并且这个组件库数量是固定的，咱们将其称之为“通用组件”。
2. 利用通用组件填充进业务数据后能够配置呈现出业务性能，比方登录表单、我的项目创立表单等；通用组件复合业务属性后，咱们称之为“业务组件”，业务组件个数会随着业务增长而收缩。
3. 须要有一个协定来响应交互，达成上述 form 表单的交互流程，然而这个协定须要足够弱小不仅能反对组件库所有组件的交互流程，还须要反对多组件联动的简单场景；这个协定运行在 HTTP 之上，然而与 RESTful 的区别在于，REST 只关注数据且它是无状态的，而咱们构想的协定须要感知界面出现以及反对残缺的交互流程。

如上图所示，通过组件库和协定，能够承载前端一半以上的工作，同时将局部缩小后端与前端重叠的工作，并且前后端仍保有其本身的灵活性。

组件及协定

综上，落实咱们得出的三点构思，须要达成三个档次的事件：
​

• 丰盛的通用组件库
• 组件渲染能力，将业务组件渲染成通用组件
• 协定渲染能力，以解决简单交互

咱们设计了这样一个渲染框架，分两个局部（上图绿色局部）：
​

• 业务组件渲染器：外围是解决业务数据到通用组件的转化，以及通用组件操作（operation）的解决（handle）。
• 场景协定渲染器：外围是将一堆组件编排成为一个场景（能够了解为一个页面，如上图右侧的页面构造）以及场景中组件之间的数据绑定，在有交互产生操作（operation）时，负责决策下派以及操作失效后的从新渲染。

上图两头的通用组件库，则是由前端进行定义和保护的，前端的关注点在于要丰盛这个通用组件库，以及将每个组件的交互和 UI 做到极致（前面会讲到，这些工作即是前端出现器）。

这样的设计初衷旨在大量缩小前端工作，尤其是前后端对接方面，甚至能够认为对接是“反转”的，体现在两个层面：接口定义的反转和开发时序的变动。

接口定义的反转

接口的定义上，传统的由后端主导转向为前端主导。

传统（或者说当初支流）的后端实现为 RESTful API，而前端间接对接这些散落的 API，并且了解接口内构造体的含意。但在组件化的背景下，所谓“前后端对接”被拆成了两局部：渲染和出现。

后面所说的渲染框架（后端）实现了业务到通用组件的渲染，前端定义保护了通用组件库，并实现通用组件的“出现器”，它将通用组件的数据出现为可视化的模式。

在渲染和出现之间的是标准化的通用组件构造（Component Data），咱们能够认为通用组件即为前端主导定义的接口，后端由原先甩手一个 RESTful API，演变成要“被迫”了解通用组件的数据结构以实现业务逻辑，整个局势产生了反转。

乏味的是，因为通用组件的数量是确定的，咱们能够将通用组件开发移植到其余不同出现介质，甚至能够开发出 CLI 界面的出现器，且后端代码无需批改。

开发时序的变动

由传统的后端开发实现后前端联调，转向为前端先实现开发而后端配合联调。

“出现器”使得前端只须要关注通用组件的开发，业务逻辑能够彻底归为后端。如此职责的划分让前端跳出对后端的依赖，能够独立实现设计、开发和调试（只须要 mock 组件数据）。组件的高度复用，前端甚至能够摇身一变成为设计师，跳过高保真设计稿，间接交付实物，而这个时候的后端可能还在与表结构设计苦苦挣扎。

更重要的不仅仅是前端的开发工夫缩短。

咱们能够类比 RESTful API 模式的前后端拆散，同样都是通过“接口”来标准化对接以实现解耦。REST 接口显然是会随着业务而收缩的，通用组件的真正劣势在于彻底剥除业务，使得它的数量绝对恒定且极少。咱们都晓得少即是美（simple is better），实践证明组件越少越能保障每个组件的品质，而前端通过这些高质量组件实现的性能，简直能够认为，调试的工作都在后端了。

更多

• 业务组件真的能隔离业务吗？交互怎么办？
• 协定渲染真的能替换 REST 吗？我只能二选一吗？
• ……

在下篇文章中，咱们将会具体地介绍组件渲染和协定渲染的运行逻辑，以及咱们是如何做到让前端彻底不关怀业务的？
​

Erda 作为开源的一站式云原生 PaaS 平台，具备 DevOps、微服务观测治理、多云治理以及快数据治理等平台级能力。点击下方链接即可参加开源，和泛滥开发者一起探讨、交换，共建开源社区。欢送大家关注、奉献代码和 Star！
​

• Erda Github 地址：https://github.com/erda-project/erda
• Erda Cloud 官网：https://www.erda.cloud/