foreword
Low-code applications have greatly lowered the barriers to entry for developers, enabling more and wider groups to participate in the software development process. However, most of the applications in the early stage are function extensions built on a specific platform. This model of platform first and then application directly limits the scope of application of low-code platforms, so leading low-code platforms have launched light application models that allow customers to customize exports and independently publish and deploy. After customers complete the basic low-code model and application development, they can quickly export it as a separate application and deploy it in their own intranet or public cloud virtual host according to their needs. This article will explain the low-code service release design from the perspective of low-code service export and release combined with OneCode's DevOps design.
1. Why do enterprises need independent deployment support?
(1) Application of special requirements for gradual process
In enterprise-level applications, low-code is a new thing. It is inevitable to start with some marginal businesses first and gradually move closer to the core business. Most of the companies that have the strength to try new technologies such as low-code engines have relatively complete release and management processes. There are relatively strict process safety specifications for the online operation of each application. If the low-code application still uses the traditional deployment method to go online, it needs to be integrated according to the company's own application release testing process, and complete many technical requirements such as code storage, version management, release scripts, and test scripts. This is obviously contrary to the design concept of low-code itself, and these customizations will also greatly increase the workload of the platform service side and the user side. The easiest way to solve this problem is to provide independent DevOps support, especially for light applications, and provide independent support for running, testing, publishing and deploying environments. It is used as an independent service middleware in the original service of the enterprise.
(2) Data security and application security requirements
A large part of enterprise applications are internal enterprise applications that cannot be externalized. In particular, some financial and government affairs applications even require an independent internal network to support them. In extreme cases, these applications can only be updated through physical media such as CDs. To a certain extent, this provides higher requirements for application deployment, program version, and data version. In particular, some business configurations such as permission setting and approval processes need to be set after real data. It is also necessary to support secondary configuration in the release environment.
2. General outline of project release document structure
Edit toggle to center
Add picture annotations, no more than 140 words (optional)
The release of the project requires three resources to support, namely, the page and function interaction completed by the user through design, and the front-end page directory formed by the conversion of the corresponding technology stack front-end through a specific code-out template. The back-end application is based on the domain model files formed by the user through basic data modeling. These domain model files are usually packaged independently in the form of resource libraries, support domain engineering domains and other models to facilitate later version management and individual updates. In addition, the third block is to facilitate project startup and operation, access control, external exposure monitoring and other related project configuration information.
Three, resource (material) directory tree
(1) User project directory tree:
The user directory tree is established by the user, and it is also the entry point for project editing. The user routes through the directory configuration page. Concatenate related functions. At the same time, some personalized definitions also have this import.
(2) Front-end support library
It is mainly related to the technology stack selected by the developer when exporting code, and is usually used as the basic attribute of the export template configuration. In the basic basic stack, it will cooperate with corresponding debugging and running integration pages to achieve out-of-the-box matching capabilities.
(3) Material library support directory
The material library is the most innovative part of low-code applications, and it is also the most attractive part to developers in componentized and visualized applications.
In addition to the basic import and maintenance functions of the material library, it is also an important part of low-code release management to automatically load, compress and compile according to the developer's second choice when publishing.
(4) External library import
In low-code applications, when it comes to some statistical reports, industrial configuration design, and calculation table applications. Usually, an independent third-party JS code library is introduced, which greatly simplifies the configuration and enhances the integrated design of the application. But each component will have its own packaging rules when publishing and compiling. When designing a packaging and compiling system, independent configuration is required to complete it. It is cited in OneCode, more than 200 independent component libraries supplement the shortage of basic components, and are packaged and adapted according to its basic code packaging rules.
Four, back-end services
(1) Overview of back-end packaging structure
If a low-code application needs to have complete modeling and external application management functions, it will inevitably involve back-end data modeling and basic logic arrangement functions. Different platforms will target different developer groups. The primary database modeling application for the purpose of solving the addition, deletion, modification and query of simple data also has domain modeling applications for professional developers. But no matter what kind of platform, when packaging and compiling output. This is usually done using the following model.
(2) Service model interface description
The service model interface description usually adopts the Rest web service model. Each project will set the corresponding naming control, and then rearrange according to the service address of the specific page to manage and display the webapi structure in a tree structure.
Edit toggle to center
OneCode API model
An interface description usually includes:
URL address: Identifies the address that can be accessed through WEB.
Page binding service object: After obtaining data through the data interface, bind the data to specific components such as front-end containers, lists, tables, and trees.
Back-end receiving binding: When the front-end data changes, the data is synchronized to the back-end data model through ajax or form submission.
The service model interface description is a necessary option in packaged applications. After the package is completed, the application server needs to be notified to complete the relevant service registration and also provide policy service support for application service permissions.
Five, user engineering domain model
In low-code service applications, a large part of the applications are built under independent and complete data models. Relatively mature low-generation platforms allow developers to use domain model tools to build new business models.
(1) Repository resource library
In the domain model, the Repository resource library also becomes the infrastructure layer. When building basic applications on low-code platforms, most of them build object-oriented database table designs from infrastructure layers such as database tables. In the process of application packaging, it is necessary to complete the code output and compilation of the infrastructure layer according to the basic technology stack and template library selected by the user.
(2) Aggregate aggregation application
Aggregate aggregation is a very important part of the domain model, and it is also highly abstract. DNA is very widely used in low-code applications. In low-code, a large number of page actions and data events need to interact with the background to complete. And this interaction process is very complicated and cumbersome. If it is only constructed from the front end and decomposed into individual front-end and back-end interaction calls, it will not only increase the cost of learning and use for no reason, but also make the logic of the front-end page crowded. The aggregation application acts as a bridge better. Use Aggregate Root (" aggregate root" ) to encapsulate business objects into a business model that can be directly operated. Promote the business entity to an "aggregate entity" and directly serve as the carrier of the front-end and back-end data models to complete the data interaction application, while the interaction actions related to the front-end page are directly encapsulated as aggregation menu actions. Completely connect with the front-end API to realize the synchronous call of the front-end API.
This kind of logic application is especially suitable as a logic arrangement tool in the low-code platform. While the developer arranges the relevant logic, the back-end Aggregate aggregation application is created synchronously, and the back-end Repository resource library is associated with the front-end page throughout the front-end page.
When the model is published and managed, it needs to be converted to the local language according to the specific technology stack to complete the relevant front-end and back-end code configuration work synchronously. This is also the most difficult place to grasp in the compilation and release of low-code platforms.
(3) View routing
View routing is the most important presentation method in the presentation layer in the domain model. The biggest feature of the low-code platform is componentization and visualization. Presentation layer modeling is its unique advantage, but what is mentioned here is a more abstract representation. That is, after the user completes view drawing and data model action event configuration, he needs to complete the extraction of the visual model, and use the page and routing-related models to build the presentation layer model "view routing" in the domain model, and at the same time extract data and interaction actions as Repository Resource layer and Aggregate aggregation application layer. Then through the code factory to compile and output as an independent and runnable project code.
Six, general domain model
(1) Overview of the general domain model
(2) User model
In application modeling, user models are mandatory for all applications. In low-code modeling applications, most of them are also completed in the model based on the user's own system, such as the built-in DingTalk organizational model in Yidak, and the enterprise WeChat model used by Wedak. However, in a relatively large-scale enterprise, there will be an adaptive unified organizational model to support it.
In the low-generation receipt design, in addition to obtaining relevant information through the corresponding API, it is also necessary to parameterize its application to better integrate it with low-code applications. In the process of application release, it is also necessary to build related environments according to specific domain models.
(3) Permission model
In business applications, the permission model is the blood and soul of the system, controlling the flow of data to ensure the safe and correct operation of data. With the further improvement of componentization in the low-code platform, fine-grained permission subdivision is required to improve the application experience.
(4) Knowledge database
The knowledge database is a special existence in enterprise applications. Almost all business application systems need to be integrated with it. Common business integration is mostly limited to the retrieval and archiving of written documents. However, in the low-code model, due to its special With the model capability, the data declaration cycle can be planned uniformly from the metadata level, and a knowledge database based on the metadata model can be built from multiple levels of pages, data structures, and metadata itself. Realize the electronic file model management of the full statement cycle.
(5) Portal and news
Among Internet low-code applications, WeChat and DingTalk, the largest enterprises, have gradually expanded from instant messaging to the field of enterprise services. Instant messaging and enterprise portals are portal applications in enterprises, and will play a vital role in the integration of low-code engineering applications.
Seven, support domain model
The supporting domain is the core logic layer of the enterprise core middleware. It is an essential access integration in low-code applications. This requires that when the description of the open interface is obtained through the middle platform, relevant applications can be quickly parameterized, and the low-code platform can be accessed through the aggregation capability. When deploying and packaging, it can be compiled into a specific environment through the code output setting of a specific language. The adaptation code completion should be closely integrated with the user's core support and .
Eight, engineering configuration
(1) Engineering version support
(2) Engineering version support
(3) Engineering configuration support
