I. Product introduction

Why is it called ma Ji? Because we all raise chickens in the cluster!

Form lists written every day, no improvement and no technical output? Component library ecology has long been mature, smashed the re-creation?

Majji is a solution based on VUE framework to build middle and background pages. It has been applied in Yunyun for more than one year, receiving nearly 200 pages with a comprehensive improvement efficiency of 70%.

Advantages of sesame chicken:

  • Quick up – Drag and drop component configuration, responsive preview

  • Fast development – skilled operation of a page in 10 minutes, perfect development and test process, no need to build rapid online requirements

  • Fast iteration – Iteration requires faster response to secondary development, small iteration Java packages are built and released

  • Access fast – saas platform, all old pages can access

  • Supporting full – built-in front-end full set of services: buried point, monitoring, permissions, gray everything

  • Me (making: remove relating to the business process, code, and components, starts to enter 127.0.0.1:8080 / generate/lego/edit/form test page editor)

  • Demo address: Click on me

Product demonstration

​

Application effect

​

Ii. Product Background:

With the development of business, business needs rapid expansion in 2019, in particular, more and more in the background system, 50 + a backend system, in the background system needs to take up front team 70% of the workload, occupied personnel proportion is as high as 60%, the background of system requirements, how to quickly response is the business side, product manager, project manager’s attention.

The requirement complexity of middle and background system is low, at least 90% of the pages can be standardized, and a large number of personnel are invested in repetitive work, so that the growth space is narrow and the actual ability of developers can not be brought into play.

Product status

Since the project was established in 2019.4, due to the product positioning, repeated trial and error until it was put into production in 2019.10, enabling students with front-end, back-end and product testing with certain programming foundation. Adaptive form page, list page, detail page three types of page, including 38 functional components, so far in the cloud set internal application of maji configuration online nearly 200 pages.

Product positioning

  • Enabling -> Developed by the core team, can be used by the company including front-end, back-end, testing and other research and development personnel, through simple graphical configuration and a small amount of code, not only directly achieve business requirements, but also provide permissions, environment, gray, buried point, monitoring and other capabilities.

  • Optimization process -> Set development, debugging, testing, release the whole link integration low code development platform, without limiting the project, access to the old project is simple and fast

The early design of Maji was used by the product, UED and back-end roles, and the front-end resources were released from the background system. The configuration of components was designed from an operational perspective. Midway more do more wrong way, sesame chicken became a tool to shift the workload, and can not do the real effect.

After the review, we clearly positioned Maji as mainly serving the front-end and back-end students, and gradually introduced code development and template statements in the subsequent component design, so that the expansibility of configuration pages increased directly.

Iii. Maji architecture design

1. Architecture design

​

2. Workflow

​

The front-end technology changes with each passing day, and we have no time for reconstruction due to the iteration of requirements. Iframe has become the most direct way to integrate projects across the technology stack, and JSP, VUe1, Vue and React can be easily and quickly accessed.

3. Component ecology

​

4. Data protocol design

The design of component data only has two core fields type (component type) and ID (component ID). The other attributes can be classified as business attributes, which belong to the business configuration fields inside the component. The rendering engine does not need to care about them, but only properly renders the component and fills the data.

In VUEX, the design is floorList (main page floor ID) and idModule (component configuration data).

Manage component data in a discrete manner, categorize component nesting relationships as business configurations, and allow more freedom of operation within components

​

Rendering components only need to be rendered into target components using self-matching configuration data within the component via the moduleId.

​

5. Code injection function design

Code injection enhances the freedom of the component ecosystem by executing events based on the component lifecycle or event insertion, Currently support componentCreate (component creation), componentWillDestroy (component destruction before), beforeSend (interface request before construction), afterSend (interface request completion), valueChange (form data change) five scenarios have met the daily Development and use, subsequent expansion is also very convenient.

​

  • To keep the authoring experience of writing code in the Web editor consistent with that in the IDE, the VSCode MonacoEditor plug-in is used. The custom function stored in JSON is a string format, which requires regular processing to remove the header and tail from the function before it can be used. Bind keeps this pointing to the vue instance of the current component.

Iv. Pain points and solutions

1. Redundant repeated requests

Multiple Select components configure external data sources requested by the same interface, and page initialization executes multiple duplicate interfaces simultaneously

Solution:

To achieve global repetitive interface merging without changing the interaction and configuration data structure of the original component, it is easy to think of implementing it in a unified encapsulation HTTP approach

​

​

2. Configure historical data baggage

Every time we look back at code from a few months ago, do we get a new idea? A better idea, or a change in product requirements, requires a redesign of the original plan. Historical baggage is a central issue for configured pages.

Solution:

Page initialization when JSON is stored in VUEX, a historyDataUpdate method will be implemented for all components when data is stored, and synchronization operation will be performed for the old data of components that are needed. Internal compatibility processing of components will be reduced, and only data dimension operation will be updated

Five, the Q&A

Q1: Why not generate code?

A1: The form of generated code is intrusive to the old project structure. The iterative requirements of the middle and background system are more than the requirements of new pages. The form of generated code is not convenient for secondary configuration

Q2: What’s the difference between react and VUE? **

A2: The construction system development cost is high, the volume of others is large, and the demand of the same type has such a large magnitude, so it is reasonable to have a quantity of input-output ratio. Most of the construction systems used in enterprise development can clearly limit the boundary. The framework system, normative vision, normative interface, and normative interaction can greatly reduce the configuration complexity, otherwise the gain is outweighed by the loss.

Six, summarized

Low Code and No Code are among the most popular front-end projects in the past two years. We have gone through many detours in the process of polishing. It is concluded that there are two core issues in developing this type of project:

Who is the user? What business scenarios are met?

We don’t transfer complexity, shift work, but how to starting point for the team assigned to the core, in specific business scenarios, set up system to maximize the value of the software industry ecology is various, in order to do general commercialization, inevitably increase the complexity of the configuration, but when the requirements are domain specific limits, complexity is greatly reduced, We can limit change through specifications.