Recent attention to gayhub ali warehouse new open a code base, address: https://github.com/alibaba/schema-plugin-flow, see the README file on the introduction, this is a can let developers by modifying the configuration code, Extensions to the business logic and page layout can be accomplished, avoiding changes to the source code. At first glance, I thought it was a set of solutions related to low code, but after actually watching it and playing it, I feel it is not accurate to define it in this way. Let’s have a look at it in detail.
A, positioning
I just mentioned that WHEN I first contacted Sifo, I thought it was a solution with low code, but this expression is not accurate. Let’s take a look at another solution with similar capabilities, namely Amis of Baidu. This solution focuses entirely on low code. It aims to build front-end pages quickly and cheaply by means of JSON configuration. Sifo is very similar in that it organizes the page structure through JSON configuration.
First of all, I would like to talk about why low code should be studied in the front end. In fact, I personally think the application scenarios of Low Code are mostly some business scenarios in the B end. Why do you say so? Because most pages of b-side businesses are fixed, they are more about the arrangement, combination and extension of various forms, tables, data, graphs, etc., which often occur in these business scenarios. Pages are very similar, but there are always some special customized changes and business requirements, which are particularly common in enterprise Sass services.
And business in this scenario, if we are in accordance with the conventional solution to develop these business requirements, then pay the resource is huge, on the one hand, is in the development of the above, each development of such a page that requires developers to write a lot of duplicate code, although can through the way of component reuse to solve some trouble, But it’s still up to the developers to organize the code to make the pages we want.
Low code solution is to deal with this business scenario, such a low cost way, through JSON configuration to complete rapid organization of the page, this organization does not need front-end technology have high requirements for developers, even can be realized to server configuration, direct injection through metadata generated page. This is where amis’s main foothold is.
The traditional development method, on the other hand, needs huge resources, is in the late maintenance and update above. For example, as mentioned earlier, in some generic scenarios, there is a need to customize services. In this case, it is very expensive to reuse components or page source code, and it will affect other related areas. This is where a high scalability capability comes in. This is where Sifo focuses its focus. It can implement secondary development extensions without infecting source code through internal controllers, which is one of its main capabilities.
Therefore, we should accurately position these two solutions. Amis is a pure low code fast and low-cost configuration generation page solution, focusing on low code, while Sifo is a high expansion configuration generation page solution, focusing on high expansion.
, of course, this part of the content of the low code is based on the two solutions do partial comparison and analysis, the effect of low code is far more than that, and finally the ultimate goal of no code to pursue the visual to build this together, is a promising research direction, if there is anything wrong place still please correct me.
Second, the use of
Sifo’s official documentation also provides detailed guidelines on how to use Hello World, but there are no more details here. You can go to the warehouse through the link posted above to check, CV with other not good this is still very good. Here basically say a few feelings after initial overhand use. Here are some examples:
Advantages:
- Low learning cost
- Low business infection
- Low access cost
- High scalability
Inadequate:
- Application scenarios have limited support and limitations
- Slightly more demanding for developers
The following is a detailed explanation of the source of my brother’s views, of course, I did not put the specific demo code here, rather than see my demo to see the official demo to understand, personally feel that out of the real business scene of the demo are almost the same:
1. Low learning costs
Getting started with Sifo is easy if you have a front-end foundation, and Sifo’s current target audience should be developers. If you want to run, follow the example code on the official website to run directly. The initial use of SifoModel clear this core of several parameters can almost normal start.
The schema is a CONFIGURATION JSON file for a page structure, and Plugins are Plugins for that page, such as pages, components, models, and so on. Namesapce is related to secondary development extensions. Here’s how it works (vUE as an example):
This approach is very similar to amis, where a JSON file is used as the main structure of the page, and other capabilities are added, including some built-in UI libraries. Sifo uses ant’s Ant-Design family of component libraries as the built-in default. A data-driven page configuration is implemented.
2. Low business infection
First Sifo’s official description is that it is a highly extensible JavaScript library. In other words, Sifo is a low-level runtime that is completely independent from common UI frameworks such as React/Vue. In other words, in the actual operation process, Sifo has almost no interference with the business code written in these UI frameworks.
In other words, when we use Sifo, apart from the business-related code in the upper UI framework library and the way components are used in combination with Sifo, everything in the Sifo framework layer is exactly the same and can be reused. In the Sifo framework, it can be understood that the Sifo Schema corresponds to the configuration on the page, which is closely related to our components, while the Plugin handles some business logic, which can be completely separated and reused. This is the idea of pluggable plug-in development.
3. Low access cost
Which I think is one of the features of Sifo, as compared to the amis, amis currently only support in the React under the environment of use, or use the JDK, of course can’t use the JDK for some custom power use, such as custom components and so on, this is a way for developers to use, We will not discuss it here. Sifo is completely decoupled from THE UI framework mentioned above, and perfectly supports React and Vue UI frameworks, which is very friendly to me as a Vue graphic cutter. Because it is completely decoupled from the UI framework, we can quickly access Sifo by making component-level modifications to the original project, and the overall project migration cost is not too high.
You can see that both UI frameworks are supported in the Sifo source code. But to use vue-related capabilities in Amis, you not only need to use custom correlation capabilities, but you also need to introduce VUE correlation in the custom React component. Of course, because of the different focus of the two solutions, there are some functional differences. It’s hard to say which one is better than the other, but Sifo is more friendly to companies and developers using the Vue technology stack.
4. High scalability
This is at the heart of Sifo, as the official emphasis is on high scalability. The extensibility I understand here is mostly at the component level, and less at the business level. How to put it? First of all, the business and logical composition of Sifo is summarized. At the component level, it is completed by built-in components or self-developed custom components. At the page level, the pages are organized by JSON configuration files configured by Schema, and then the logic level is reused and organized by Plugin. This way of composition completely separated the view from the logic layer, so our implementation separated from the business logic, the view layer page structure modification, rendering component modification, component internal transformation provides the basis for implementation. Of course we could just modify the business source code. That is, components, pages, and logical plug-ins can be replaced and extended flexibly. This is good news for b-side Sass service business scenarios.
Amis has no such capability. When changing some view or logic within the framework, it is necessary to first hack into the original page source code, find the corresponding module, and then carry out corresponding operations. It’s really limited in terms of scalability.
5. Application scenarios are limited
In current use, Sifo solutions are applicable to the B end of the page scene is relatively fixed business scenarios, in the end, C higher request for high extension ability, take the WeChat before my internship experience, a component might involve other ability to view and the other three components, handling of logic and the difference at the same time, In this scenario, using this configuration to organize the page may not be as handy as using it on the B side. If official developers are willing to go in this direction and do some deeper optimizations for high scale in some complex scenarios, THEN I believe Sifo will be more and more widely used and influential. Of course, this is only my partial understanding.
6. Technical requirements
This is one of Sifo’s weaknesses that I personally feel is that amis can provide a JDK approach for non-developers to directly configure and generate pages, whereas Sifo requires a certain front-end foundation to get started. Can we also consider making some simplified versions for non-front-end developers? This will also help with Sifo’s use elsewhere. Of course, amis is mainly aimed at configuring and generating pages. The audience is not necessarily front-end developers, while Sifo is more aimed at helping front-end developers to solve the problems of view and logic coupling, low efficiency of repetitive pages and low expansibility of traditional development in the development process.
Third, the end
Actually my personal understanding of Sifo is not particularly deep, is also a learning and learn in use of stage, just some thoughts in the process of using, remembered before the many development scenarios can use this ability to quickly solve, in the process also do with some B friend amway this framework, they also in the process of using evaluation, Some friends told me that such ability can be handed over to the backend students to complete the control of the front-end page. After a careful thought, it is indeed true. The backend students return a schema configuration, and the front-end students write the appropriate render and plugin, which can indeed achieve the generation of server-side configuration pages. All in all, I have only seen the tip of the iceberg of Sifo capability. What I have seen so far is only low code and high expansion. In the next step, I plan to use it gradually in my own team, reconstruct some previous infrastructure systems with Sifo, and then try deeper capabilities. This wave is tailored to specific business scenarios, specific problem – specific analysis. This wave I’m on the first floor. After the feedback from the team, I will evaluate some original and deeper abilities, hoping to see more abilities of Sifo, which is also a process of learning by myself.