C station expert circle sharing - the principle and experience of low-code construction of WebAPI

Judging from many survey reports, the developer community's evaluation of low-code focuses on several points, the flexibility of pages, the flexibility of business logic, and the professionalism of technical architecture. And these points are also the most obvious areas of difference between different low-code vendors and products. Today, we take movable type as an example, and we will focus on the principle and experience of visual business logic construction and talk to you.

Since Forrester proposed the concept of low-code in 2014, the definition of low-code has gradually become clearer.
The main feature of low-code is the whole process of visual development, which is essentially a set of metadata-driven visual development solutions. The metadata here is a generalized concept, which not only refers to the definition of data fields, but also includes business logic. The business logic in the metadata is mainly reflected in the configuration and arrangement of components.

Components are the most critical key in low code. In different products, these components have different names, such as nodes, commands, etc. The differences in learning thresholds, application scenarios, and user groups of low-code platforms are mainly due to the different degrees of abstraction of these components. The higher the level of abstraction, the less flexible it is to deal with complex application scenarios. Correspondingly, if the degree of abstraction is low, the concept of IT technology will inevitably be introduced, resulting in a significant increase in the learning threshold. Therefore, whether the low-code built-in components introduce the concept of IT technology, especially the concept of software development, is to distinguish between low-code and no-code for technical personnel (low-code for business personnel is being renamed no-code on the market side, is Forrester and China Software Association) consensus).

Business-oriented components tend to be designed for things that can be seen in reality, such as elements and operations on the page, such as fields, rules, additions, deletions, changes, and so on. If the encapsulation level is too high, there will be fewer scenes that can be covered. Generally speaking, configurable items grow with the level of encapsulation. For example, if we encapsulate 4 elements each with 3 configuration items, the options that need to be provided are 3^4=81. If it is encapsulated to the first layer, the provided configuration items are only 3*4=12. In reality, the configurability is far more than 3-4. Such highly packaged components obviously cannot provide this exponentially increasing configurability, and ultimately manifests as worse flexibility and insufficient configurability.

Going to the other extreme are imperative and declarative languages that are common in coding development. Broadly speaking, both of these can be metadata. For example, C# needs to be compiled into IL, and CLR loads IL to perform actions. The IL here is metadata. Because the encapsulation level is too low, users cannot perceive it. On the basis of imperative languages, there is another type of declarative languages. The encapsulation level of the declarative language has been improved to a certain extent, and it is usually oriented to a specific domain and provides sufficient flexibility. Such as HTML in page rendering, SQL in database operations. Compared with imperative languages, the advantages and disadvantages of declarative languages are clear. On the whole, the advantages and disadvantages of using declarative languages in the current software development field outweigh the disadvantages.

Finally, to add that the initial desktop application development, whether it is MFC or WinForm, uses an imperative language. Later, WPF, H5, Android, and iOS were all switched to declarative languages. It can be seen that declarative languages have advantages in interface display.
One reason that cannot be ignored is that the computing power of early terminal devices was too poor to undertake parsing work; now the computing power of interactive terminals is getting stronger and stronger, and the performance overhead of parsing declarative languages has been ignored by customers.

Back to the topic of low-code, the component encapsulation provided by the low-code platform is between the business model and the declarative language. Let's take driver's license recognition as an example. The abstraction level can be simply divided into four levels. The lower the encapsulation granularity is, the higher it is. What is the difference between different low-code platforms in this matter? According to Forrester, who proposed the concept of low-code, low-code platforms can be divided into two categories: professional developers and business personnel. There is a very significant difference in the encapsulation level on this issue. The former usually provides all four layers, while the latter usually provides the upper two layers.

Therefore, for low-code business personnel, it is easy to understand that it does not support complex business logic and WebAPI construction capabilities. It is not that the technology cannot be realized, but that the market positioning does not need to be done.
As one of the representative products of Forrester LCDP for PRO, what kind of components and orchestration experience does movable type provide for complex business logic construction? First of all, when designing, movable type sinks the encapsulation level of components to the level close to coding development, and provides some commonly used high-level capabilities on this basis. In terms of experience, the indentation level of coding development is simulated in the form of expression tree.

The entire set of logical orchestration mechanisms can run on the front end or on the back end.

In addition to components and orchestration, we also need to provide some functions that can interact with components. In order to cover as many diverse application scenarios as possible, the completeness of the function library is a big challenge. The function libraries of .NET and VBA are too scattered and too large, so we chose to refer to another solution commonly used in enterprise informatization, Excel.
Therefore, we used Excel formulas as templates to implement more than 400 calculation formulas. Another important reason for choosing this path is that in the past 30 years, we have accumulated a complete set of expression engines while developing the Spread table control. Take it directly and put it in the business logic engine, it will get twice the result with half the effort, and it has a high degree of maturity. If you do similar functions yourself, you can also use SpreadJS to directly call the CalcEngine inside.

Complex business logic usually cannot be guaranteed in one step, so after solving the construction problem, we also need to solve the problem of debugging and self-testing. Debugging is the disadvantage of declarative languages over imperative languages, such as we cannot debug the rendering process of HTML. However, SQL Management Studio gave us a solution: print out the execution log completely. "Complete" here refers to outputting the variables of each step, each branch condition and the execution time of each component, as well as all SQL statements that operate on the database.

This kind of log can not only be used for self-testing and debugging, but also when you need to maintain this business logic in the later stage, or even take over the business logic developed by others, the visual expression tree plus the complete execution log can play a great role.

On the basis of complex business capabilities, the construction of WebAPI is a matter of course. We only need to provide the "shell" required by WebAPI based on the business logic running on the server.

At this point, we can clearly feel that the components used to build WebAPI and complex business logic are all developers-oriented language systems, which once again confirms that low-code and no-code platforms for business people usually do not provide similar functions. judgment. After all, if you want to train such a system for business personnel without any IT foundation, the investment is huge, and the return risk is huge.

Going back to the product requirements, it seems that we don't need to build WebAPI if we just develop complex business logic. So, why does Movable Type specifically come up with WebAPI building capabilities, and what can it be used for? Just to separate the front-end and back-end, and let low-code development and coding development cooperate? This is really important, it adds a more realistic path for our team to transition from coded development to low-code, but only?

The answer is obviously no. The main application scenario of WebAPI is system integration. Enterprise informatization has come to this day, and every enterprise already has various software applications. How to integrate with these systems of different eras and different technical architectures to reduce data islands? This is a problem that low-code platforms must solve, at least not creating new data silos. When doing integration, in addition to actively calling other systems, it is a common scenario to provide WebAPI interfaces for other systems to call.

Having said so much, let's watch an 8-minute video to intuitively feel how to build a WebAPI for third-party calls, and how to call third-party WebAPIs in WebAPI.

To sum up, today we discussed the relationship between low-code and metadata-driven, the relationship between the degree of abstraction of components and application scenarios and flexibility, the design and arrangement of components used to support complex business logic, the mechanism for outputting detailed logs to assist debugging, Encapsulate business logic as the main points of WebAPI and application scenarios of system integration. Finally, a video is used to visually demonstrate the user experience of using movable type to build WebAPI.

The movable type low-code development platform shown today can be downloaded for free on the official website. I gave a public class a few months ago detailing the process of building a WebAPI using movable type. With the video and movable type low-code platform, interested friends can experience it for themselves.

"[Nuggets Open Course] Complete Short Boards and Go Full Stack: Low-Code Development of Pure Front-End or Pure Back-End Applications" https://juejin.cn/live/3808810

Q&A:
Q: Mr. Ning, I have seen a lot of benefits. I have two questions: (1) Are there any quantified indicators for low-code tools to improve project development efficiency? (2) If programmers are required to solve custom functional problems, is there an access mechanism for the corresponding development language?

A: Question 1, I have several actual cases of projects. The extent of efficiency improvement mainly depends on the type of project requirements. The lower the interface refinement requirements, the greater the improvement. The second and third ones here are similar in scale and complexity, just because the third one is for chain medical aesthetics member customers, with high interface requirements, the development efficiency has been greatly affected; question 2, which low-code platform is it? Some are all done by the manufacturers themselves. Most of them provide programming interfaces at all levels. It allows you to take over and replace any level to meet the scenarios where the built-in capabilities of the low-code platform cannot be handled. The front end needs to provide a JS interface to operate page elements; the back end needs to provide a Java/C# interface to realize special API integration; the database end also needs to support the direct execution of SQL statements to improve performance; the user authentication layer supports a secure interface to realize user integration. To be more "advanced", you have to support plug-in interfaces, which can directly expand the capabilities of the low-code platform, provide them for your own use, and sell them to other developers for profit.

Q: What is the difference between this low-code platform and the low-code platform of RPA manufacturers?
A: RPA manufacturers, low-code is to expand their RPA capabilities, usually deeply bound to their own products or scenarios

Q: I would like to ask, can low-code be done only by cloud vendors or by companies themselves? What I see now is basically what cloud manufacturers are doing
A: From the Forrester report, cloud vendors are just one of the categories. It's just that the marketing capabilities of Internet giants are really not comparable to other types of manufacturers.

Q: Is this a code generator for developers before? Speed up development
A: It can be understood that this is an "advanced version" of the code generator. Code generators are one-off tools, and once you develop on the generated code, there is usually no way to enjoy the efficiency gains of visualization. Low-code takes a metadata-driven route, and can be carried out in a visual way in subsequent development and maintenance.

Learn more about low code: https://help.grapecity.com.cn/display/lowcode