关于基于 Serverless 的低代码平台思考

下边主要是围绕为什么要低代码(Serverless)，以及关于低代码平台能力方案的一些思考。

首先来看看一个挺有趣的现象：

github上有些项目挺受欢迎，如上图，但是只有readme、license这些，没有功能代码，写着 The best way to write secure and reliable applications. Write nothing; deploy nowhere. 开发安全可靠应用的最佳方式是不写代码，不部署，当然这是带有一定玩笑的话，但是也引发我们的思考，是不是可以用其他的方式代替写代码完成产品的研发? 是不是产品同学可以在不用开发同学介入，完全独立完成一个活动H5的上线？

下边回到文章正题， 讨论为什么要低代码(Serverless)。

产品研发周期

上边这张图是咱们非常熟悉的产品研发周期，咱们是需要不同角色的配合，上下游依赖，共同来完成产品迭代。

研发关注点

下边是从研发的关注点来说，对比不同时期的开发模式：

从传统的机房，也就是服务器时代，需要关心处理从硬件（存储、网络等）到系统再到应用层面的东西，购买使用云服务器，少关注了很多硬件方面的东西，然后到更为简单的Serverless，这个时候就主要关注核心代码的实现；saas提供封装程度更高，但是可能不具备拓展能力，比如可以使用表格服务完成表格相关的功能，但是可能没办法定制化的完成开发整个网页。
Serverless对比传统的开发模式，需要研发关注的是，存储放哪，功能逻辑放哪，各端咋调用，而不用再关注异地容灾、弹性伸缩、负载均衡，内容加速，安全加固，网路专线，数据库申请&维护等等，大大降低研发的物理层，网络层，运维方面的要求。

全代码 低代码 无代码

全代码，低代码 ，无代码三者的区别看上去基本就能大概清楚：无代码是一种封装程度高，抽象，解决问题更为便捷，能够以很简单的方式完成你的述求，但是没办法完全满足你的述求，比如通用Saas，部分业务逻辑适用；咱们大部分的开发方式都需要有很专业的知识，解决各式各样问题；理想情况就是对编程不需要掌握多深，但是也能做出足够通用灵活的一个应用，低代码是最接近这种理想情况的一个方式。

第一部分小结一下：Serverless带来的好处是降低了开发门槛，输出封装能力，赋能给其他角色推进，让开发者更专注于业务逻辑，迭代提效。

下边讨论低代码的平台应该具备需要的能力：低代码的平台应该包括可视化开发，数据模型驱动，拓展性，以及工程化。

可视化开发：将传统的应用逻辑和声明代码映射成拖拽、表单等UI交互，我们比较熟悉的通过拖拽式生成页面UI，可实时预览；或者说是一些逻辑分析也可以流程图的形式生成定义，这图是允许低代码的形式生成一些流程控制，然后这些可视化的交互最终都是会生成DSL，声明式的代码，最终是转成可执行的应用。

第二个数据模型驱动，通过定义数据模型以及模型间的关系来定义应用和核心逻辑。这个能力也挺常见，比如内置数据源，定义好数据模型（字段类型性、校验规则、索引，UI展示形式等）和 模型关系（关联、主子等），生成页面，允许对数据进行CRUD操作.当然也可使用外部数据源。

第三个要素要有一定的拓展性，包括逻辑/服务/UI的拓展性，逻辑这边指的是，举个例子，执行行为A，有两个条件判断，允许多增加条件；服务拓展，除了运行态扩容之外，增加对外输出能力，或者对接其他数据源的能力；UI拓展就好理解，比如组件样式允许背景，文案等等配置。

第四个要素：工程化
沉淀一定的开发套件，流程规范统一化，能大大提升开发调试体验；版本管理以及自动化构建发布，质量保障。

总得来说平台的流程通过可视化配置方式定义页面、 数据模型和流程，生成声明文件， 然后动态解析生成各端可执行的代码逻辑发布到Serverless平台。
具体实施，前端方面，会把页面拆分，然后从上到下，分为区块、高阶组件、基础组件，目标是能够把前端应用以声明式的方式表达出来，DSL的声明，主要是需求要比较容易翻译成前端代码，定义包括组件，嵌套组件，属性，事件等等；
后端这块主要关注的数据，流程，权限控制以及服务拓展，数据模型这块采用的 jsonschema 形式，而流程这块可采用业界比较标准的 bpmn 描述，这些描述性文件最终在发布的时候都会变成云函数可执行代码；
产品化服务运维方面，流量变化比较明显业务，基于Severless，波谷较低投入，波峰能快速实现秒级或者毫秒级服务扩容，很好地应用Serverless自动扩缩容、互相隔离的两个特点。
客户端访问流程，用户访问页面， 前端还是cdn， 服务端则访问的云服务。

以上，如有理解不恰当之处，欢迎指正~