The complete separation of front and back ends has always been the dream of web developers, and it has always been my dream. Imagine that in the past, whether it was outputting HTML directly in code or embedding various codes in HTML, it was not satisfactory. Painful and tangled, I think all web developers are deeply touched.
Since I have been working on the MS platform in recent years, from Web Form to MVC, although the MS platform is easy to use and easy to learn, the integration is too high and the flexibility is not enough. I have not found a good idea of separation of the front and back ends. (Already have a very mature platform and ideas, it is best to simply leave a message to a post address or technical name, appreciate it).
The MVC model of ASP.NET is indeed a big step forward and backward separation, but I think the current model is still not thorough. I have read some articles in the park, everyone thinks this is a problem of the Controller layer, but I I think it is still a problem of the View layer. The output of the View layer still needs to go through the Controller channel, which means that the Controller still affects the final effect of "page rendering", so that the current MVC can only be the upgrade mode of Servlet, JSP, Web Form. There is still a certain distance from the actual front and rear separation.
However, the emergence of the OWIN standard and the self-revolution of MS have led me to rethink the core issues of front-end and back-end separation. Combining the problems and experiences encountered in previous web development, I hope to share ideas and experience in this regard with you. .
Prerequisites and necessity
From the current point of view, the increasing development of Web development technology and the increasing demand for Web systems have made the conditions for front-office separation increasingly mature, and the necessity has increased. I summarize it in 3 sentences:
The front end is omnipotent, the channels are becoming more convenient, and the needs are becoming more and more clear.
The development of HTML / CSS standards makes the front-end performance increasingly rich
In the competition of web front-end technologies in recent years, HTML5 / CSS3 is clearly still the leader.The continuous development of their standards has also brought more possibilities to the front-end implementation.Between these two technologies are mandatory for any mode, here is not Jary recounted.
The continuous development of JS framework makes front-end development unlimited possibilities
Through continuous development and the efforts of countless experts, "JS can achieve any function" is no longer a joke, and even the slightly frivolous remarks such as "Atwood's Law" have been accepted by more and more people.
Today, there are simple and easy-to-use basic function libraries such as JQuery, Dojo, and awesome frameworks such as AngularJS and BackBone outside. On the shoulders of JS, front-end development has virtually unlimited possibilities.
The development of RESTful Api and Json makes front-end and back-end interactions increasingly convenient
Of course, there are communication problems after separation. How to quickly, concisely, effectively, and uniformly exchange information in the front and back ends has become a problem that must be considered after separation.
Fortunately, the emergence of RESTful ideas and the Json data standard has made this interaction increasingly convenient. On the front end, our well-known JS technology and framework support for RESTful and Json is well established. As for the back end, no matter what language, what The platforms all have very mature solutions.
The different development trends of the front and back end make the need for front and back separation increasingly obvious
As we all know, web development has been inherently deficient in performance, performance, and experience since its emergence, but today, this is no longer the case. Some applications and websites that seem even more dazzling than desktop programs have been born, and customers have been suspended. Appetite. The desktop development of Web development is already an irresistible trend, and the needs of front-end development should develop in the direction of paying more attention to interface performance, speed, and user experience, and the requirements will only become higher and higher.
On the back end, core issues such as stability, performance, security, storage, and business are still mainstream, so the front-end and back-end needs will be increasingly differentiated, and front-end and back-end developers who focus on performance and internality will definitely need their own stage.
Therefore, I think that in the future of web development, the complete separation of the front and back ends should be a direction worth considering. My idea is relatively simple and clear (maybe it is simpler, I hope everyone can correct it), see the following figure:
To achieve this separation, I think there are four main principles:
The front-end has only static content, and to be clear, only HTML / CSS / JS. Its content comes from completely static resources without the need for any background technology for dynamic assembly. The operating environment and engine of the front-end content are completely based on the browser itself .
Backends can be implemented in any language, technology, and platform, but they must follow a principle: only provide data, and do not provide any content related to interface performance. In other words, the data they provide can be used by any other client (such as localization Programs, mobile programs).
The three front-end technologies are platform-independent, and the essence of the back-end connection part is to implement a suitable RESTful interface and interact with Json data.As far as these two technologies are concerned, any technology and platform can be implemented.
The front-end architecture is completely based on the development of HTML / CSS and the evolution of the JS framework. It has nothing to do with the familiar back-end languages (such as C #, Java, NodeJs, etc.). Since the front desk is pure static content, large-scale architecture can be considered to develop in the direction of CDN.
The back-end architecture can be based on almost any solution in any language and platform.In terms of large-scale architecture, RESTful Api can consider load balancing; and data and business implementation can consider database optimization and distribution. The shift was axe.
But all in all, the separation of the front and back ends also achieves the separation of the front and back architecture.
Advantages of separation mode
Significant reduction in front-end and back-end traffic
We know that the majority of front-end and back-end traffic is HTML / JS / IMG resources, and the data is only small heads.The page with resources accounting for more than 100K is not large, but the data is about 10K at best. It's only about 100K, and a slightly larger JS library or image is more than that.
The reduction of traffic lies in the "front-end static" rule. After the first acquisition, static resources will be cached by the browser. Even if the browser continues to poll, the server will return a very small Not Modified response, and the traffic is almost negligible. .
For example, in a page with 100K and 10K data, the traffic for 100 requests is 100K + 10X100 = 1.1M. Obviously, the traffic is significantly lower than the case of obtaining full HTML each time.
Some people have also questioned the performance of this mode of the page.In fact, the situation is not so pessimistic: the first acquisition does have a slight loss, but I think that the loss is minimal, one HTML page is loaded, and more than 10 dozens of K of JS are loaded at the same time. The situation of Image is very common, and no more than 1-2 10K Jsons is not a heavy burden.
However, the subsequent use of this page fully reflects the performance advantages.Most of the content of the page is directly loaded by the local cache, and only 1-2 10K content is obtained remotely.Its loading time is within 100 milliseconds, which is similar to the local page. It's almost the same.It's obvious that the front-end loading and response speed are greatly improved.
Front-end and back-end platform-independent and technology-independent
The front end is pure HTML technology. The front-end staff only needs notepad to develop. It is not a "joke", and the back-end can implement RESTful frameworks and platforms abound. It is entirely possible to choose a technical route that is more suitable for teams, people and companies without tangling. Choice of platform and technology.
Centralized optimization in security
After the front-end is static, front-end page attacks are almost impossible, and some injection attacks are well avoided in the separation mode; while the back-end security issues are centralized, only dealing with the security considerations of a RESEful interface, security erection and centralized optimization changes Be clearer and more convenient.
Development separation and architecture separation
Maybe many teams still have a developer's all-inclusive front-end and back-end model, but I also mentioned that the front-end requirements are getting higher and higher, and the needs of front-end and back-end personnel are becoming increasingly differentiated. Once the system is up-level, the need for separation will definitely appear.
The complete separation of front-end and back-end personnel can make them further seek expertise in their respective fields and become more professional masters.In addition, the front-end and back-end architecture can also be considered and erected separately.The front-end architecture can focus on performance and optimization, while business, security And storage issues can be concentrated on the back-end consideration.
Discussion on Common Problem Solving
Here I read the articles of several masters in the park:
Summer Forest-Thoughts on the Technology Evolution of Large Websites (14)-Website Static Processing-Front and Back Separation
System Architecture: New Trends in Web Application Architecture --- Some Ideas of Front-end and Back-end Separation
Lu Dabao (Double.Lv) A simple and crude front-end separation scheme
Chang 胤 Thinking and practice of front-end separation (1)
It can be said that it has benefited a lot, and for asking some questions, they have also tried to find solutions under their own ideas:
Page logic and rendering effect: It is still just a sentence, JS is omnipotent, relying on the current various JS function libraries and frameworks, after obtaining reasonable data, there is almost no logic and effect that cannot be done. I myself It is biased towards the front-end implementation. Friends who have questions about this point can have in-depth communication. As for the data verification, white screen, routing control, code reuse and other issues raised by some gardeners, the front-end technology can completely solve it.
Server performance and optimization: Because the front-end content is completely static, most of the time after the initial acquisition, the browser uses the local cache, which means that the pressure on the server mainly comes from the RESTFul Api calls that host the data. It is self-evident that coupled with the reasonable design of interactive data, it can be said that the amount of client-server interaction control is approaching the limit.
Security: As the front-end static content can only be obtained, and the back-end can only accept Json, it should be said that a large number of possible injection-type problems are blocked, while some other problems, such as illegal objects, data encryption, DDOS, etc., are themselves It is the responsibility that back-end personnel cannot avoid, and it must be considered in any mode.
Cross-platform, cross-technology: As just mentioned, the front-end technology itself has no platform restrictions, and the back-end can be implemented on almost any platform.
Enterprise-level architecture considerations: The front-end considers building a CDN, the back-end considers load balancing, database optimization, and distributed design. The key problem is that the front-end and back-end architectures can be considered separately and each of them is given to its professionals to set up.
Testing: The front-end JS has a very good unit testing framework (AngularJS), and the back-end RESTFul testing technology is already familiar.
SEO: It is indeed a problem, but it is not difficult to transfer some HTTP routes to SEO function through OWIN or other HTTP Module bridging technology.
Development technology: front-end staff only needs to learn HTML / CSS / JS, while back-end staff only needs to learn back-end language. There is almost no need to intersect.
Ajax cross-domain: If remote calls or a small number of internal calls, you can consider back-end transfer and JSONP, and internal architecture separation can consider CORS.