Web-front-end separation development deployment Pattern __web

web-front-end separation development deployment Pattern

Before we begin to discuss this topic, let's start with the traditional development model.

First, the traditional development model

I believe that many of the web development children's shoes should experience such a development model, using the back-end language provided by the template engine to write html/xml pages, such as:

PHP has a smarty template engine; Java Web projects have JSP pages; Python web frameworks have their own template engines; Nodejs Express you know

All have a common feature, the server-side background language generated after the resolution of the Html/xml format returned to the client, such as browser-side access directly return to parse the good HTML, the browser directly explain the implementation.

Second, the Ajax transition

Ajax is the push to separate the front and back ends of the deployment, when the Web page local update is the beginning of the future separation of the front and back. So what is the separation between the front and the end of the development?

In short, front-end development does not need to deploy background language that heap of garbage environment, back-end development does not need to write any of the front-end program, the background to expose a variety of API interface to provide front-end data additions and deletions to check, not responsible for generating HTML pages

The front end requests to the data and then dynamically claims the DOM node.

third, front-end construction

In contrast to the background, front-end construction is the focus, because the front and rear side of the separation and development after the focus on the front-end, the back end is a data provider, access control API.

Back-end projects usually bring their own server, in addition to PHP, so back-end do PHP development also need a webserver,apache is the classic tie, has recently been abandoned for Nginx, so the background environment is a pseudo production environment.

Front-End projects or to build a server, and then throw the project inside to run to debug development, the most stupid direct whole Apache or nginx can also, but this development is still very painful. You can take advantage of the node toolset and have a lot of node toolset, such as the browsersync I like to use very much.

Iv. resolution of requests

After the front and rear separation, we only need the server side to tell us the API URL, then this will create a problem: Ajax Cross-domain. It's not possible to use generic cross-domain solutions, such as Jsonp,iframe Messenger, and so on, because we have post requests.

So the HTTP proxy class tool is useful, for example, I will be in Browsersync to join the middleware to judge each request, if the/API prefix will be proxy to the API server, the API server to receive data and then return to Browsersync, Browsersync back to the browser end. This resolves the problem of Cross-domain requests.

The production environment has two kinds of deployment, one is put in the backstage project, this has nothing to say, the other is the front and back end of the deployment, then in the front-end webserver processing end-point forwarding rules are good, such as Nginx,apache support.

v. Static resource path issues

If your project has the ability to upload resources, it will naturally generate user resources, then after the end of the separation, how to deal with this problem. We have to look at the pattern first.

Resources and background items together, the background processing after the need to return to the foreground a relative path, if the resources of a separate server, it needs to return the absolute URL of the resource.

vi. conversation

The biggest headache for Web projects is that stateless causes session problems, traditional Web projects use Session/cookie, but in the back-and-forth side separation, the cluster deployment mode is obviously too flawed. Token mode is already the mainstream of the current web-end solution session, and there are henduo open source and Easy-to-use token build management program, basically can be used.

last

The weakness of the front and rear separation is nothing more than two points:

1, the front-end load increased, such as the request to the list, the front-end needs to traverse the data set claimed that the DOM node (most of the current user's computer configuration is not bad, and the browser kernel is not covered with the defective IE browser)

2, not conducive to spiders (in fact, some of the spiders are already very powerful, can support H5 C3 effect).

Strengths

1, the web end is like the mobile phone side of the app, do not need cookie/session, and server completely separate, easy to maintain, expand. A server API can serve multiple Web apps at will

2, Angularjs after use, you should feel the future of the Web development model, ANGULARJS in almost the front and back of the separation of the pilot

3, the front-end static resources and background API streaming, do not affect each other, even do not exist IO problem

4, development and backstage almost synchronized, not affect each other, especially based on RESTful API style, but also reduce the cost of communication

5, to facilitate the respective Debug,java developers do not need to run to the front-end developer machine to see the error of Tomcat console, front-end developers do not need to run to the back-end developer's machine to see the error debugging Browser