The difference between the front end and the rear end route route talk

Today interview, the interviewer asked me a question front-end and back-end routing route, I only answer to the point, the interviewer asked me to go find out

In fact, I had the line in his blog on the following issues encountered

    Why I write Vue application no problem, after deployment in addition to the server can not access / page in the development stage it

    Routing mode with hash why I wrote SPA page no problem, it is highly problematic to change history pattern it

    What is the front-end routing is what the back-end routing, how to support the back end with the front end of my route it

What is routing

Web Routing understand this article speaks particularly good.

In the Web development process, often encounter the concept of “routing” of. So, in the end what is the route? In simple terms, routing is the URL to the mapping function.

URL access will be mapped to the corresponding function in (this function is generalized, may also be a function of the front-end back-end function), then the corresponding function is determined by the return to the URL something. Routing is doing a job matching.

Start from the back-end routing

In the early web development “slash and burn” era, it has been a back-end routing dominate. Whether php, or jsp, asp, users can access to the page URL, mostly back to the browser through the back end after routing match. Classic face questions, “You input from the browser address bar to see the web page you go through the process of what” is actually talking about is the truth.

In the web back-end, no matter what language is the back-end framework, there will be a special opened up routing module or routing areas, to match the URL given by the user, as well as some form submission, address ajax request. Usually not encountered matching route, the backend will return a 404 status code. This is why we often say that the origin of the 404 NOT FOUND.

URL and Methods

If you are concerned about RESTful API, it will be very familiar to initiate the following four types of requests: GET, POST, PUT, DELETE.

Which correspond to the four basic operations: GET used to obtain resources, POST for new resources (can also be used to update the resource), PUT for updating resources, DELETE to delete the resource. – from Ruan Yifeng “Understanding RESTful architecture.”

Although the above is a RESTful API, but in fact we enter a URL in the address bar and press Enter when the GET request is sent out. It also reflects, URL address and the request method should also be one to one. An example is given below:

1'/user/:id', addUser)

If my back-end routing configuration, only this one route. So I accessed through a browser: http: // words are unable to access, and also returns a 404. Because the back-end with only a method of routing a post. To accept this request, you must have the following route:


router.get ( '/ user /: id', getUser) // get routing configuration ( '/ user /: id', addUser)

Routing and back-end server-side rendering

Said earlier, “slash and burn” era, pages are typically straight out to the client browser through the back-end routing. Html page that is generally good template rendering engine and then to the front end of the back-end server inside through. As for other effects, it is written in advance through pages of a common front-end framework jQuery, Bootstrap, etc. to take charge of.

If you say that some sites have a page via ajax to achieve, such as gmail, such as qq mailbox. Then you have to note that even these pages, which pages “keel” and it is not all by ajax to achieve, they are still back-end straight out – which is what we are now commonplace server rendering.

The benefits of server-side rendering many, such as SEO-friendly for some of the high security requirements of pages using server-side rendering is more insurance. But at the time no node.js of years, in order to build good front page, are multiplexed to achieve dynamic web page structure of the organization, component by corresponding server-side language template engine. For example Laravel the blade, with a Django jinja2, and the like used in the Struts jsp. In fact now, a backend language you want to be able to realize their web features, requires its own corresponding template engine.

After the birth of node.js, the front end has its own back-end rendering template engine has become a reality. Common example pug, ejs, nunjucks and so on. These templates engine with Express, Koa back-end frameworks are beginning rage.

However, in this process, with the development of web applications become increasingly complex, the simple server-side rendering problems began slowly exposed – the coupling is too strong, the era of bad maintenance jQuery page, black and white page switching serious and so on. Although the problem by coupling good code structure, norms to solve, but the page jQuery era of bad maintenance it is obvious, global variables everywhere, the code too invasive. Ongoing maintenance usually patched to the previous code. The black and white issue, although the page switching can be solved by ajax, or iframe, etc., but in the realization of trouble – further increasing the difficulty maintainable.

So, we began to enter the era of front-end route.

The transition to the front end of the route

The front end of the route – as the name implies, URL rules page jump match is controlled by the front end. The front-end routing is mainly displayed in two ways:

    The front end of the route, the advantage of high compatibility with the hash. The disadvantage is that URL does not look good with a #

    Without distal hash routing, the advantage is that without the # URL, nice. The disadvantage is that you need to support both back-end servers also need support

Front-end routing applications, the most widely used example of this is today’s SPA web projects. Whether Vue, React Angular page or engineering, are inseparable from the corresponding sets of router tool. The most obvious benefit is to bring the front end of the route, the URL address bar to jump not black and white – which also benefited from the benefits of front-end rendering brings.

Front-end and front-end rendering routing

Speaking front-end routing can not say front-end rendering. Vue project as an example to me. If you are with a project webpack template built with official vue-cli, have you ever thought of your browser to get the html is what? Long as you have a page button has a form like it? I do not think so. In production mode, you look out of the building look like index.html:


<html lang="en">
<meta charset="UTF-8">
<div id="app">div>
<script type="text/javascript" src="">script>
<script type="text/javascript" src="yyyy.yyy.js">script>
<script type="text/javascript" src="zzzz.zzz.js">script>

The above is usually long like this. You can see, this is actually your browser to get from the server html. There is only one empty div

the entrance as well as supporting the following series js file. So you can see the page is actually rendered by those js. This is why we often say that the front-end rendering.

Front-end rendering the rendering tasks to the browser, to solve numerical force the client to build pages, to a large extent eased the pressure on the service side. And with the front-end routing, seamless page switching experience nature is user-friendly. But the downside is to bring SEO unfriendly, after all, the search engine crawlers can only climb as above html, version of the browser will have a corresponding requirement.

To be clear, and then press Enter as long as the browser address bar enter the URL, that will go to the back-end server requests once. And if it is in the page by clicking the button and other operations, the use of api router library to the URL of the update is not going to back-end server requests.

Hash mode

hash pattern will not use the browser on the back of the # path to the server to initiate route requests. That is, enter the following two addresses in the browser: http: // localhost / # / user / 1 and http: // localhost / server-side are going to actually request http: // localhost this page.

The front of the router behind the library by capturing the # parameter address to tell the front library (such as Vue) to render the corresponding page. In this way, whether we jump through api router in the browser address bar, or pages, all the same navigation logic. Therefore, this model does not require back-end configuration other logic, as long as the return to the front end of http: // localhost corresponding html, the rest of which specific page, you can judge by the front-end route to go.

History mode

# Routing without number, that is, URL form we usually see. To achieve this history router library api this function is generally provided by HTML5. For example history.pushState () can be a URL to the browser address bar push, but this URL will not initiate a request to the backend! By this feature, you can easily achieve beautiful URL. But note that this api and the following version for IE9 browser is not supported, IE10 began to support, so the browser version is required. vue-router will detect the browser version, when history can not be enabled when the mode is automatically downgraded to hash mode.

Above that, you jump pages, usually carried out by a jump to the router api, api calls the router is usually history.pushState () this api, so nothing to do with the back-end. But once you enter an address from the browser address bar, such as http: // localhost / user / 1, this URL will initiate a get request to the backend. If there is no back-end routing table configure the appropriate route, then it will naturally return to a 404 up! This is the reason a lot of friends in the mode of production of 404 pages encountered.

So many people will ask, why I have no problem in development mode it? That is because the express vue-cli help you start the development server to help you do these things are configured in development mode. Theoretically in development mode would have been required to configure the server, only vue-cli will help you configured, so you do not have to manually configured.

So how to configure it? In fact, in production mode is also very simple configuration, a configuration example is given with reference vue-router. A principle that, in the end, back-end configuration of a rule all routing rules, the case if the front does not match the other routing rules on the implementation of this rule – to build good that index.html returned to the front end. This would solve the problem of back-end routing thrown 404, because as long as you enter the http: // localhost / user / 1 this address, because the rear end of the other routes do not match, then the index will be returned to the browser .html.

After the browser to get this html, router library began to work, began to acquire URL information in the address bar, and then tell the front-end library (such as Vue) to render the corresponding page. At this point just like hash of the pattern is similar.

Of course, since the rear end can not throw an error 404 page, URL rules to the front-end 404 is naturally routed to decide. You can decide for themselves what URL does not match what’s in the front end of the route in the 404 page should be displayed.

Front-end routing and server-side rendering

Although there are many benefits of front-end rendering, but SEO problems, it is quite prominent. So react, vue, etc. Later in the frame are rendered on the server doing their own efforts. Based on the server front-end library as before rendering server-based rendering backend language are different. Server front-end frame rendering mostly still used front-end routing, and the introduction of a unified state, vnode and so the concept of their services on the server side rendering performance requirements and other language than php template engine based rendering for a string of filling performance requirements of servers is much higher. So in this regard it is not only the framework itself constantly improved algorithm to optimize the performance of the server must also be improved. The Nuggets had replaced SSR, they also met with corresponding performance problems, it is the reason.

Of course, in between, there have been a concept of pre-rendered. That is to build part of a static html file on the server, straight out of the browser used. Then the rest of the page and then be achieved by conventional front-end rendering. Usually we can put home with pre-rendered mode. The benefits are obvious, taking into account the performance requirements of SEO and servers. But it can not do the whole station SEO, time-consuming production of the construction phase will be increased, and this is regrettable lies.

On pre-rendered, consider using prerender-spa-plugin webapck this plug-in, version 3.x start using it to build a puppeteer html files.

Separate front and rear ends

Thanks to front-end routing and complete front and rear ends of the front frame of the modern rendering capabilities, with page rendering, tissue, something related components, back-end can finally no longer involved.

Separate front and rear ends gradually began to spread development model. The front page began to pay more attention to the development of engineering, automation, and more focused on the back end api to provide protection and databases. On the code level also further reduce the degree of coupling, a clearer division of labor. We also had to get rid of the “slash and burn” web development era. Sahua ~

to sum up

We hope this article allows you to route the front and rear ends and front and rear side rendering understand. In the actual development process, we should not focus only on areas where their relevant fields have been covered, so as to face the problem with ease.

Front-end exchange group: 928 029 210

Leave a Reply