Why should the front and back ends be written separately?

As we all know, companies usually require us to write the front-end and back-end separately. Why do we do this? This time I will tell you why the front and back ends should be written separately. The following is a practical case. Let’s take a look at it together.

If you have not tried the workflow of front-end and back-end separation, you can first imagine such a process change:
Change the process from
PM: "I want this function"
Backend: "Let's make a template from the frontend first"
Frontend: "The template is finished"
Backend: "Let me connect it, the style here is wrong"
Frontend: "I've finished changing it"
Backend: "Function Delivery"
PM: "This activity will be added during the Spring Festival"
Backend: "First find the frontend to change the template"
Frontend: "The template is finished"
After End: "Let me connect, the style here is wrong"
Front end: "I have changed it"
Back end: "Function delivery"

becomes

PM: "I I want this function"
Front end: "I want an interface"
Back end: "The interface is completed"
Front end: "Let me connect it and deliver the function"
PM: "This activity will be added during the Spring Festival ”
Front-end: “Need to add an interface”
Back-end: “The interface is completed”
Front-end: “Let me connect it and deliver the function”

It can be seen from this that the front-end and back-end are separated. The main concept is: the backend only needs to provide an API interface, and the frontend calls AJAX to implement data presentation.

Current situation and differences

As a front-end developer, we should try some novel technologies, improve every detail issue, and constantly break through ourselves. Although the separation of front-end and back-end is not a new technology or idea, many back-end developers and even front-end developers have not been exposed to it.

According to my personal understanding, if in a department, all department personnel are back-end developers, and some front-end pages are also completed by back-end personnel, then the separation of front-end and back-end may be unknown to them. In the field, most projects are strongly coupled with front-end and back-end, and the concept of front-end does not even exist.

In companies or departments that do not pay attention to the front-end, it is understandable that they do not understand the separation of the front-end and the front-end. Most entrepreneurial companies have one or two front-end departments in one department, and one person is responsible for several projects. It is rare for them to collaborate to complete a project. Because there is no standard at all (the standard here refers to the code organization structure), the front-end staff cuts the pictures, writes the pages and throws them to the back-end, and the back-end code structure is used as the standard. Although some companies have the awareness of front-end and back-end separation, they don't know how to practice it. At that time, the back-end staff of the department believed that the separation of front-end and back-end meant that the back-end no longer needed to write HTML and JS and could leave it to the front-end. However, this could only be called front-end and back-end division of labor.

The above describes a situation: I don’t understand the separation of front-end and back-end, and I don’t know how to practice it. There is another situation below: you understand the separation of front-end and back-end, but don’t want to try it.

Regarding the second situation, many people have made corresponding explanations. In fact, this involves the issue of "the pros and cons of front-end and back-end separation". Many backend staff will think that there is no problem with what they have done. Even if it is common for the backend to apply front-end html, it has always been the general trend. The backend MVC framework is also recommended in this way, which is very reasonable. At this time, front-end developers often do not have enough say in the department, or they think that the opinions of back-end developers are always right and have no subjectivity.

On the contrary, it is also possible that back-end developers strongly recommend front-end and back-end separation, but front-end developers do not want to practice it. At this time, the front-end will think that the back-end developers are messing around. In the past, projects without separation of the front-end and back-end would have gone smoothly. However, if the front-end and back-end were separated, it would bring extra workload and learning costs to themselves, which depends on the technical capabilities and Seen it.

Of course, this is also where I personally think there are some current situations and differences in the separation of front-end and back-end.

Scenarios and Requirements

Not all scenarios are suitable for application scenarios where front-end and back-end are separated, but most projects can be realized through front-end and back-end separation.

Since I am mainly engaged in front-end development of enterprise-level back-end applications, I personally believe that for the development of back-end applications, the advantages of front-end and back-end separation far outweigh the disadvantages.

We can make most backend applications into SPA applications (single-page applications), and the main feature of single-page applications is partial refresh. This can be achieved by calling AJAX through front-end control routing and providing interfaces in the backend. Moreover, this method has a more user-friendly experience, web pages load faster, development and maintenance costs are also reduced a lot, and efficiency is significantly improved.

Similarly, the separation of front-end and back-end in display websites and mobile APP pages is also tried. When the front and back ends are not separated, the server must process the web side separately and return complete HTML. This will inevitably increase the complexity of the server and have poor maintainability. The web side needs to load complete HTML, which affects the performance of the web page to a certain extent. This is very unfriendly for a place where mobile performance is king.

With the development and iteration of front-end technology, the front-end MVC framework came into being. Using the current mainstream front-end frameworks, such as React, Vue, Angular, etc., we can easily build a website that can be displayed without server-side rendering. At the same time, this type of framework provides front-end routing function. The backend can no longer control routing jumps, and all the business logic that originally belongs to the front-end is thrown to the front-end. This can be said to be the most complete separation of the front-end and the back-end. The following is a piece of code for front-end control routing:

'use strict'export default function (router) {
    router.map({        '/': {            component: function (resolve) {                require(['./PC.vue'], resolve)
            }
        },        '/m/:params': {            component: function (resolve) {                require(['./Mobile.vue'], resolve)
            }
        },        '/p': {            component: function (resolve) {                require(['./PC.vue'], resolve)
            },            subRoutes: {                '/process/:username': {                    component: function (resolve) {                        require(['./components/Process.vue'], resolve)
                    }
                }
            }
        }
    })
}

The implementation of front-end and back-end separation will raise the requirements for technical personnel, especially front-end personnel. The front-end work is not just about cutting pages and writing templates or processing some simple tasks. js logic, the front end needs to process various data formats returned by the server, and also needs to master a series of data processing logic, MVC ideas and various mainstream frameworks.

Advantages and Significance

We can also regard the meaning of front-end and back-end separation as the meaning of front-end rendering. I mainly summarized the following four points:

Complete liberation of the front-end
The front-end no longer needs to provide templates to the back-end or the back-end embeds the back-end code in the front-end html, such as:

<!--服务器端渲染 --><select>
    <option value=&#39;&#39;>--请选择所属业务--</option>
    {% for p in p_list %}    <option value="{{ p }}">{{ p }}</option>
    {% endfor %}</select>

This is coupled between the front and back ends and has poor readability.

<!--前端渲染 --><template>
    <select id="rander">
        <option value=&#39;&#39;>--请选择所属业务--</option>
        <option v-for="list in lists" :value="list" v-text="list"></option>
    </select></template><script>export default {    data: {        return {            lists: [&#39;选项一&#39;, &#39;选项二&#39;, &#39;选项三&#39;, &#39;选项四&#39;]
        }
    }，
    ready: function () {        this.$http({            url: &#39;/demo/&#39;,            method: &#39;POST&#39;,
        })
        .then(function (response) {            this.lists = response.data.lists // 获取服务器端数据并渲染
        })
    }
}
</script>

The above is a piece of code rendered by the front end. The front end calls the backend interface through AJAX. The data logic is placed on the front end and maintained by the front end.

Improve work efficiency and make the division of labor clearer
The workflow of separation of front-end and back-end can make the front-end only focus on the front-end, and the back-end only care about the back-end activities. The development of the two can be carried out at the same time, and there is no time in the back-end When providing an interface, the front-end can write the data first or call a local json file. The addition of pages and the modification of routes do not have to trouble the backend, making development more flexible.

Partial performance improvement
Through the configuration of front-end routing, we can realize on-demand loading of pages. There is no need to load all the resources of the website as soon as the homepage is loaded. The server no longer needs to parse the front-end page. Page interaction and user experience have been improved.

Reduce maintenance costs
Through the current mainstream front-end MVC framework, we can locate and discover the problem very quickly. Client-side problems no longer require the participation and debugging of back-end personnel. Code refactoring and maintainability enhancement.

Configure ServerEnvironment2. The front-end files of the project can be thrown into the server when you need to call the backend interface. There is no need to put them in beforehand.
3. Adding a project page requires configuring routing. I no longer need to ask my back-end colleagues to add them for me, I can handle the front-end myself
4. The front-end files are no longer mixed with back-end code logic, and it looks much more comfortable
5. Page jumps are smoother than before It is smooth, partial rendering and partial loading are very fast
6. Page templates can be reused, front-end component development improves development efficiency

How to implement mvvm-style tabs in Angularjs? Case + code

Vue2.0 project very practical code collection

The above is the detailed content of Why should the front and back ends be written separately?. For more information, please follow other related articles on the PHP Chinese website!