Rethinking the development architecture of web systems-complete separation of front and rear end

The original: The Web System Development Framework rethinking-the complete separation of the front and rear end

Objective

Full separation of the front and back in fact, has always been a web developer's dream, has always been my dream, thinking back that year, whether it is directly in the code output HTML, or embedded in the HTML code, can not be satisfied. During the pain and tangled, I think all web developers are deeply impressed.

Since the last few years have been on the MS Platform, from the Web form to the Mvc,ms platform although easy to learn, but the integration is too high and inflexible, has not found a good front-end separation of ideas. (Java Platform Brothers if there are very mature platform and ideas, it is best to leave a word to a post address or technical name, greatly appreciated).

Asp. NET MVC pattern is really a big step forward to the front-end separation, but I think the current model is still not thorough, I have seen some of the park's articles, we all think this is the controller layer problem, but I think it is the problem of the view layer, The output of the view layer still needs to pass through the controller channel, that is, the controller still affects the "page rendering" the final effect, so that the current MVC can only be servlet, JSP, Web form upgrade mode, Separation from the real front and back is still a certain distance.

However, the current owin standards and Ms of the self-revolution, so that I began to rethink the core issues of front-end separation, combined with the previous web development problems and experience, I hope to communicate with you in this area of thinking and experience.

Prerequisites and Necessity

From now on, the development of web development technology and the increasing demand of web system make the condition of separation of front and rear station become more and more mature, and the necessity is increasing. I summarize it in 3 words to summarize:

front-end omnipotent, channel is increasingly convenient, demand is becoming clearer.

The development of the HTML/CSS standard makes the front-end performance more abundant

In recent years, the Web front-end technology competition, HTML5/CSS3 is clearly still the leader, their standards continue to evolve to the front-end to bring more possibilities, between these two technologies are any mode of the required, here is not added to the statement.

The continuous development of JS framework makes the front-end development infinitely possible

Through continuous development and countless master efforts, "JS can achieve any function" is not a joke, even the "Atwood law" this slightly frivolous speech has been more and more people accept.

Today, there are jquery, Dojo, an easy-to-use base function library, with ANGULARJS and backbone as the glittering framework. On the shoulder of JS, front-end development has virtually limitless possibilities.

The development of RESTful APIs and JSON makes the front-end interaction increasingly convenient

Of course, there is the problem of communication after the separation, how fast, concise, effective, unified in front of the background of information interaction, become a problem that must be considered after separation.

Fortunately, the advent of restful thinking and JSON data standards makes this interaction increasingly convenient, and in the front-end, our familiar JS technology and framework support for restful and JSON can be said to be the case. As for the backend, no matter what language, what platform has a very mature program.

The different development trend of front and back end makes the demand for separation of front and rear end increasingly obvious

As we all know, since the advent of web development has been in the performance, performance and experience of congenital defects, but to this day, the fact is not so, some appear even more than desktop programs and the application of the Web site turned out, customers are also hanging foot appetite. Web Development Desktop is an unstoppable trend, and the need for front-end development should be more focused on interface performance, speed, user experience and the direction of development, and the requirements will only become higher.

In the backend, stability, performance, security, storage, business and other core issues are still mainstream, so the demand for the front and rear end will increasingly split, pay attention to performance and focus on the internal front and back developers will need to fit their stage.

Four principles

So I think the future of web development, the complete separation of the front and back should be a worthy consideration of the direction, my idea is relatively simple and clear (may be relatively simple, I hope that everyone more treatise), see:

To achieve this separation, I think there are four principles:

Front-end Static

The front end has only static content, and then it's clear, only html/css/js. The content comes from a completely static resource without the need for any background technology for dynamic assembly. The runtime environment and engine of the front-end content is entirely based on the browser itself.

Back-end data

The backend can be implemented in any language, technology, and platform, but they must follow one principle: to provide only data , not to provide any content related to the interface performance. In other words, the data they provide can be used for any other client (such as localization programs, mobile programs).

Platform agnostic

The front-end 3 technology itself is platform-independent, the essence of the latter part of the connection is to achieve the appropriate restful interface and interactive JSON data, for these 2, any technology and platform can be achieved.

Architecture separation

The front-end architecture is entirely based on the development of HTML/CSS and the evolution of the JS framework, completely unrelated to our familiar background language (e.g. C #, Java, Nodejs, etc.). As the front desk is purely static content, large architectures can be considered to the CDN direction.

Back-end architectures can be almost based on any language and platform of any solution, large-scale architecture, RESTful API can consider load balancing, and data, business implementation, etc. can consider database optimization and distribution, these domains in the park, such as the cloud, the swim no longer.

But in a word, the separation of the front and back ends also realizes the separation of the front and rear end architectures.

Advantages of the separation mode

Significant reduction in front and back traffic

We know that the front and back end of the traffic is HTML/JS/IMG resources, and the data is only a small head, the resources accounted for more than 100K of the page is not big, but the data at best about 10K, such as a 10,000 records of data compression is only around 100K, and a slightly larger JS library or pictures more than these .

The decrease in traffic lies in the "front-end static" rule, where the static resource is cached by the browser after the first fetch, and even if the browser continues polling, the server returns a very small not-modified response, and the traffic is almost negligible.

For example, on a page with a page of 100K and data of 10K, 100 requests of traffic are 100k+10x100 = 1.1M. It is obvious that the traffic is significantly lower than the case of getting full HTML each time.

Performance improvement

Some people also questioned the page performance of this model, in fact, the situation is not so pessimistic: the first time there will be some loss, but I think, the loss is negligible, an HTML page loading, loading more than 10 dozens of K JS, image is very common, 1-2 more 10K JSON is not a heavy burden.

But the subsequent use of this page, the performance advantage is fully reflected, the majority of the content of the page is the local cache directly loaded, remote access is only 1-2 10K of content, its load time hundred milliseconds, this and local page few differences, its front-end loading and response speed has been greatly improved is obvious.

Front-end platform agnostic and technology agnostic

Front-end is pure HTML technology, front-end personnel only need Notepad can develop not a "joke", the latter can achieve restful frameworks and platforms abound, can choose more suitable for the team, people and the company's technical path is not tangled in the choice of platform and technology.

Centralized optimization of security

After the front-end static, the front-end page attack is not possible, some injection attacks in the separation mode is well circumvented; The security of the backend is centralized, and only the security considerations of a Reseful interface are addressed, and security and centralized optimization become clearer and more convenient.

Separation of development and separation of architectures

Maybe a lot of team or 1 developers all-inclusive front-end mode, but I also mentioned that the front-end requirements are more and more high, the needs of the front and rear end of the division is increasingly obvious, once the system superiors do not grade, its separation needs will appear.

The complete separation of the front and rear personnel allows them to further seek expertise in their respective fields, become more professional master; In addition, the front and back of the architecture can be considered and set up separately, the frontend framework can focus on performance and optimization, and business, security and storage problems can be centralized to the back-end considerations.

Discussion on common problem solving

Here I have read several masters in the Park article:

Forest of the summer-thoughts on the evolution of large-scale website Technology (14)--site static processing-front and back separation

System architecture: A new trend in Web application architecture---the idea of separating front-end and back-end

A simple, crude front-end separation scheme for the double.lv

Thinking and practice of separating front and back of Tsunetane (i.)

Can be said to be beneficial, and for them to ask some questions, but also try to find a solution under their own ideas:

page logic and rendering effect : Or just a word, JS has omnipotent, relying on the current various JS function library and framework, in obtaining reasonable data, almost no do not come out of the logic and effect. I am biased towards the front-end, friends who have doubts about this, we can communicate in depth. As for some friends of the data validation, page white screen, routing control, code reuse and so on, the front-end technology has been completely resolved.

server performance and optimization : Because the front-end content is completely static content, the browser uses the local cache for most of the time after the initial acquisition, that is, the server's stress comes mainly from the RESTful API calls that host the data, The sharp reduction of pressure is self-evident. Coupled with the reasonable design of the interactive data, it can be said that the client-server interaction control has been close to the limit.

Security : Because the front-end static content can only be obtained, the backend can only accept JSON, it should be said, shielding a large number of possible injection-type problems, and some other issues, such as illegal objects, data encryption, DDoS and other issues, which are in itself is the responsibility of the back-end personnel can not evade, Must be considered in any mode.

cross-platform, Cross-technology : As we have just said, front-end technology itself has no platform limitations, and the backend can be implemented on almost any platform.

Enterprise-Class architecture Considerations : Front-end considerations for building a CDN, backend considerations for load Balancing, database optimization and distributed design. The key problem is that the front and back end architectures can be considered separately and assigned to their professionals.

Test : Front-end JS has a very good unit Test framework (AngularJS), and the backend restful testing technology has been very familiar.

seo: It is really a problem, but with Owin or other HTTP module bridging technology, transferring part of the HTTP route to SEO functionality is not difficult.

Development Technology: front-end personnel only need to learn html/css/js, and the latter only need to learn back-end language. Almost no need to be interspersed.

Ajax cross-domain: If a remote call or a small number of internal calls, you can consider back-end transfer and JSONP, internal architecture separation can consider cors.

Rethinking the development architecture of web systems-complete separation of front and rear end