01

写作背景

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

02

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

1、前端、后端

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

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

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

1. 一方面微服务思想普及导致api向原子化演进，另一方面产品由于用户体验多变需求，也希望前端承担更多的接口组合、业务逻辑实现职责，以缩短开发响应用户需求的路径。这时候这就需要有地方去承载这些实现，如果都在应用前端实现，那当有多端或者多系统需求的时候，这些业务逻辑就需要重复实现，这对程序员来说是无法忍受的事情。这也是前端引入BFF的最根本最原始的原因。

2. 前端请求性能优化的考虑。把多个网络请求组合放在靠近微服务的BFF层实现，可以解决因存在多次串行请求所带来的用户体验问题。

3. 前后端彻底分离。前后端独立开发更加方便：前端灵活性，即使有微服务迁移，也不影响前端。

4. 此外，在实际实践中，我们经常还会在BFF实现用户认证和部分鉴权工作。
   

但是在低代码应用中，我们引入了GraphQL做数据整合、且开放了可视化 schema 设计，前面两点问题基本得到解决；另外我们本身就不希望用户区分前后端，认证、鉴权也都可以页面对应的后端服务中实现，因此后两点本身也不是什么问题。

05

总结

• 低代码目标客户群体（非程序员用户）不需要被动接受前后端服务的划分

• 低代码应用设计中应该体现设计抽象（页面、接口、逻辑、数据），不应该体现实现逻辑（前后端）。

• 在低代码应用实现中，不需要引入BFF做彻底前后端分离。

06

后记

– END –

 报告下载 

大佬观点