C站专家圈分享——低代码构建WebAPI的原理和经验，技术架构专长。而这几点也是不同低码厂商和产品差异最为明显的地方。今天，我们以活字印刷为例，围绕可视化业务逻辑构建的原理和心得来和大家聊一聊。自2014年Forrester提出低代码概念以来，低代码的定义逐渐清晰。低代码的主要特点是可视化开发的全过程。本质上是一套元数据驱动的可视化开发解决方案。这里的元数据是一个广义的概念，不仅指数据字段的定义，还包括业务逻辑。业务逻辑主要体现在元数据中组件的配置和排列。组件是低代码中最关键的关键。在不同的产品中，这些组件有不同的名称，比如节点、命令等，低代码平台的学习门槛、应用场景、用户群体的差异主要是因为这些组件的抽象层次不同。抽象层次越高，处理复杂应用场景的灵活性就越差。相应的，如果抽象层次低，必然会引入IT技术的概念，导致学习门槛大幅提高。因此，低代码内置组件是否引入了IT技术的概念，尤其是软件开发的概念，是为了区分技术人员的低代码和无代码（业务人员的低代码正在更名为无-代码在市场端，这是Forrester和ChinasoftAssociation)共识的结果的一个重要标志。面向业务人员的组件被设计成倾向于现实中可以看到的东西，比如页面上的元素和操作，比如字段、规则、增删改查等，如果封装级别太高，覆盖的场景就少了.一般来说，可配置项随着封装级别的增加而增加。比如我们封装了4个元素，每个元素有3个配置项，那么需要提供的选项就是3^4=81。如果封装到第一层，那么只提供3*4=12个配置项。现实中的可配置性远不止这3-4。这种高封装的组件显然无法提供这种指数级增长的可配置性，最终会表现出灵活性和可配置性不足。走向另一个极端，编码开发中常见命令式和声明式语言。从广义上讲，这两者都可以成为元数据。比如C#需要编译成IL，CLR加载IL执行动作。IL这里是元数据。因为封装级别太低，用户无法感知。在命令式语言的基础上，还有一类是声明式语言。声明式语言的封装级别得到了一定程度的提高，通常是面向特定领域的，提供了足够的灵活性。比如页面渲染中的HTML，数据库操作中的SQL。与命令式语言相比，声明式语言的优缺点一目了然。总的来说，在当前的软件开发领域使用声明式语言利大于弊。最后补充一点，最开始的桌面应用开发，无论是MFC还是WinForm，都是使用命令式语言。后来WPF、H5、Android、iOS都转为声明式语言。可见声明式语言在界面显示上是有优势的。一个不可忽视的原因是早期终端设备的计算能力太差，无法承担分析工作；现在交互终端的计算能力越来越强，解析声明式语言的性能开销已经被客户忽略了。回到低代码的话题，低代码平台提供的组件封装是介于业务模型和声明式语言之间的。我们以驾照识别为例。抽象层次可以简单分为四层。封装粒度越低越高。不同的低代码平台在这件事上有什么区别？根据低代码概念的开创者Forrester的说法，低代码平台可以分为两类：专业开发人员和业务人员。在这件事上封装级别有非常显着的差异。前者通常会提供所有四个层级，而后者通常会提供上面两个层级。因此，对于业务人员来说低代码，不支持复杂的业务逻辑和WebAPI构建能力是很容易理解的。不是技术不能变现，而是市场定位不用做。作为ForresterLCDPforPRO的代表产品之一，MovableType为构建复杂的业务逻辑提供了怎样的组件和编排体验？首先，在设计时，MovableType将组件的封装层次降低到接近编码开发的层次，并在此基础上提供一些常用的高级能力。经验上，用表达式树的形式来模拟编码开发的缩进层次。整套逻辑编排机制可以运行在前端，也可以运行在后端。除了组件和编排之外，我们还需要提供一些可以与组件交互的功能。为了尽可能多地覆盖多样化的应用场景，函数库的完备性是一个不小的挑战。.NET和VBA的函数库过于分散和庞大，所以我们选择参考另一个企业信息化常用的解决方案Excel。因此，我们以Excel公式为模板，实现了400多个计算公式。选择这条路的另一个重要原因是，在过去的30年里，我们在开发Spread表格控件的同时，积累了一套完整的表达式引擎。直接拿来放到业务逻辑引擎中，会事半功倍，成熟度高。如果自己做类似的功能，也可以使用SpreadJS直接调用里面的CalcEngine。复杂的业务逻辑通常不能保证一步到位，所以在解决了构建问题之后，我们还需要解决调试和自测的问题。调试是声明式语言相对于命令式语言的劣势，比如我们无法调试HTML的渲染过程。然而，SQLManagementStudio给了我们一个解决方案：将执行日志完整地打出来。这里的“完整”是指输出每一步的变量、每一个分支条件、每一个组件的执行时间，以及所有操作数据库的SQL语句。这种日志不仅可以用于自测和调试，后期需要维护这个业务逻辑，甚至接管别人开发的业务逻辑时，可视化的表达树和完整的执行日志能起到很大的作用。在复杂的业务能力基础上，构建WebAPI水到渠成。我们只需要根据服务端运行的业务逻辑，提供WebAPI所需的“外壳”即可。从这里的介绍，我们可以明显感受到，用于构建WebAPI和复杂业务逻辑的组件都是面向开发者的语言系统，这再次印证了面向业务人员的低代码和无代码平台通常不会提供类似的功能。判断。毕竟，如果要为没有任何IT基础的业务人员培训这样的系统，投入是巨大的，回报的风险也很大。回到产品需求，如果我们只是开发复杂的业务逻辑，我们似乎不需要构建WebAPI。那么，为什么MovableType专门开发了WebAPI构建能力，又可以用来做什么呢？就为了前后端分离，让低代码开发和编码开发可以配合？这真的很重要。这为我们的团队从编码开发过渡到低代码增加了一条更现实的路径，但仅此而已吗？答案显然是否定的，WebAPI的主要应用场景是系统集成。企业信息化走到今天，每个企业都已经有了各种各样的软件应用。如何与这些不同时代、不同技术架构的系统进行整合，减少数据孤岛？这是低代码平台必须解决的问题，至少不能造成新的数据孤岛。在做集成的时候，除了主动调用其他系统外，提供WebAPI接口供其他系统调用是一个很常见的场景。说了这么多，让我们看一个8分钟的视频，直观感受下如何搭建第三方调用的WebAPI，以及如何在WebAPI中调用第三方WebAPI。综上所述，今天我们讨论了低代码与元数据驱动的关系，组件抽象与应用场景和灵活性的关系，用于支持复杂业务逻辑的组件设计和编排方式，以及输出详细日志到协助调试。将业务逻辑封装成WebAPI的要点和系统集成的应用场景。最后用一段视频直观地展示了使用活字格构建WebAPI的用户体验。今天展示的活字低代码开发平台官网可以免费下载。几个月前我做了一个公开课，详细介绍了使用活字创建WebAPI的过程。有视频和活字低码平台，有兴趣的朋友可以自己体验一下。《【掘金公开课】补全短板，走向全栈：低代码开发纯前端或纯后端应用》https://juejin.cn/live/3808810问答：问：宁老师，我读了受益匪浅。我有两个问题：（1）低代码工具对项目开发效率有没有量化的提升？指数？(2)如果需要程序员解决自定义功能问题，是否有相应的开发语言接入机制？A：问题1，我这里有几个项目的实际案例。效率提升的程度主要取决于项目需求的类型。增删改查比例越高，提升越大。接口精细化要求越低，提升越大。这里的第二个和第三个规模和复杂度差不多，只是因为第三个是针对连锁医美会员客户，接口要求高，开发效率影响很大；问题2，哪个低代码平台？这完全取决于制造商自己。大多数都提供不同级别的编程接口。允许您接管和替换任何级别，以满足低代码平台内置能力无法处理的场景。前端需要提供一个JS接口来操作页面元素；后端需要提供Java/C#接口来实现特殊的API集成；数据库端也必须支持直接执行SQL语句以提高性能；用户认证层支持安全接口，实现用户集成。如果再“高级”一点，就必须支持插件接口，可以直接扩展低代码平台的能力，提供给自己使用，卖给其他开发者盈利。Q：这个低代码平台和RPA厂商的低代码平台有什么区别？A：RPA厂商，低代码是为了扩展自己的RPA能力，通常是和自己的产品或者场景深度绑定。Q：我觉得Ask，low-code是云厂商可以做还是公司自己做？我现在看到的基本都是云厂商在做A：根据Forrester的报告，云厂商只是其中的一类。但是，各大互联网公司的营销能力是其他类型厂商无法比拟的。Q：这是以前开发者的代码生成器吗？加快开发进度A：可以理解为这是代码生成器的“进阶版”。代码生成器是一次性工具，一旦你在生成的代码上进行开发，通常就无法享受可视化带来的效率提升。低代码走的是元数据驱动的路线，在后续的开发和维护中可以以可视化的方式进行。了解更多低代码内容：https://help.grapecity.com.cn...
