focus

If there is one thing that distinguishes low-code platforms from the usual technical development frameworks, it is their focus on code and configuration.

• The code is preferred
• Configure the priority

Obviously, the low code platform is configuration first, and the configuration presentation capability needs to be strong if the presentation capability is not lost.

So, when we choose the technology, we should always keep in mind that this is different from the technical framework we usually use to write code, the whole thing is not to write code to be comfortable, but to build a set of people with different technical abilities can reasonably cooperate mechanism.

Again, the Excel analogy: some people tend to combine existing formulas; Some people ignore these things and write their own code to implement what they want. The former is the main object we want to serve.

type

Type system is a very interesting thing, which can be used to express the combination and transformation of structures, so as to preliminarily verify the security of transformation.

A type system based on metadata

In a low code platform, a type system that enables the structure and relational expression of business entities and provides a degree of convenience for extending rules is a useful tool and may be a core part of the underlying methodology of an overall model-driven low code platform.

Often, we take advantage of the ability to express atomic and compound types in a programming language. The most common type description architecture on the Web front end is TypeScript, but it’s important to note that TypeScript validates things that are determined at compile time, whereas on low-code platforms there are a lot of things that are undefined at compile time and validated at run time.

For example, a user creates a “school” model and dynamically adds fields to it.

This whole process is done entirely at run time, and if we want to add type validation to it, we need to approach it from a different Angle.

A domain-model-driven, low-code platform that naturally owns entity metadata and can rely on it to be passed to every corner of the runtime, effectively establishing a schema-based typing mechanism. Being able to express this type mechanism explicitly would benefit both platform and low-code developers.

Low code platform runtime, are actually quite so conventional software development process development period, so, we need to provide type support at this level, and because the entire implementation spans, runs through the full process from the server to multiple clients, at least one link through the serialization and deserialization process, so, This validation process needs to be able to simultaneously ensure that the data is valid.

Thus, the responsibility of this type system is to run through the life cycle of the data.

Type of operation

A validation mechanism can be extended from the existing type structure. For example, if we know how a type’s Schema is described, we can generate validation functions to verify the validity of the corresponding data.

It is even possible to generate detailed information about compound types on the fly because of the combination and transformation of types, and use this as a basis for validation of more complex data structures.

It is important to note that composition and transformation are not in TypeScript anymore. They are the capabilities that the platform needs to implement, even if the platform itself is not developed in TypeScript.

Code prompt

Similarly, based on the existing type structure, you can provide some additional programming convenience in extending actions and methods. The type structure between different languages is transformable to a certain extent, and the type structure we build based on the description can be easily mapped to mainstream programming languages.

storage

Storage is a key component of overall system availability.

From a programming framework perspective, several different dimensions of abstraction have emerged for structured data storage:

• Database-oriented connection: JDBC
• Entity oriented: ORM

The former mainly focuses on shielding the differences between different databases, generally supported by a specific programming language or framework agreed programming methods, such as the Java system in the base class, abstract class, implementation class and so on a set of mechanisms.

The way this approach is exposed is low-level, has a lot of control, and does not use requirements that cannot be achieved in this way, but in most cases the level of abstraction is too low on a low-code platform.

Generalized ORM is a more moderate abstraction layer, it first provides an entity perspective, can be oriented to the physical layer model in the domain model to organize data access.

Secondly, the underlying storage is not necessarily the structured storage within the system, but can map a virtual entity based on the read and write API provided by the external system. Then, the virtual entity can be associated or combined as a real entity.

So from this point of view, we can design a set of distributed ORM to abstract the entire generalized storage layer. Entity definitions in ORM serve as metadata descriptions throughout the entire system, which can be combined with the type system throughout the entire system.

logic

Low-code platforms are the most difficult to “go code-free,” or the only thing that can’t be configured completely is business logic, and many times it’s not impossible, it’s not appropriate.

For example, we often design larger-grained logic as flows and orchestrate them as sequences or state machine flowcharts, but it is difficult to orchestrate finer-grained logic this way because it is too cost-effective and increases the cost of understanding.

However, we need to realize that logic can also be classified. For example, in terms of trigger mode, it can be divided into:

• Take the initiative to
• passive

Active logic can often be organized into services that are used by some active callers, or triggered by timers, life cycles. Passive logic, which typically performs interception, validation, and other functions, can generally be classified as rules.

view

In a typical application system, the view layer is the least abstract and the most time consuming in the development process.

From the most basic point of view, whether there is a view layer or not, providing a refined or crude view layer, doesn’t really matter much about the nature of the general business.

Basis of

The basic components of the view layer include the following:

• Atomization interaction
• Layout and Layout
• State management
• Data request

In addition to the atomic interaction, is a kind of objects that can be locked out, other parts have a common characteristic: you need to use to the entity structure, and this kind of entity structure, is one of the metadata description to the backend storage part, if we can make these three pieces of content to reuse the metadata as far as possible, may be possible to reduce the extra amount of code written.

From this perspective, we can reorganize our front-end component architecture and typical state structure scenarios around metadata structures to interpret metadata and generate different forms of interactive systems.

From this point of view, look at the previous several questions in reverse:

The least controversial are data requests, which can be expressed as requests based on metadata descriptions, described in detail in the next section.

Layout and choreography

There are usually several schools of thought:

• JSX, less constraints, high manual readability, high parsing difficulty
• A template language with many constraints, intermediate human readability and low parsing difficulty
• JSON, many constraints, low manual readability, low parsing difficulty

It is important to note that in low-code platforms additional visual framing tools are often included, so:

• JSX is not the most suitable tool for hosting view choreography, mainly because of the difficulty of parsing and its programming-friendly nature, which is a minor factor on low-code platforms
• Templates have moderate human and machine processing power and can be used either as an underlying storage structure for visual editing or by hand
• JSON is relatively easy to support visual editing, but it can be difficult if a skilled worker wants to write it by hand

So the dominant choice here is some kind of template syntax, and whether that template is based on tags or on structural expressions like Markdown is secondary and not very important, and the two are basically equivalent.

State management

The need for state management can be supported by a typical state structure built in, plus extensible control logic. In this place, we can take a look at the controversial Redux in the past two years, what is its essence?

The essence of Redux is to treat itself as a kind of data holder and to provide an iterator pattern so that the outer layer can provide a mapper to handle every change to the data. Usually when we write code, this pattern is more complex, with many constraints and format code, but in another way, it is a good way to carry the configuration of code operations.

Constraints are bad for programming, and generally good for configuration. This state structure can be modeled on by providing some built-in actions and then providing additional action extension capabilities so that state and logic can be easily extended.

Across the

Another issue that views need to address is cross-ends. If you realize that, in our architecture, you don’t need to look for the same cross-side representation for every component, but rather for semantic equivalence, you can design atomic interactions for each side individually, and then solve the problem with the same choreography layer.

The only thing to consider is how the engine layer communicates or integrates with the view layer at each end. It is possible to try to transfer the logic engine to Worker at the PC Web end. The interaction layer uses the communication protocol similar to local RPC to transmit data with the engine, and the other ends use similar methods. In this way, the interaction at each end is localized, but the logic engine shares the same set.

interface

Note that we are talking about interfaces so far down the line, because interfaces are not really worth paying too much attention to in the context of cross-system integration semantics, because they are internal system behavior.

From a view point, it calls a wrapped RPC service because of the capabilities provided by the platform, and how it is transmitted internally is not very important.

However, it is important to take into account that our previous considerations have configured the view as a whole. In the view layer, we reuse “choreography” and make it run through “state structure” and “read and write”. Therefore, the interface layer must be able to flexibly call various flexible structures corresponding to the view layer, for example:

• Partial
• Array<Partial>

And more complicated combinations of them. Currently, the most mature solution for responding to this request structure is GraphQL, which provides two capabilities that fit our needs:

• Atomized read-write interface that flattens hierarchical requests into entity dimensions
• Ability to tailor the read/write structure of a single atomized interface

So GraphQL is a good choice here, and it also makes it easier to implement more complex and powerful capabilities, because the graph structure of the underlying entity relationships is highlighted, and you can do some choreography definitions like permissions at this level.

From this perspective, we can also see that in the whole system, the front end is the true ORM consumer, and the data life cycle runs all the way to the client, so there are some interesting thinking involved, which I have discussed in some detail in my previous articles.

On the other hand, multiple sets of API exits can be provided to the interface layer to accommodate different cross-system integration approaches.

summary

As an overview, this article only briefly mentions some of the major aspects of technology selection in the process of low-code platform development. The details are so extensive that there is enough room for dozens of articles.

The general principle, or to combinability, configuration as the highest starting point, on this basis, the first to build a workable technical framework, and then do the upper product packaging.

The original link: zhuanlan.zhihu.com/p/182211043