Author | Zheng Jiatao (Qunqing) source | Erda public account

Without exception, when it comes to front and back end separation, it’s “definitely” a RESTful API. But we know that REST is always designed to divide resources differently from UI, and that a lot of dedicated, specific, and quirky interfaces are like a never-ending collection of fungi that you can wipe out, only to be recovered in a thunderstorm. On the other hand, interfaces are becoming more and more common, and only CRUD is left. The back-end only cares about stability and performance, but a lot of business logic is left to the front end. It makes people wonder whether this is really a separation of the front and back ends.

As a one-stop cloud native PaaS platform for enterprises, Erda also has a large number of interfaces oriented to use interaction: from personal background to deployment overview to project setup; From cluster management to monitor the market to member management. We started with REST, but it changed over time. This article will start with how we built and improved Erda’s front and back separation framework from the real problem. Since there are so many things involved in the framework, I plan to cover them in detail in a series of articles. This paper mainly introduces the reasons for its emergence and design ideas, and more related details will be developed in the following articles, including but not limited to:

  • Framework implementation details
  • How do tests unfold after using the framework?
  • Stability and engineering management
  • · · · · · ·

Briefly introduce the main structure of this article:

  • Plain thinking
  • Interactive vs Business
  • Return to the classic
  • Components and Protocols

The first three sections mainly describe the background and solution analysis of our framework, while the “Components and Protocols” section explains the core design concept of the framework. If you are in a hurry, it is recommended to go straight to the components and Protocols section.

Plain thinking

The dilemma that all software companies face is the division of labor. Old-school developers would believe in the ability to go it alone on the full stack, but as software becomes more complex, division of labor is inevitable, most notably at the front and back ends.

The front-end resources of Erda have always been in short supply. In the most exaggerated cases, the ratio of the front end to the front end can reach 1:8. In most cases, the bottleneck of the project lies in the front end. Our naive view is that changing this situation requires more work on the back end to free up manpower on the front end.

Interactive vs Business

The so-called division of labor at the front and back ends is fundamentally the division of interaction and business.

The following is the most common scenario, with the front end focusing on vision, experience, etc., and the back end focusing on CRUD, security, stability, etc. While business processes, permissions, and so on are scattered between the front end and the back end, it is difficult to say whether a specific business logic is implemented at the front end or at the back end.

As can be foreseen from the above description, such a division can lead to some problems:

  • Repetitive work: As a result, the system development will result in negligence in some places (for example, the front-end implementation of authentication, but the back-end authentication logic is not well verified).
  • Large area of front and rear ends: communication costs are often borne by students at the front end, which is one of the reasons for the shortage of resources at the front end.

Think about how often you’ve seen the back end write an interface and then walk away, leaving the front end to guess what the interface’s parameters mean. Bugs, including those later tested, are “always” thought to be front-end problems.

There are many solutions to the above problems, such as NodeJS:

As shown in the figure above, the LOGIC for business processes, permissions, and so on is included in the JS implementation. This leaves virtually all of the logic in the front end and the back end hollowed out, leaving only the familiar CRUD.

This approach is efficient to some extent, but also in line with the front end of the “unified” trend of thought, but for the front end of the current situation of insufficient resources, this move is undoubtedly worse.

At the same time, there are radicals who will adopt a low-code platform “once and for all,” requiring no front-end development at all. Platform-based configurations and a small amount of back-end process code seem to present a possible future:

However, most of the existing low-code platforms are still in the development stage, and getting rid of the front end entirely would result in a rather rigid and fixed UI presentation, simply not “cool” enough. This is why most low – code platforms currently support mid – and back-end systems.

We also see the industry going retro, such as Hey.com (www.hey.com/how-it-work…) :

By “retro,” I mean that the page logic is heavily rendered on the back end and only a little simple code (CSS, JS) on the front end to implement the interactive details. Just like the old PHP and JSP development models, basically all the business logic was implemented on the back end. You can say that this practice is a kind of “rebellion” against the current situation where front-end frameworks are getting bigger and nodeJS are prevalent.

But it’s nice to see that even with the so-called “outdated” development model, there are still “cool” products with a contemporary aesthetic and a great interactive experience.

The saving grace of full stack

The hey.com development model can also be considered full-stack in a way.

There is a great temptation to develop the front end and the back end by one person. This also means:

  • Communication costs at the front and back ends are significantly reduced, even though both sides need to know the details of the business.
  • Interface debugging costs are significantly reduced, even if the interface design has been fully reviewed.
  • In the longer term, the cost of feature changes and iterations tends to decrease.

However, the full stack requirements are so high that it is difficult for individuals to master both the front and back ends. But the idea that one person is responsible for everything is very desirable.

Return to the classic

The foundation of the Web is HTTP. The target of an HTTP request is a resource. All the pages we visit are resources, and the links to the pages are resource locators (URIs). As shown below, the process looks like this:

  1. The browser makes the request, and when the request is processed, the server transfers the data to the browser to render the interface (this data is usually HTML, a language that describes the rendering).
  2. Take a form as an example. When you operate on the interface rendered as a form, a new resource request (HTTP) is initiated according to the protocol and browser implementation.
  3. This request requires the server to make resource changes, and when successful, the data is returned to the browser to render the modified interface.

<form action="/users/1">
  <label>Name:</label>
  <input type="text" name="name" value="Bob">
  <input type="submit" value="Submit">
</form>
Copy the code

The traditional Web has a minimum of browser-defined interaction elements such as pop-ups, confirmation, scroll, and submit is the end of interaction. However, with the development of Web and JS, there are more possibilities for interaction, while HTML5 and CSS3 also provide a larger foundation for interaction.

Now, our most intuitive feeling is that the website is more and more “cool”, but also more and more “heavy”. From a developer’s point of view, front-end JS projects are packaged even more slowly than back-end projects.

Is it possible for all of our technologies to go back to the classic Web, back to resource-oriented operations, back to the last century of rethinking interaction? We can then extend the interactive elements of the browser without using the JS framework to implement complex interactions; Extend HTTP requests to make them more suitable for browser rendering and interaction.

For example, we are about to develop a job board, if the browser already provides a general kanban interactive elements, whether we can use the form as the form, only need to use this interactive elements “configuration” on business information again, can under the condition of without using additional js, complete the functions?

Based on the above, we come to the following idea:

  1. A common component library (to augment browser interaction elements) is settled, and the number of this component libraries is fixed, which we call “common components.”
  2. After populating business data with common components, business functions can be configured to present, such as login forms, project creation forms, etc. When a common component is compounded with business attributes, we call it a “business component,” and the number of business components expands as the business grows.
  3. There needs to be a protocol to respond to the interaction and reach the interaction flow of the above form, but this protocol needs to be powerful enough to support not only the interaction flow of all components of the component library, but also the complex scenario of multi-component linkage. This protocol runs on top of HTTP, but unlike RESTful, where REST only focuses on data and is stateless, we envisage a protocol that needs to be aware of the interface presentation and support the full flow of interactions.

As the figure above shows, with component libraries and protocols, more than half of the front-end work can be carried, while some of the overlap between the back end and the front end is reduced, and the front end retains its own flexibility.

Components and Protocols

To sum up, to implement the three ideas we have reached, we need to achieve three levels of things:

  • Rich library of common components
  • Component rendering capability to render business components into generic components
  • Protocol rendering capability to handle complex interactions

We designed a render frame with two parts (the green part above) :

  • Business component Renderer: The core is to handle the transformation of business data to common components and the handling of common component operations.
  • Scenario Protocol Renderer: The core is to organize a bunch of components into a scene (think of it as a page, as shown in the page structure on the right of the figure above) and data binding between the components in the scene. It is responsible for making decisions when there is an interaction resulting in an operation and re-rendering the operation after it has taken effect.

The common component library, in the middle of the figure above, is defined and maintained by the front end, which focuses on enriching the common component library and maximizing the interaction and UI of each component (as we’ll see later, this is the front end renderer).

This is designed to reduce the amount of front-end work, especially the front and rear end connections, which can even be considered “reversed” on two levels: the interface definition is reversed and the development timing changes.

Inversion of the interface definition

In the definition of the interface, the traditional from the back – end led to the front – end led.

The traditional (or now mainstream) back-end implementation is RESTful apis, while the front end directly connects to these scattered apis and understands the meaning of the structures within the interface. But in the context of componentization, the so-called “front and back docking” is broken down into two parts: rendering and rendering.

The rendering framework (back-end) mentioned above implements business to common component rendering, the front-end definition maintains the common component library, and implements the common component “renderer”, which renders the common component data into a visual form.

In between rendering and rendering is the standardized Component Data structure. We can think of the common Component as the interface that dominates the definition of the front end, and the back end goes from throwing away a RESTful API to being “forced” to understand the Data structure of the common Component to implement the business logic. The whole situation is reversed.

Interestingly, since the number of common components is fixed, we can port common component development to different rendering media, and even develop a RENDERer for the CLI interface, without modifying the back-end code.

Changes in development timing

By the traditional back-end development after the completion of the front end of the development, to complete the development first for the front end of the back end of the coordination and coordination.

The “renderer” allows the front end to focus only on the development of common components, and the business logic can be completely relegated to the back end. This division of responsibilities frees the front end from its dependence on the back end and allows it to design, develop, and debug independently (with only the mock component data). Components are highly reusable, and the front end can even become a designer, skipping the hi-fi design and delivering directly to the real thing, at a time when the back end may still be struggling with table structure design.

What’s more important is not just the shortening of development time on the front end.

We can compare this to the RESTful API form of front and back separation, where the same “interface” standardizes the connection to achieve decoupling. REST interfaces are obviously going to swell with business, and the real advantage of a generic component is to strip the business completely, making it relatively constant and small in number. As we all know, simple is better. It has been proven that the fewer components you have, the better the quality of each component, and the functionality done on the front end with these high-quality components, you can almost assume that the debugging work is done on the back end.

More and more

  • Can business components really isolate business? What about interaction?
  • Can protocol rendering really replace REST? Do I have to choose between two?
  • …

In the next article, we’ll look at the running logic of component rendering and protocol rendering in more detail, and how we managed to make the front end completely business-unconcerned.

Welcome to open source

Erda is an open source, one-stop cloud-native PaaS platform with platform level capabilities such as DevOps, micro-service observation governance, multi-cloud management, and fast data governance. Click on the link below to participate in open source, discuss and communicate with many developers, and build an open source community. You are welcome to pay attention, contribute code and Star!

  • Erda Githubhttps://github.com/erda-project/erda
  • Erda Cloudhttps://www.erda.cloud/