preface

Most of my previous projects were Java programmers who were both father and mother, both front end and back end.

With the development of The Times, gradually many small and medium-sized companies began to divide the boundaries of the front and back end more and more clear, front-end engineers only responsible for front-end things, back-end engineers only back-end things. Is the so-called specialty, if a person can do everything, so it is difficult to achieve mastery of everything.

Large and medium-sized companies need professionals, small companies need generalists, but for individual career development, I recommend separate. If you’re going to live your life in Java, don’t go into CSS, JS, etc.

By focusing on Java, JVM principles, Spring principles, mysql locks, transactions, multithreading, large concurrency, distributed architecture, microservices, and project management, your core competencies will grow. What you put into life will come back to you.

Once upon a time

Our Java Web projects are developed using several backend frameworks, Spring, Spring MVC, MyBatis, Hibernate, etc.

And most projects have three layers in the Java back end: control layer, business layer, and persistence layer. The control layer is responsible for receiving parameters, calling relevant business layers, encapsulating data, and routing to JSP pages. The Jsp page then uses various tag (JSTL/EL) expressions to present the data in the background.

Let’s take a look at the situation above. The requirements are finalized, the code is written, the tests are tested, and then we release:

You need to use tools like Maven or Eclipse to put your code into a WAR package and publish the war package to the Web container in your production environment. After publishing the war, you need to start your Web container and start providing services. At this point, you can configure the domain name, DNS and so on to make your website accessible.

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 website’s domain name in your browser: www.xxx.com. What happens?

The browser routes to your service through IP, after tcp3 handshake, starts to access your Web server through TCP protocol, your Web server gets the request, starts to provide the service, receives the request, and then returns your response to the browser through response.

Let’s say you have 100 images on your home page, and a single table query, and what looks like an HTTP request is not a single request, and when the user first visits, there’s no cache in the browser, your 100 images, The browser will request HTTP requests 100 times in a row (someone will tell me that HTTP is long and short, but I won’t discuss it here), and your Web server will need to consume memory to create sockets to play with TCP traffic when receiving these requests.

Key here, so, your Web server’s pressure will be very big, because the page of all the requests are only request to you on this server, if one is good, if 10000 individual concurrent access (first not talk about the Web server cluster, there is a single instance of the Web server), that you of how many TCP server can resist? How much memory does your server have? How much IO can you hold? How much memory do you assign to the Web server? Will it go down?

That’s why, the larger the medium to large Web applications, the more decoupled they are.

Theoretically you could have your database, application services, message queues, caches, user-uploaded files, logs, and so on all on one host, but you’re putting all your eggs in one basket.

In a normal distributed architecture, it’s all broken down, your application server cluster (front and back) + file server cluster + database server cluster + message queue cluster + cache cluster, etc.

Get into the business

Let’s get down to business. First of all, Java Web projects in the future should try to avoid using JSP, decouple front and back, and play with distributed architecture, so that our application architecture will be stronger.

Pain points of using JSP:

1. Dynamic resources and static resources are all coupled together, and real dynamic and static separation cannot be achieved. The server is under a lot of pressure because the server will receive various HTTP requests, such as CSS HTTP requests, JS requests, images, dynamic code 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 front-end engineer completes the HTML, Java engineers need to modify the HTML into JSP pages, which has a high error rate (because a large number of JS codes often appear in the page). When modifying problems, both sides need to cooperate in development, which is inefficient.

3. JSP must run in savA-enabled Web server (such as Tomcat, etc.), can not use Nginx, etc. (Nginx is said to single instance HTTP concurrency up to 5W, this advantage should be used), performance is not improved.

4. The first time to use JSP, must be compiled into a servlet in the Web server, the first run will be slow.

5. Each REQUEST for JSP is to access the HTML page output by the output stream of Servlet, which is not as efficient as using HTML directly.

6. JSP contains a lot of tags and expressions, front-end engineers in the modification of the page will be overwhelmed, encounter a lot of pain points.

7. If the JSP has a lot of content, the page response will be slow because it is loaded synchronously.

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!

The old way:

1. Client request

2. Servlets or controllers on the server side receive requests (routing rules are made by the back end, and the weight of the whole project development is mostly in the back end)

3. Invoke the Service, and the DAO code completes the service logic

4. Return to the JSP

5. JSP shows some dynamic code

The new way:

1. The browser sends a request

2. Directly to the HTML page (routing rules are made by the front end, the weight of the whole project development is moved forward)

3. The HTML page is responsible for calling the server-side interface to generate data (via Ajax, etc.)

4. Fill in THE HTML to show the dynamic effect.

Interested children can visit alibaba and other large websites, and then click F12, monitoring you refresh a page, his HTTP is how to play, most are separate requests for background data, using JSON data transmission, rather than a large and complete HTTP request to the whole page including dynamic + static all back

The benefits of this are:

1. Real front-end and back-end decoupling can be achieved, with the front-end server using NGINx.

Front-end server is CSS, JS, images and a series of static resources. You can even put CSS, JS, images and other resources into a specific file server, such as ALI Cloud OSS, and use CDN acceleration. The front-end server is responsible for controlling page references, jumps, and calls the back-end interface, and the back-end server uses Tomcat.

Use front-end engineering frameworks such as NodeJS, React, Router, React, Redux, and Webpack

2. Find the bug, who is the problem can be quickly located, 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 over 100 million.

Go to ali’s tech summit and hear them write their own web container, even if it has 100 thousand HTTP concurrent instances, 2000 is 200 million HTTP concurrent instances, and they can scale infinitely based on predicted flood peak, horrible, just one home page.

4. Reduce the concurrency pressure of the back-end server and transfer all HTTP requests except interfaces to the front-end Nginx.

5. Even if the back-end service times out or goes down temporarily, the front-end page will be accessed normally, but the data will not be reproduced.

6. Maybe you also need to have a light application related to wechat, so that your interface can be completely shared. If you also have app-related services, you can also reuse a lot of interfaces through some code reconstruction to improve efficiency.

7. It’s okay to display too much on a page because it’s loading asynchronously.

Note:

1. During the requirements meeting, the front and back end engineers must all attend and prepare interface documents. The back end engineers should write test cases

Chrome plugin Postman, service layer test cases written in junit.

2. The above interface is not the Java interface, so call the method in your Controler.

3. Increased workload of front-end team, reduced workload of back-end team, improved performance and scalability.

4. We need some front-end frameworks to solve 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 Internet project, hehe.

6. The use of template frameworks such as Velocity/Freemarker to generate static pages is now obsolete.

7. The main purpose of this article is to say that JSP has been eliminated in large external Java Web projects, but did not say that JSP can be completely not learn, for some students, servlet and other related Java Web foundation or to master solid, otherwise you think that Spring MVC framework is based on what to write?