In recent years, the discussion about LowCode and NoCode is getting more and more popular in the front-end community. Simply speaking, LowCode is to complete the development and launch of the application by writing a small amount of code, while NoCode is further, the whole application development can be completed through configuration without writing code. At present, there are many low-code platforms within the group, such as iceluna, Eitab, Lego, Yunfengdi, etc., while the general code-free platform is still in the exploration stage.
Low code and no code
First whether low code or no code, is aimed at a particular scenario or niche, such as operating activities page, in the background of the form, form, etc., because only in these scenarios, the front-end interactive relative convergence, can precipitate out enough component material, through a visual way to drag and drop components can directly build page.
At present, my team is studying the middle and back end front-end solution for the marketing domain. Generally speaking, the core of the solution in the background the goal is to effect, effect includes two aspects, on the one hand is the effect of r&d personnel, on the other hand is to the user’s effect, the effect of core gripper is the change in the production relations, developed by the front-end to back-end, vision, products all aspects involved in the development, thus reducing the threshold of the front-end development, improve the production efficiency. Instead of addressing 20 percent of individual incremental requirements, the solution is to engage the “non-front end” and address 80 percent of general requirements. Most of the improvement paths in the middle and background are ProCode->LowCode->NoCode.
On the surface, ProCode->LowCode->NoCode looks like there is only a small difference, as if it is only a matter of how much code, but the whole process has changed from quantitative to qualitative. ProCode and LowCode are mainly aimed at people who need front-end programming skills, while NoCode represents front-end page building that “non-front-end” can participate in. This does not mean that code is not needed at all, because today it is difficult to define what “code” is. For example, when a user writes a configuration file, This file is in JSON format. Is that code or not? Therefore, NoCode does not mean that there is NoCode, but that the user learning threshold and learning cost is reduced, ordinary users do not need to go through the difficult learning can achieve the previous program to achieve the code.
Pain points of iceluna’s low code platform
Iceluna, as an excellent low-code building platform within the group, mainly solves the scene of rapid page building in the middle and background. After several years of exploration, it can basically realize the visual building of page UI, but it still needs to be manually coded for business logic. This is a relatively high threshold for non-front-end developers to get started. The graph below is a recent survey of iceluna users (front end, back end, and test), and it shows that the learning costs of logical code and data binding are also the most cited by users in the questionnaire.
Therefore, in this fiscal year, we tried to solve logic-related problems in the way of visual logic orchestration, solve the last part of low code that needs to be coded, and realize the development mode without code, so as to further reduce the learning and use threshold of users.
Visual logic orchestration
Let’s start with a logical choreography example to see what a piece of code looks like when rendered in choreography:
As shown in the figure above, the logic of the product becomes very intuitive when the otherwise obscure code logic is expressed in the form of a flowchart. Readability and maintainability are also very high. There is no need to worry about non-standard annotations and incomplete documentation when taking over other people’s projects. The logical graph generated by logical orchestration is a natural product document.
Logical node abstraction
It can be seen that to form such a logical atlas, it is necessary to combine and series different logical nodes in essence, and the real logic is completed by functions encapsulated in the nodes. Then there are two problems. First, how to abstract the logical nodes. Whether the abstract logical nodes can be reused directly determines the cost of user orchestration. Secondly, the granularity of logical nodes is also very important. If the granularity of encapsulated logic is too large, as large as a functional service, it may become business process choreography. If the granularity is too small, down to the level of an expression, it may be more efficient for students with programming background to write code directly.
Based on the background of marketing domain part of the business code, found in the background page are mostly in the form and list, details, and 90% of the business logic basically all around in the form (check, value, value assignment and submit), a dialog box (hidden, tips), send the request, the message prompt, data processing, routing the jump, the condition judgment, etc., Relatively convergent. Iceluna at the same time as the group stage of the excellent low code, in the upper encapsulates many very good API, shielding the differences on the level of most front-end grammar, such as state assignment, a page refresh, interface calls, some commonly used tools function (time), etc., for the logical node abstraction provides a great convenience.
Through analysis and classification, about 10 logical nodes are finally precipitated, as shown in the figure below. At the same time, each logical node is essentially corresponding to a section of execution function, and receives one parameter as the input parameter and returns one parameter as the output parameter.
Choreography agreement
Since it is a visual arrangement, the arrangement protocol cannot be avoided naturally. In order to avoid repeated construction and maximize reuse of the existing arrangement scheme within the group, the final plan is to adopt the LF general visual logical arrangement protocol to realize the logical arrangement in ICELuna.
Technical architecture diagram
Technical difficulties
Automated layout
From the very beginning research we found that most of the products, is to let the user to drag and drop, operations such as attachment to complete, but through the analysis of former face logic code, if we will use an asynchronous callback operation async/await converts the synchronization method and most logic code can be regarded as a kind of serial execution process, Occasionally superimpose if/else branch judgments, which is also very consistent with people’s common thinking pattern and very intuitive to understand. Therefore, from the perspective of layout, it is to connect different logical nodes and branch judgment nodes in series, which does not need too much flexibility in layout, and the connection operation is also redundant, so we changed all the drag and drop connections to add nodes, and then automatically connect.
With the method of the automatic layout can greatly simplify the operation of the user, the user can focus on core business logic processes, in order to add nodes can, but it also brings a problem, because the branch node can produce two types of branch flow, if there are any nested branches, need to automatically the upper branches of the location of the abscissa unified offset a unit to the right, Otherwise, node positions on different branches of upper and lower levels may overlap. To this end, I designed an automatic layout algorithm, the final realization of the effect picture is as follows:
The algorithm process is relatively simple, using DFS depth-first traversal algorithm, the detailed process will not be described here.
Code interrolls with schema
After the logical diagram is choreographed, the next problem is how to ensure that the choreographed logic runs correctly and produces the same effect as the source code. At the beginning, there were two schemes discussed. The first scheme regarded the whole logic as an event flow, and completed the upstream and downstream series of logical nodes by means of event registration monitoring according to the previously designed logic layout schema. Finally, a set of event actuators were designed to trigger events successively. This approach is relatively simple to implement, but more intrusive to the original development process. Because the original places where event functions were stored would be replaced with logical schema, and the front-end students in charge of code review would see the diFF of schema instead of the code diFF, which would undoubtedly greatly increase the risk of CR. So after some discussion, we decided on the second option, where the logically orchestrated schema was automatically converted into code, and the generated code was automatically converted back to the Schema.
Converting code based on schema is easy because each logical node maps itself to a fragment of function, while converting code back to schema is a bit more complicated. In this case, Babel is used to parse the code and obtain the abstract syntax tree AST. Then, the nodes of the type Statement in the AST are traversed. Finally, the corresponding logical nodes are found by regular matching and the lines are connected in series. Here is an example of the generated code:
It can be seen that the code generated by schema is a little different from the source code. It has some characteristics of logical arrangement, but it is more readable and can intuitively deduce the logical flow chart from the code, which reduces the cost of code review to some extent. The entire AST parsing process is as follows:
Breakpoint debugging
For writing business logic, it is inevitable to need debugging function, which is a natural thing for students with programming ability, but when the logic becomes through visual choreography, how to make these “non-front-end” users can also easily through debugging to locate errors, has become particularly critical.
Debugging is essentially for users, it is need a can make arrangements after the process of logical simulation to run, so we do to every link of logical node point, the user can view in the process of simulation run state data of each node and the parameters of the context, the types of error, etc., at the same time, according to the logic flowchart state (green represent the execution is successful, Red indicates failed execution) can also locate the problem very quickly, as shown in the following figure:
The debugging function is still in the early stage, and there will be continuous iterative improvements, such as the addition of a step during debugging, like the browser’s step tool for breakpoints.
Conclusion outlook
conclusion
At present, visual logic orchestration has been officially launched with iceluna low-code platform within the group, and has been officially used in marketing tool business. The transition from low code to no code is still in the exploratory stage, and there will be a lot of problems along the way, but it is a critical step forward and worth looking forward to.
Looking forward to
As mentioned above, from ProCode->LowCode->NoCode, by lowering the threshold of R&D and allowing non-technical personnel to participate in application development, production efficiency can be greatly improved. However, the ideal is full and the reality is also very dull. I think NoCode platform can only be applied in relatively vertical scenarios at present. And since there is no escape mechanism like LowCode that can still write code, NoCode is probably only a 70-something product. However, from another perspective, if a non-technical person can complete a product with about 70 points (MVP of the minimum available product) with a very low threshold, and can directly promote it to the market for trial and error, and if the verification is feasible, continue iterative optimization by converting to LowCode or ProCode. That alone, I think, is valuable and a core driver of business innovation. Therefore, I think the pace of product development in the future may be NoCode->LowCode->ProCode. Each process should have corresponding solutions and be able to get through each other. Only in this way can we survive better in the increasingly competitive market environment.
- Author: Ling Yi