Today I’m going to share with you why do we separate the front and back ends? What are the advantages and disadvantages?
Next, Letbyte Z will take you to the theme:
A, foreplay
Front-end and back-end separation has become the industry standard for Internet project development. It can be effectively decouple by using Nginx + Tomcat (or by adding a NodeJS in the middle), and the front-end and back-end separation will be used for large-scale distributed architecture, elastic computing architecture, micro-service architecture, and multi-terminal services (multiple clients, such as: Browsers, in-car terminals, Android, IOS, etc.) lay a solid foundation. This step is necessary for a system architecture to evolve from an ape to an adult.
The core idea is that the front-end HTML page invokes the Back-end Restuful API through Ajax and interacts with JSON data.
In the Internet architecture, noun definitions:
Web servers: Typically nginx, Apache and other servers that can only parse static resources.
Application server: generally refers to servers such as Tomcat, Jetty, resin can resolve dynamic resources and static resources, but the ability to resolve static resources is not as good as web server.
Generally, only the Web server can be accessed from the Internet, and only the application server can be accessed from the Intranet.
Two, the technical industry has specialized (developer separation)
Most previous JavaWeb projects were Java programmers who were mom and dad, front-end and back-end.
With the development of The Times, gradually many small and medium-sized companies began to put the boundaries of the front and back end more and more clear, front-end engineers only front-end things, back-end engineers only back-end things. Is the so-called specialty, if a person can do anything, so he is not good at anything after all.
Large and medium-sized companies need professionals, small companies need generalists, but for individual career development, I recommend separate.
1. For backend Java engineers:
Focus on Java fundamentals, design patterns, JVM principles, Spring + Spring MVC principles and source code, Linux, mysql transaction isolation and locking mechanism, mongodb, HTTP/TCP, multi-threading, distributed architecture, elastic computing architecture, microservice architecture, Java performance optimization, And related project management and so on.
The back end pursues the three high points (high concurrency, high availability, high performance), security, storage, business, and so on.
2. For front-end engineers:
Focus on HTML5, CSS3, jquery, AngularJS, Bootstrap, ReactJS, Vuejs, Webpack, less/sass, gulp, NodeJS, Google V8, javascript multi-threading, modular, Faceted programming, design patterns, browser compatibility, performance optimization, and more.
The front-end is about page performance, speed, compatibility, user experience, and so on.
There is specialization, so that your core competitiveness will be higher and higher, is the so-called what you put into life, life will give you what. And both ends of the development are more and more advanced, you think what will, after all, you are not fine.
By dividing the team into front and back end teams, engineers on both sides can focus more on their respective fields and manage them independently, and then build a full-stack team of excellence.
Three, primitive times (various coupling)
There was a time when our JavaWeb projects used several backend frameworks, SpringMVC/Struts + Spring + Spring JDBC/Hibernate/Mybatis, etc.
Most projects have three layers in the Java backend: a control layer, a business layer, and a persistence layer. The control layer is responsible for receiving parameters, calling relevant business layers, encapsulating data, and routing & rendering to JSP pages. Then JSP page using a variety of tags or handwritten Java expressions will show the background data, playing is MVC that set of ideas.
Let’s look at the situation: requirements are finalized, code is written, tests are tested, and then what? Ready to launch? You need to use tools like Maven or Eclipse to break your code into a WAR and publish that WAR to a Web container in your production environment, right?
Once you’re done publishing, you need to start your Web container and start providing services, at which point you’ll be able to access your site (assuming you’re a website) by configuring the domain name, DNS, etc. Is your front and back end code all in that WAR package? That includes your JS, your CSS, your images, all kinds of third-party libraries, right?
Ok, now enter your web domain name (ww w.xx.com) in your browser. What happens? (This question is also a lot of companies interview questions) I picked up dry said ah, the foundation is not good children’s shoes please go to search.
The browser through the domain name through DNS server to find your server external IP, send HTTP request to your server, after the tcp3 handshake (HTTP is TCP/IP below), through TCP protocol start to transmit data, your server gets the request, start to provide services, receive parameters, and then return your response to the browser, The browser then uses the Content-Type to parse the content you return and present it to the user.
So let’s take a look at, we first assume that there are 100 images in your home page, at this point, the user’s seemingly an HTTP request, it’s not time, the user at the time of the first visit, the browser does not have a cache, your 100 images, the browser to be attached to the request 100 HTTP requests (HTTP long even short even someone would tell me the problem, Not discussed here), your server receives these requests, and it consumes memory to create sockets to play with TCP transfers (costing your server four, JSP pain points)
Layer before most of the use of JSP javaWeb project as a page display data to the user, because the traffic is not high, so it is less demanding performance requirements, but now is the era of big data, for the performance requirements of the Internet project is more and more high, so the original front end coupling together of architectural pattern has gradually can not meet us, So we need to find a decoupled way to dramatically increase our load capacity.
1, dynamic resources and static resources are all coupled together, the server is under great pressure, because the server will receive various HTTP requests, such as CSS HTTP requests, JS, images and so on. Once the server is in trouble, the front and back end play together, and the user experience is terrible.
2. After the UI has a good design drawing, the front-end engineer is only responsible for cutting the design drawing into HTML, which needs to be set into JSP pages by Java engineers. The error rate is high (because a large number of JS codes often appear in the page).
3, JSP must be run in Java support web server (such as Tomcat, Jetty, resin, etc.), can not use Nginx, etc. (Nginx is said to single instance HTTP concurrency up to 5W, this advantage should be used), performance can not be improved.
4. The first request for a JSP must be compiled into a servlet in the Web server, which will run slower the first time.
5, each request JSP is access to the servlet output stream output HTML page, efficiency is not direct use of HTML high (is every yo, pro ~).
JSP has so many tags and expressions that the front-end engineer will be overwhelmed and encounter many pain points when modifying the page.
7. If the JSP has a lot of content, the page response will be slow because it is loaded synchronously.
8, the need for front-end engineers to use Java IDE (such as Eclipse), as well as the need to configure a variety of back-end development environment, you have considered the experience of front-end engineers.
Based on some of the pain points mentioned above, we should move the development weight of the entire project forward to achieve true decoupling of the front and back ends!
Iv. Development mode
The old way was:
1. Product experience/leader/customer demand
2. Make design drawings for UI
3. Front-end engineers do HTML pages
4, back-end engineers will HTML pages into JSP pages (before and after the end of the strong dependence, back-end must wait for the front-end HTML to do a good job in order to set JSP. If the HTML changes, it’s even more painful and inefficient.)
5, integration problems
6. Front-end rework
7. Back-end rework
8. Secondary integration
9. Integration is successful
10, delivery,
The new approach is:
1. Product experience/leader/customer demand
2. Make design drawings for UI
3. Interfaces & data & parameters are agreed on the front and back ends
4, the front and back end parallel development (no strong dependence, can be the front and back end parallel development, if the demand changes, as long as the interface and parameters remain unchanged, do not need to modify the code on both sides, high development efficiency)
5. Front and rear end integration
6. Front-end page adjustment
7. Integration is successful
8, delivery,
5. Request method
The old way was:
1. Client request
2. Servlets or controllers on the server side receive requests (the back end controls routing and rendering pages, and the weight of the whole project development is mostly on the back end)
3. Call service and DAO code to complete business logic
4. Return to JSP
5. JSP displays some dynamic code
The new approach is:
1. The browser sends the request
2, directly to the HTML page (front-end control routing and rendering page, the weight of the whole project development forward)
3. The HTML page is responsible for generating data by calling the server-side interface (via Ajax, etc., and returning data in JSON format in the background, which replaces XML for its simplicity and efficiency)
4. Fill in HTML, display dynamic effects, parse and manipulate DOM on the page.
To summarize the new approach to request steps:
Large number of concurrent browser requests –> Web Server Cluster (NGINx)– > Application Server Cluster (Tomcat)– > File/database/cache/message queue server cluster
At the same time, it can be divided into modules and divided into small clusters according to business to prepare for the later architecture upgrade.
Six, the advantages of separation before and after
1. Real front-end and back-end decoupling can be achieved, with the front-end server using NGINx. Front/WEB server to put the CSS, js, pictures and so on a series of static resources (you can even CSS, js, pictures and other resources on a particular file server, such as ali cloud oss, and use the CDN acceleration), the front-end server is responsible for the control of page references & jump & routing, the front page asynchronous calls the backend interface, The back-end/application server uses Tomcat (think of it as a data provider) to speed up overall response times. (Use front-end engineering frameworks such as NodeJS, React, Router, React, Redux, webpack)
2, find the bug, can quickly locate who is the problem, there will be no mutual kicking phenomenon. Page logic, jump errors, browser compatibility issues, scripting errors, page styles, etc., are all the responsibility of the front-end engineer. Problems such as interface data error, data submission failure, and reply timeout are all solved by back-end engineers. The two sides do not interfere with each other, and the front end and back end are a loving family.
3. In the case of large concurrency, I can expand the front and back end servers horizontally at the same time. For example, a home page of Taobao needs 2000+ front-end servers as a cluster to resist the daily pv of hundreds of millions. (Go to ali’s tech summit and hear them write their own web container, even if it has 100 thousand HTTP concurrent singletons, 2000 is 200 million HTTP concurrent singletons, and they can scale infinitely based on predicted flood peak, horrible, just one home page…)
4. Reduce the concurrency/load on the back-end server. All HTTP requests except for the interface are transferred to the front-end Nginx, and the interface requests invoke Tomcat, referring to the Nginx reverse proxy Tomcat. And the browser makes a lot of calls to the local cache except for the first page request.
5. Even if the back-end service is temporarily timed out or down, the front-end page will be accessed normally, but the data will not be brushed out.
6. Maybe you also need to have a light application related to wechat, so that your interface can be completely shared. If there are also app-related services, then as long as some code reconstruction, you can also reuse a lot of interfaces to improve efficiency. (Multi-terminal application)
7, the page is not afraid to display more things, because it is asynchronous loading.
8, Nginx support page hot deployment, do not need to restart the server, front-end upgrade more seamless.
9. Increase code maintainability & readability (code that is coupled at the front and back ends is quite laborious to read).
10, improve the development efficiency, because the front and back end of parallel development, rather than the previous strong dependency.
11, the deployment of certificates in nginx, the use of HTTPS access to the external network, and only open port 443 and 80, other ports are closed (to prevent hacker port scanning), Intranet use HTTP, performance and security are guaranteed.
A lot of front-end component code to reuse, componentalization, improve development efficiency, out!
Seven, notes
1. During the requirements meeting, both front and back end engineers must attend and develop interface documents. Back end engineers should write test cases (2 dimensions). Test cases for the Service layer are written in junit. Ps: Can you play unit tests on the front end?
The above interface is not the Java interface, so call the method in your controler.
3. Increased the workload of the front-end team, reduced the workload of the back-end team, and improved performance and scalability.
4, we need some front-end framework to solve the functions like page nesting, paging, page jump control and so on. (Those front-end frameworks mentioned above).
5. If your project is small, or if it’s purely an Intranet project, you can rest assured that you don’t need any architecture, but if your project is an extranet project, hehe.
6. In the past, some people have used template frameworks such as Velocity/Freemarker to generate static pages.
7, the main purpose of this article is to say that JSP in the large external Java Web project has been eliminated, but did not say that JSP can be completely not learn, for some students, JSP /servlet and other related Java Web foundation or to master the firm. What else do you think a framework like SpringMVC is based on?
8. If the page has some permissions and other related validation, the related data can also be retrieved from the interface via Ajax.
For both front-end and back-end logic, I recommend putting it in the front end, why? Because you need the logic of the computing resources to calculate, if on the backend to run logic, will & CPU & memory bandwidth and so on computing resources, you should remember is the server-side computing resources are limited, and if on the front end, using the client computing resources, so your server load will drop (high concurrency scenario). Similar to data verification, both the front and back end need to do!
10, the front end needs to have a mechanism to deal with the back-end request timeout and back-end service downtime, friendly display to the user.
8. Read more
1. In fact, static resources such as JS, CSS and pictures can be considered in the OSS file server similar to Ali Cloud (if it is an ordinary server & operating system, stored in the file after reaching the PB level, or the number of files in a single folder reaches 30,000 to 50,000, IO will have serious performance problems). With CDN (national child Node Acceleration) on OSS, your pages will fly no matter where you are in the country, and your Nginx load will be further reduced.
2, if you want to play a lightweight service architecture, to use nodejs gateway, the benefits of using nodejs and conducive to seo optimization, because nginx is static resource to the browser to return to the page, and domestic search engine crawlers would grab the static data, the page that will not be parsed js, which can not good search engine application support. Also, because Nginx does not do page assembly rendering, the static page needs to be returned to the browser and rendered, which increases the rendering burden of the browser. Requests initiated by the browser are distributed through Nginx, and URL requests are uniformly distributed to NodeJS for page assembly and rendering. API requests are sent directly to the back-end server to complete the response.
3. If you encounter cross-domain problems, Spring4’s CORS can be perfectly solved, but there are generally no cross-domain problems using nginx reverse proxy, unless you split the front-end and back-end services into two domains. The JSONP approach is also obsolete.
4, If you want to play multiple applications, pay attention to remove the tomcat native session mechanism, use the token mechanism, use caching (because it is a distributed system), do a single point, for the security of the token mechanism, you can search JWT.
5. Mock tests can be added to the front-end project (virtual test objects can be constructed to simulate the back-end, which can be independently developed and tested). The back-end needs detailed test cases to ensure the availability and stability of the service.
Nine,
Front-end separation is not just a development pattern, but an architectural pattern (front-end separation architecture). Don’t think that separating the front end from the back end means separating the front end from the back end. You need to separate the front end from the back end. Front-end and back-end projects are two projects, on two different servers, deployed independently, two different projects, two different code bases, and different developers.
The front and back end engineers need to agree interaction interfaces to achieve parallel development. After development, they need to deploy independently. The front end invokes HTTP requests through Ajax and invokes restful apis at the back end. The front end only needs to focus on page style and dynamic data parsing & rendering, while the back end focuses on concrete business logic.
This article is reprinted at: Lybyte
There are still a lot of things to learn, of course, the process of learning has also brought me a lot of sense of achievement, these achievements also promote me to learn more technical knowledge.