01 写作背景

在低代码平台建设项目中，最核心最关键是对“应用”的理解和抽象。好比你要建设一个生产工厂，总得先把你要生产的产品设计好。但是在对应用理解和抽象时，产品团队产生了一个很关键的分歧“低代码应用是否需要强制划分出前后端两类服务”。一方的观点是服务（服务是一个独立部署单位，一个应用可以有多个服务组成）只要有“页面、接口、逻辑、数据”这四类设计对象就可以了；另一方的观点是不仅要有这四类对象，而且服务要划分出前端和后端两种类型。以下是个人对这个问题的一些思考和总结，欢迎点评和指正。

02 web应用两种基本的解构方式

1、前端、后端

这种解构方式下，一个完整低代码应用中，用户都至少会看到“前端”“后端”两个服务。这其实是一种程序员视角下的web应用解构方式，体现的是一种实现层面的思维。

2、页面、接口、逻辑、数据，(流程、认证与权限)

这是一种非程序员思维下较为直观的web应用的解构方式（“流程、认证与权限”包含领域拆解思维，不过这不是今天文章探讨的问题，后面有空再单独讨论）。这种拆解方式能更加直观体现出应用设计的思维。

03 第一项建议：在设计层面低代码应用不需要划分出前后端两类服务

1.从用户的角度，要从目标客户群的认知出发

低代码平台的最终目标客户是是非专业程序员、非程序员，因此从降低目标用户认知成本的角度考虑，不应该出现“前端服务”、“后端服务”这两个实现层面的概念；
“页面、接口、逻辑、数据，（流程、认证与权限）”更贴近非程序员对应用设计的直观理解，可以降低用户认知和学习难度。这对一个想覆盖更多人群来赢得市场的低代码产品来说至关重要。而且这种方式能够实现“用户理解和操作”、“应用设计和实现”在用户认知的层面上保持一致。

2.从低代码应用设计的角度，要真正理解应用设计和实现的差异

1）从设计DSL的目的说起

完整的抽象低代码应用
保证应用抽象具有灵活可复用性
保证应用抽象有足够的可扩展性
保证低代码平台本身架构稳定性

因此基于以上四点我们在可视化编辑器到交付物之间设计了一层DSL（由于应用本身横跨多领域，因此低代码DSL会有多项子DSL构成，比如流程由BPMN2.0协议表示、接口定义由swagger表示等等，不过这不是今天文章讨论的重点，后面有空再单独讨论）。

2）DSL的核心功能主要是两项：

把可视化设计转变为DSL脚本（把抽象概念映射成dsl的结构和对象的能力）—>（应用设计）
把DSL脚本解释（实现）成源码、制品及部署（把dsl结构和对象解释成GPL的能力）—>（应用实现）

3）两个核心观点（划重点）：

良好的DSL设计，在应用设计阶段，支持用户表达意图的方式越简单越好、对表达的约束越少越好。按照这个原则，在低代码的例子中，在应用设计阶段，首先DSL脚本中只应该出现“页面、接口、数据、逻辑，（流程、认证与权限）”等概念，不应该出现“前、后端服务”的概念，这对保证DSL脚本的简洁性和确定性至关重要；其次，一旦出现前后端划分，就会约束和限制用户表达设计意图的自由，比如“前端服务”不能操作数据库、后端服务不能带前端页面就是非常典型的一种限制；再比如因为划分了“前、后端服务“，为了满足用户一个界面编辑所有业务逻辑的目的，把所有“前、后端服务”都塞进了同一个编辑界面里，这也是一种限制，而且这种限制导致了交互复杂度和用户使用难度的急剧增加。
在应用实现阶段，可以通过提供不同的DSL解释器，来提供不同的实现。（比如前后端一体化实现或者前后端分离实现）

换一个视角和思路：让用户区分前后端其实类似于让用户在为他所搭建的应用做“前端渲染”还是“服务端渲染”这样的技术实现方案的选择。首先，这种选择对用户实现业务功能来说没有任何意义；其次，一旦把前后端概念暴露给用户了，不仅用户已经没得选了，而且应用实现方式今后也难于做调整，这其实是一种比较糟糕的“设计、实现”分层策略。

3.在设计层面“页面、接口、逻辑、数据”已经可以完整、自洽的描述一个服务

在设计层面“页面、接口、逻辑、数据”的抽象已经可以完整、自洽的描述一个服务。在此基础之上，强行引入前后端服务的分类，是一种过度的、重复的描述，而且带来了不必要的约束。这种设计的根因是根植于程序员脑中的根深蒂固的前后端分离开发的思维。当然这跟我们低代码产品的演进路径也有一定的关系，后续我会单独写文章介绍。

想象一下，你只是想买一台能用的电脑，但卖家告诉你只能单独买机箱和显示器，没有笔记本也没有一体机，这是挺怪的一个逻辑。

4.“前、后端服务”划分带来的后遗症后患无穷

前面提到过，因为设计阶段区分了“前、后端服务”、前端服务不能操作数据库、后端服务不能带页面的限制，为了满足用户在一个界面编辑所有业务逻辑的目的，把应用所有“服务”都塞进了同一个编辑界面里。这样的设计带来如下两个问题：

1）在用户意图编辑某个服务时，很可能不小心修改到其他服务，因为用户的编辑视图能操作到应用内的所有服务，不管你是从“应用编辑”还是“服务编辑”进入；在编辑界面点击“预览、提交、发布”的时候，用户又得清晰知道并选择要“预览、提交、发布”哪些服务，否则可能带来意向不到的效果，这对使用者来说可能是件令人崩溃的事情。

2）可视化编辑视图“一次可编辑应用的所有服务”跟“一次只编辑应用的一个服务”，后者应用了问题域拆解的思维，通过合理的问题域拆解，设计要面对的复杂度就能显著降低，才能有可控的解决方案；反之，前者没有对问题域做任何拆解，需要一次面对所有的复杂度，解决方案自然同等复杂。可惜的是，在现阶段低代码平台的实现中，我们不仅没有做问题域的拆解，而且还把问题丢回给了用户，这是一种糟糕的解题思路。

我们的设计本来是该帮助客户解决问题的，但是却制造了麻烦。

04 第二项建议：在实现层面也不要划分出前后端服务

在实现层面，在DSL解释、编译和打包阶段，前后端可能需要提供不同的解释器和流水线，但是不建议做前后端完全独立的部署。主要原因是，如果要做完全独立部署，那势必就需要为前端引入BFF。而引入BFF从低代码应用角度出发，除了导致整体实现复杂度会增加以外我想不到有任何明显的收益。解释这一点，我们首先要真正理解BFF产生的原因和目的：

一方面微服务思想普及导致api向原子化演进，另一方面产品由于用户体验多变需求，也希望前端承担更多的接口组合、业务逻辑实现职责，以缩短开发响应用户需求的路径。这时候这就需要有地方去承载这些实现，如果都在应用前端实现，那当有多端或者多系统需求的时候，这些业务逻辑就需要重复实现，这对程序员来说是无法忍受的事情。这也是前端引入BFF的最根本最原始的原因。
前端请求性能优化的考虑。把多个网络请求组合放在靠近微服务的BFF层实现，可以解决因存在多次串行请求所带来的用户体验问题。
前后端彻底分离。前后端独立开发更加方便：前端灵活性，即使有微服务迁移，也不影响前端。
此外，在实际实践中，我们经常还会在BFF实现用户认证和部分鉴权工作。