Why do we try to split back and forth?

This is not a purely technical article, but a share of my personal in the front and back of the separation on the road harvest points of the article, in order to prepare to try to separate the front and back or want to know the front and rear separation of children's shoes to do a general explanation.

Try and change

If you haven't tried the back-and-forth workflow, consider this process change:

Move the process from
PM: "I want this feature"
Backend: "This first to find the front-end to make a template"
Front end: "Templates are Done"
Back end: "I'll butt it, it's not the right style."
Front end: "I'm done."
Back-end: "Feature delivery"
PM: "Spring Festival to add this activity"
Back-end: "This first to find the front-end to change a template"
Front end: "Templates are Done"
Back end: "I'll butt it, it's not the right style."
Front end: "I'm done."
Back-end: "Feature delivery"

Become
PM: "I want this feature"
Front end: "I Want Interface"
Backend: "Interface Complete"
Front end: "I come to butt, feature delivery"
PM: "Spring Festival to add this activity"
Front end: "Need to add interface"
Backend: "Interface Complete"
Front end: "I come to butt, feature delivery"

Thus, the main concept of front-end separation is: The backend only need to provide API interface, the front-end call Ajax implementation of data rendering.

Current situation and differences

As a front-end developer, we should try some new technology, perfect every detail of the problem, and constantly break through the self. Although the front-end separation is not a novel technology or ideas, but currently many background developers and even front-end developers have not been contacted.

According to my personal understanding, if in a department, department personnel are all background developers, the front-end of some of the pages are done by the background, then the front and back end of the separation for them may be an unknown field, the project is mostly front-end strong coupling, and even there is no front-end concept.

In a company or department that does not attach importance to the front end, it is understandable that there is no understanding of both front and back. When I first entered a department full of background developers, the whole department on my front-end, I just started the main responsibility is to be responsible for the project front-end page production and JS function realization, although the department has a front-end separation of consciousness, but do not know how to practice. At that time, the Department of the back-end staff think back and forth is no longer required to write HTML and JS, can be handed to the front-end to do, however, this can only be called front and rear division.

The above is a situation: do not understand the separation of the front and back, but also do not know how to practice. Here's another scenario: understand the front-end separation, but don't want to try.

For the second situation, many people have also done the corresponding explanation, in fact, this involves "the pros and cons of the separation of the front and back" problem. Many backstage people will think that the set of their own do not have problems, even if the background to apply the front-end HTML is commonplace, has always been the trend, the background MVC framework is so recommended to use, very reasonable. At this time the front-end developers in the Department of the discourse is often not enough, or think that the background developer's opinion is always right, there is no subjectivity.

Conversely, it is possible that background developers are highly recommended for front-end separation, and front-end developers do not want to practice. At this time the front end will think the background developers in the blind toss, before and after the end of the project does not separate to do it is very smooth, separate instead will give themselves to bring additional workload and learning costs, and this depends on the front-end technical capabilities and insight.

Of course, this is what I personally think of the front and back end of the existence of some of the current situation and differences.

Scenarios and Requirements

For both front-and back-end applications, not all scenarios are appropriate, but most projects can be separated by a front-end separation.

Since I am mainly engaged in the front-end development of enterprise-level applications, I personally think that for the development of background applications, the advantages of front-end separation is far greater than the disadvantages.

Most background applications we can be made into a spa application (single page application), while the main feature of the single page application is the local refresh, which is called by the front-end control route Ajax, the backend to provide interface can be implemented, and this way the user experience more friendly, Web page loading faster, development and maintenance costs also reduced a lot , the efficiency is significantly improved.

Similarly, the front-end separation in the display and mobile app pages is also tried. The front and back end does not separate the case, the server to the Web side to do processing, return full HTML, this will inevitably increase the complexity of the service side, maintainability poor, and the web needs to load the full HTML, to a certain extent affect the performance of the Web page, which is very unfriendly to the mobile performance of the King's Place.

With the development of front-end technology and iteration, the front-end MVC framework came into being, using the current mainstream front-end framework, such as react, Vue, angular and so on we can easily build a Web site without server-side rendering can be demonstrated, and this kind of framework provides the front-end routing capabilities, The background can no longer control the routing of the jump, the original front-end business logic is all thrown to the front end, so that the front-end separation can be said to be the most thorough. Here is the code for a front-end control route:

' Use strict 'ExportDefaultfunction(Router) {Router.map ({'/')function (Resolve) {require (['./pc.vue ' : {component: function (resolve) {require (['./pc.vue '  Function (resolve) {require (['./components/process.vue ')          /span>      

Front-end separation of the implementation of technical personnel, especially the front-end personnel requirements will rise to a level, the front-end work is not just to cut the page to write templates or to deal with some simple JS logic, the front-end needs to deal with the various data formats returned by the server, but also need to master a series of data processing logic, MVC ideas and

Advantages and significance

For the meaning of front-end separation, we can also be seen as the meaning of frontend rendering, I mainly summarize the following four points:

1. Complete liberation of the front end

The front end no longer needs to provide templates to the background or background code embedded in the front-end HTML, such as:

<!--server-side rendering--><select>    <option value= ">--Please select your business--</option> in    p_list% }    <option value= "{{p}}" >{{p}}</option>    {% endfor%}</select>  

This is a back-and-forth coupling with poor readability.

<!--front-end rendering--><template> <select id= "Rander" > <option value= ">--Please select your business--</option> <option V-For= "list in lists": value= "List" v-text= "list" ></option> </select></template><script>Export default {data: { return {lists: [' Option one ', ' option two ', ' option three ', ' option Four '}}, ready: Fu Nction () { this. $http ({url: '/demo/', Method: ' POST ',}). Then (function (response) {
                  
                   this.lists = response.data.lists 
                   // Get server-side data and render })}}</script>   
                   

Above is the front-end rendering of a piece of code, the front end through the Ajax call back-end interface, data logic on the front-end, maintained by the front.

2. Improve work efficiency, more clear division of labor

Front-end separation of the workflow can make the front-end only focus on the front-end, the background only care about the background of the work, both development can be carried out at the same time, in the background has not been available when the interface, the front end can write the data to die or call the local JSON file, the increase of the page and the modification of the Development is more flexible.

3. Local Performance improvement

Through the configuration of the front-end routing, we can implement the page load on demand, without having to load the first page to load all the resources of the site, the server no longer need to parse the front-end pages, the page interaction and user experience to improve.

4. Reduce Maintenance costs

Through the current mainstream of the front-end MVC framework, we can very quickly locate and find the problem, the client's problems no longer require background personnel to participate in and debug, code refactoring and maintainability enhancements.

Experiences and experiences

Along the way, the project one after another, from the beginning of the background control routing, background rendering page to the current front-end control routing, front-end rendering data, workflow and methods have undergone great changes. Whenever I encounter the following situation, I will feel the advantages of the separation of the front and back end:

• When the project started to make front page, I no longer need to configure the server environment in the background

• The front-end file of the project can be dropped into the server when it needs to call the backend interface, so it doesn't need to be put in advance.

• Add a project page need to configure the route when no longer need to let the background colleagues to add to my front end

• The front-end file is no longer doped with code logic in the background, it looks much more comfortable.

• Page jumps are smoother than before, local rendering is fast

• Page templates can be reused, front-end component development improves development efficiency

Wait a minute. Faced with the rapid development of the front-end, we should adapt to the way it brings about the work and process changes, the current front-end separation of work is bound to be the trend of the future, as a front-end developers, we should assume this universal front-end new knowledge and change the status of responsibility.

Only try to know suitable, only experience to identify who is who is not, this article is not respected must be separated before and after the end, but hope that everyone in the appropriate application scenario down to try to separate the front and back, in the rich experience may also be rubbed out sparks.

Original articles, reproduced please note from a radish a pit-blog Park [Http://www.cnblogs.com/luozhihao]

This address: http://www.cnblogs.com/luozhihao/p/5761515.html

This article was posted synchronously at: 1190000006240370

Why do we try to split back and forth?