Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about what is code-free programming, many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Large-scale organizations often face the challenge that the infrastructure of each application is the same, part of the code is the same, and even they may just be different data models. As a result, he / they have to rewrite an application again and again.

For a new application, it needs to dock a large number of three-party (non-team) services. The constant changes between services lead to the need for changes in the corresponding users. The ever-changing business has led to constant changes in the design of the front desk. In order to deal with the foreground service of rapid conversation, the middle station was born in the background to provide rapid response ability. With the further precipitation of the middle station, it tends to be stable in some form, while the front desk still needs the ability to respond quickly.

As a result, as a front-end developer, we constantly refine and reuse the code, and we also create a series of CLI, toolsets, programmer plug-ins and design systems to complete the rapid development of the entire system. However, we still lack a set of effective tools to manage these tools uniformly.

In other words, we need a front-end console, which is codeless / low-code programming.

What is codeless programming?

No code / low code is a way to create applications that allow developers to use minimal coding knowledge to develop applications quickly. It can assemble and configure applications in a graphical interface using visual modeling. Developers can skip all the infrastructure directly and focus only on using code to implement business logic.

Of course, from the developer's point of view, reducing the amount of code may be:

The framework itself deals with complexity. After all, "complexity does not disappear like a force, nor does it arise out of thin air. It is always transferred from one object to another or from one form to another."

Code generation reduces the workload. A lot of copying and pasting takes more time.

Process flow

With this concept alone, we cannot understand programming without code. So I drew a diagram to show the corresponding architecture and process:

From my point of view, I divided codeless programming into two parts:

Editor for building UI-- an online drag-and-drop UI design and page building tool

Flow editor for writing business logic-writing business code through flow programming (mostly data processing)

UI programmer. To design our UI builder, we need to prepare a series of infrastructure:

UI programmer. For drag-and-drop design UI.

Blank scaffolding. A project with a full application life cycle, but it's a blank project-- for us to add components and code anytime, anywhere in the process of building UI.

Design the system. We need a complete component library, a large number of page templates, and a certain number of template applications to reduce the corresponding amount of development tools.

Code snippet set. It further instantiates the component library in the design system into a code segment, and dynamically edits the code through CLI after editing.

DSL (domain specific language, optional). Intermediate products that are used to isolate the framework from the design.

Stream programmer. Then, in order to

Stream programmer. Used for drag-and-drop, input to write business code.

Back-end service. If you cannot provide off-the-shelf back-end services, you need to have a standard API specification and a corresponding mock server.

Pattern library. Contains the corresponding business processing code, such as general login, data acquisition, UI interaction and so on.

DSL (domain specific language, optional). Same as above

Of course, we also need to be able to preview the built applications in real time. We then performed the build and then built a semi-finished application. Developers only need to develop applications on the basis of it. In the process of developer development, we can design a series of tools to help developers build applications more quickly.

Editor plug-in. It contains the auto-completion code of the design system, pattern base, etc., as well as the code base commonly used within the organization.

Debugging tools. For mixed-type applications, we also need a development tool to build applications quickly.

Judging from the above process, codeless programming also has the following characteristics:

Drag-and-drop interface. Or a visual model-based on nodes and arrows

Vision-based design.

Scalable design. Such as a series of support for plug-ins, plug-in stores, communities and so on.

Cross-platform function. Support PC Web application development, support mobile application architecture, etc.

After a strong deployment. That is, the platform contains the whole life cycle of the application.

Has rich integration support. You can feel free to find the required components and the corresponding background services.

Configuration. It also means a lot of custom configuration.

Homemade domain-specific language (optional). For build-time optimization.

Advantages and disadvantages

Accordingly, it has the following characteristics:

Efficient. Needless to say, save time and development costs.

Limited Bug, security.

Low cost. The budget required is very limited.

Easy to use (depending on design).

The development speed is faster.

AI in the development process.

Low maintenance cost.

The corresponding shortcomings are:

Programming skills are still required.

Limited customization capabilities.

Scalability has become a new problem.

Integration is limited.

At present, low-code development platforms are usually divided into two main categories:

For the outside: make simple products, such as web mobile applications

For internal: create business applications for your team or business

Simple services such as using only CRUD, forms, validation, simple aggregation, paging, and so on. The most common example is form construction, where applications such as gold data can be generated directly by dragging elements, and the corresponding open source implementation is jQuery Form Builder. For developers, we just need to define the data model and drag and drop to determine the location of the elements. From this point of view, low-code development patterns can be used directly as long as applications and services built with Serverless can be used.

Development process comparison

From our understanding, the development process of traditional applications is:

Analyze, design, identify, and plan requirements

Design system architecture

Build the front and back end projects. Select a technology stack, build from scratch, or create from scaffolding.

Build continuous integration.

Create wireframe and high-fidelity prototypes.

Design the data model and define the front and back end contracts, namely API URI, methods, fields, and so on.

The front and back end implements the business logic.

The front end implements the UI page.

Integrate third-party back-end services.

Functional requirements testing (DEV, QA, ST, UAT)

Cross-functional requirements testing (security, performance, etc.)

Deploy to a production environment.

On the other hand, low code development process:

Analyze, design, identify, and plan requirements

Select the desired third-party API

Draw the workflow, data model, and user interface of the application in the visual IDE.

Connection API-- usually uses services and function discovery.

Write business logic (optional). Add manual code to the front end or customize automatically generated SQL queries.

User acceptance test.

Deploy to a production environment.

From a step-by-step point of view, codeless programming is missing a few steps. These steps are made very simple because of a large number of rich internal system integration.

Applicable scenario

Currently, codeless programming is actually a highly preset mode of the scene. Therefore, it has certain applicable scenarios:

Model-driven development.

Rapid UI build.

Minimalist business functions. The use of such tools also means that we are concerned about interactions and

IT resources are limited. In the case of limited resources, it is most important to be able to quickly develop applications that meet business requirements.

From a process point of view, for some applications, we cannot implement code-free programming-there are some business differences. Therefore, in most scenarios, only low-code programming is implemented.

If you want real codeless programming, you need some more specific scenarios:

Design form (input data)

Create a report (organize data)

General scheduling and automation processes (manipulating data)

More scenes are being explored.

The Challenge of programming without Code

Programming without code, in addition to preparing the above series of infrastructure, will inevitably encounter a series of challenges.

Who will write this part of the code?

Infrastructure preparation for the client.

The service platform of the server side is built.

Unified user experience design. Design a series of components that can be easily combined, and the corresponding template pages. At the same time, they can also adapt to different styles, that is, they are supported by a variety of themes.

DevOps pipeline design. Low-code programming relies on a series of automation tools to build, debug, deploy, and maintain, as well as testing applications.

Domain language design.

Automated testing. If our front-end code is automatically generated, do we still need to test it? This is a good question, and if the code is automatically generated, then the tests should also be generated automatically. After all, we have to write a large number of automated tests on the platform to ensure the quality of the platform.

Some of them are a little more complicated, and we can probably explore them.

Who will write this part of the code?

When we create such a platform and tool, the first question we need to consider is, who is our tool written for?

People who have no programming experience. Such as business people, he / they have a wealth of experience in business systems. It also means that we

A person who has programming knowledge but no experience.

A developer with some experience.

Experienced developers. For professionals, automation means a lack of flexibility. He or they spend more time fixing the generated code than they do writing it themselves.

Obviously, for a fairly experienced developer, this tool is not necessarily what he or they need.

Client infrastructure

As far as I understand it, it is suitable for rapid MVP builds, and the generated code should be easy to modify, rather than tools such as early DreamWeaver or FrontPage.

At the same time, due to the different level of developers, we need to do different tools:

Support for cloud building and debugging.

GUI programming application.

Code generation.

Design system construction. Build component library, create template application, etc.

...

What is more difficult is that it is easy for developers to accept code generation.

Server side

For a low-code platform, its corresponding backend should be:

A large amount of available land for existing services. Authentication, security, push capabilities, maps, etc.

Quickly build back-end services. If there is an internal Serverless or FaaS solution, it can be said to be better.

Facilitate integration with third-party services.

Flexibility. Support for multiple languages, etc.

For a unified back-end service API, we need a common paradigm for back-end services. All API should be designed according to this paradigm. However, as a consumer of API, we may not have so much power, but we can adopt the decorator mode, that is, encapsulating a third-party API into a unified way. To this end, we still adopt the following approach:

The contract. Such as Swagger UI, it can directly create a simple and available service.

BFF . That is, we go one by one to encapsulate these third-party applications according to our needs.

Query language. Compared with writing BFF yourself, a simpler way is to use a back-end query language such as GraphQL, which is more convenient and more flexible.

In the design period before development, we need to design the corresponding domain model first.

Domain language design

A low-code environment uses a (graphical) modeling language to specify the behavior of the entire system and product. It means:

Apply data structures and domain patterns to all levels of the program.

Integrate business rules and decisions into the application (hierarchy).

This means that we need to design a model language. For us, it is actually a domain specific language (DSL). The following is a simple example of DSL that describes the components used:

{'style':', 'id': 2,' blocks': [{'content': {' content': 'content',' title': 'hello'},' type': 'card'}]}

In addition to this, we also need to design the corresponding layout DSL, such as:

H: [circle1 (circle1.height)] / / set aspect-ratio for circle1HV: [circle2.. 5 (circle1)] / / use same width/height for other circlesH: | [circle1]-[circle2]-[circle3]-[circle4]-[circle5] | V: | ~ [circle1..5] ~ | / / center all circles vertically

Finally, we also need to convert the stream code into the real project code. The combination of the three types of DSL is not an easy tool.

Prototype design

Write the existing components, general interface. Such as the common login interface. For businesses that use the login interface, they only care about three parts:

Successfully logged in.

Cancel login.

Login failed. For the client, it can be considered a cancellation of login. For the server, it may be the wrong password, the user name does not exist, the account is locked and so on.

Corresponding to the above scenario, there are some general logical processing:

Login succeeded. Save the Token and return to the history page.

Login failed. A prompt box for custom content pops up.

The code is similar.

Front-end prototype

In some simple front-end applications:

Template. Just use these templates, set the appropriate properties for these templates, and bind the corresponding values.

data. The process is just on the way of saving the values of variables and CRUD these variables. To do this, we need a pipeline architecture design for data processing to handle these values.

Function. In fact, all of our functions are just administrative functions that are only used to deal with the corresponding logic.

These common functions can be made into components, and for some applications, the code repeats accordingly.

Load the page infinitely. You just need to bind API and control the display and hiding of the elements.

Form. The field is defined as the type, and the corresponding foreground and background logic is available. In addition, we also need to customize common rules for them, such as regular expressions. Once there is a linkage between forms, then the design of this component is even more troublesome.

Card elements.

Forms and tables are displayed.

Common charts. In fact, there are already a series of charting tools, and we just re-encapsulate them on the basis of them-so that they can be in the form of a domain language.

Advanced responsive layout. Unlike the independent development layout of each application, the low-code platform needs to provide a powerful custom, responsive layout design-that is, to meet the common pattern of the mobile side and the common pattern of the desktop version. For example, for a large amount of data, the desktop side uses Pagination and the mobile side uses infinite scrolling.

Backend prototype

In fact, for the back end, a low-cost platform means code generation and service generation. The service itself is limited, and since some changes have taken place in the business, the back-end service may not change.

It also means:

Micro-service. Each back-end service should be as small as possible.

API normalization. That is, it adopts a unified API format and accepts a unified authority management.

A lot of API services.

Quickly integrate third-party service solutions. The integration of third-party services is inevitable in the development of applications. In order to deal with this problem, we need to prepare the corresponding creation service logic, pass in the parameters required by the third-party service, and then we can directly generate our forwarding service.

So, the question is, in that case, can we provide a custom tool? So that everyone can create their own component flow?

The answer is obviously yes.

Proof of concept

So, in my recently designed PoC (proof of concept), I used the Anguar framework. The corresponding basic ideas are as follows:

Use Material Design as the component library and CDK's Drag to achieve the drag-and-drop function. Each dragged component, called element (element), is generated by the ElementDispatcher from the data. The draggable part consists of two parts: layout + elements.

After the UI is built, the corresponding DSL is generated. Currently, JSON is used. After all, data structures are the simplest domain-specific languages.

Use Angular Schematics to parse this part of the DSL to generate the corresponding project code.

After reading the above, do you have any further understanding of what is codeless programming? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.