preface

I have been dealing with LowCode projects since a few years ago. In the past, projects similar to CMS or intelligent operation platform can be classified into LowCode. In recent years, I have also participated in and led the implementation and evolution of design projects as the main front-end architect of similar projects. The well-known Flying ice of Ali is also a similar one, and many students’ internal development of middle and background projects is almost a part of it. As I said in my previous articles, to be an architect, besides paying attention to daily business and summarizing the experience methodology of architecture, I think the most fulfilling thing would be to participate in the promotion and popularization of an architectural standard

Make development should know about design patterns, especially in Java, the gang of four classic books written in his early introduction about design patterns, these patterns are very classic, we are now in some programming ideas most of them are used in the software development based on these patterns, or is a variation of these patterns, but design pattern has been for many years, Moreover, the complexity of front-end development and the rich scenes of the project itself are beyond the imagination of software engineers decades ago. As practitioners, we should uphold some simple technical ideals, organize and promote the popularization of better architecture standards, and help the successors to innovate on this basis. Therefore, IN this article, I would like to make some attempts on the architectural design of LowCode related projects in the past, and see if I can summarize some general patterns to help you avoid some repetitive thinking and mining in the architectural design and development process of related projects.

The body of the

Commonalities of LowCode projects

As early as when I was engaged in programming work, the front end had not been independent. At that time, Microsoft mainly promoted a set of WebForm website visual development solution based on ASP.NET. By dragging and dropping some web components and binding data sources, a website with content display and form submission could be completed very quickly. The whole process can be completed with only a small amount of code, similar to the development experience under Windows, so the dragging and dragging you see now is very cool. In fact, these are left over from Microsoft 10 years ago. Of course, sometimes the idea is not good or not, so even with the technical strength of Microsoft, It could not run this model in the network environment at that time, because the technology development in the front-end field was too fast, the WebForm architecture could not keep up with the pace of The Times, and was eventually eliminated

I’m doing front-end career planning – how is front-end architecture harder than coding? Mentioned, front-end architecture technology update speed are the biggest challenges for the architect to maintain existing architecture and design challenges, I believe that the front part of the WebForm also has extremely exquisite architectural design, if you have seen the JS code generated by the he knew from the perspective of professional front though execution is very inefficient, but development is very efficient, At the expense of the site performance under the premise of greatly improved the development efficiency, but killed also did not expect the arrival of V8 to a large extent to solve the problem of poor JS execution efficiency, so as to push the front-end development to JQ Backbone rich client development mode, The balance between the original development efficiency and execution efficiency of WebForm was broken by the development of front-end technology, which led to the decline of this program. In the subsequent MVC, Microsoft even built Backbone and decoupled front-end development from the architecture design of the whole program and handed it to professional developers. No longer provides a drag-and-drop way to generate JS code. So it’s not just Microsoft architects, because The Times are moving too fast to keep up.

Therefore, when considering the design of front-end architecture, front-end architects should try to consider the decoupling of implementation and design, so as to avoid the impact of the replacement of some dependent technologies on the core of the architecture, resulting in the subsequent difficult maintenance of the architecture

So looking back, LowCode has actually evolved over the years, from a language implementation to a language implementation, but the essence of LowCode hasn’t changed much. Basically, all LowCode architecture designs have some common elements. Since LowCode’s specific applications are all about building as many non-code applications as possible, we’ve divided these components around building the target application

  1. An operational client for building the target application description file
  2. Description file used to describe the build target application
  3. Services used to parse description files to build the actual artifacts
  4. Services used to run the actual artifacts

A little bit of LowCode architecture practice

For the sake of writing, let’s try to define some of these four parts

  1. LCClient
  2. LCSchema
  3. LCBuildService
  4. LCRuntime

Now, I’m going to assume that you have no actual development experience in LowCode projects and have never been involved in the architecture of similar projects, but I’m going to tell you that any LowCode project can be architecting through the above four components. Let’s take a look at how to understand these components

LCClient

If you know the B/S C/S architecture, or you’ve used some sort of drag-and-drop visualization platform, or you’ve used the Cli to create projects, then you can understand that these are actually clients, or an AI that understands what you’re talking about and it’s a Client, at most intelligent, As I mentioned earlier, when we’re doing architectural design, especially if we want to develop some architectural design patterns, it’s best to separate implementation from design, so I’m not specifying what Client is and what implementation to use, because I believe that as technology evolves, drag and drop is definitely not the final form. Architectural patterns to be viable have to be decouple from the actual implementation. LCClient you can do it any way you want. Our definition of LCClient is that the end goal is to produce a target application description file

Target application description file LCSchema

What is a target application description file? Maybe something like this

{
    "appName": "LowCodeExample".    "appRunTime": "React".    "appRoot": {
        "name": "SideBar". "child": [{  "name": "SideBarItem". "props": {  "title": "Learning power"  }  }]  } } Copy the code

This is a JSON file, and you can guess from the content that this is used to generate a SideBar. The real situation would be more complicated, but this article is devoted to discussing general architectural patterns, so let’s move on

LCBuildService

The user, or the developer, does something like this with LCClient and then spits out an LCSchema, at this point we have the description file, we need a real artifact, so the task of LCBuildService is to parse the LCSchema and then generate the actual artifact, Such as code

LCRuntime

Why add a LCRuntime if the code LCBuildService generates is actually runnable? The main purpose of adding this service is to make the generated code better decouplable from the actual running environment. LCBuildService can generate some intermediate code independent of the running environment through LCSchema, and then wait for the final parsing in the actual running environment, so as to achieve the purpose of cross-platform and cross-environment. The actual LowCode project architecture design can only implement LCClient LCBuildService LCSchema, and then implement LCRuntime when you need it, as part of a general architectural pattern

By convention, this pattern could be named CSBR

The latter

Students who have not been exposed to similar project development may feel a little abstract, but it doesn’t matter. Let’s take the most common forms as an example to create a series of actual coding, and develop a LowCode platform for developing forms based on CSBR mode.

Above are some of my personal experience conclusion, of course, far from an architectural design can be widely promoted model, compared with the design pattern, the architecture design patterns by the problem domain are much more complex and the vast majority, only rely on some concepts, the boundary of abstract levels are still too high, so deep down again, digging up each component architecture design, So I expect this series to be very long, and today a friend asked for a piece on how ReactHooks are actually used. Maybe I’ll digress into that one again, but I promise not to be too eunuch, so I try to fill out every hole I dig 😀

This article is formatted using MDNICE