Shulou(Shulou.com)06/01 Report--

Why do you want to give up JSP? I believe that many inexperienced people are at a loss about it. Therefore, this article summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Preface

Most of the previous projects were Java programmers, both parents and parents, both front-end and back-end.

With the development of the times, gradually many large, small and medium-sized companies begin to divide the boundaries between the front and back ends more and more clearly. The front-end engineers are only responsible for the front-end things, and the back-end engineers are only responsible for the back-end things. As the saying goes, there is a specialty in the art industry. if a person knows everything, then it is difficult to master everything.

Large and medium-sized companies need professionals, small companies need all-round talents, but for personal career development, I suggest separation. If you only eat Java for the rest of your life, don't study css,js and so on.

Focus your energies on Java,JVM principles, Spring principles, mysql locks, transactions, multithreading, large concurrency, distributed architecture, micro services, and related project management, etc., so that your core competitiveness will become higher and higher. Life will give you feedback on what you put into life.

only a short while ago

Our Java Web projects are developed using several background frameworks, such as Spring, Spring MVC, MyBatis, Hibernate and so on.

And most projects in the Java backend are divided into three layers, control layer, business layer, persistence layer. The control layer is responsible for receiving parameters, calling the relevant business layer, encapsulating data, and routing to the JSP page. Then various jstl/el expressions are used on the Jsp page to display the background data.

Let's take a look at the above situation. The requirements are set, the code is written, the tests are done, and then released:

You need to use tools such as maven or eclipse to package your code into a war package, and then publish the war package to a Web container in your production environment. After publishing, you need to start your Web container and start providing services. At this time, you can access your website by configuring domain name, dns, and so on.

Let's see, is your front and back code all in that war package? Including your js,css, pictures, and various third-party libraries, right?

OK, now enter your website domain name: www.xxx.com in the browser, and then what happens?

The browser routes to your service through ip. After the tcp3 handshake, the browser starts to access your Web server through the tcp protocol. After receiving the request, your Web server begins to provide the service, receives the request, and then returns your reply to the browser through response.

Let's assume that there are 100 pictures on your home page and a single table query. At this time, the user's http request appears to be not one. When the user visits it for the first time, there will be no cache in the browser. Your browser will have to request 100 http requests (some people will tell me that the problem of http long chain and short chain will not be discussed here). Your Web server will receive these requests. It takes a lot of memory to create socket to play tcp transport.

The point is, in this case, the pressure on your Web server will be very great, because all the requests in the page are only requested to your server. If one person is all right, if 10000 people visit concurrently (let's not talk about web server cluster, here it is a single-instance Web server), how many tcp links can your server hold? How much memory does your server have? How much IO can you resist? How much memory did you allocate to the web server? Will there be a downtime?

This is why, the more large and medium-sized Web applications, the more they need to decouple.

In theory, you can throw your database + application service + message queue + cache + user uploaded files + log + and so on on one host, but it is as if you put all your eggs in one basket.

Normal distributed architecture is to be taken apart, your application server cluster (front and back) + file server cluster + database server cluster + message queue cluster + cache cluster and so on.

Get to the point.

Let's get to the point. First of all, the future Java web projects should try to avoid using JSP, decouple the foreground and background, and play with the distributed architecture, so that our application architecture is stronger.

Pain points for using JSP:

Dynamic resources and static resources are all coupled together, so it is impossible to achieve real dynamic and static separation. The server is under a lot of pressure because it receives all kinds of http requests, such as css http requests, js requests, picture requests, dynamic code requests, and so on. Once there is something wrong with the server, the front and background play together, and the user experience is very poor.

After the front-end engineer completes the html, the Java engineer needs to modify the html into a jsp page, which has a high error rate (because a large amount of js code often appears in the page), and requires collaborative development by both parties when modifying the problem, which is inefficient.

JSP must run in a Web server that supports Sava (for example, tomcat, etc.), and cannot use nginx and so on (nginx says that the concurrency of single instance http is as high as 5w, which is an advantage), and the performance cannot be improved.

When you ask JSP for the first time, you must compile it to servlet in the web server, which will be slow the first time.

Each request JSP visits the html page of Servlet reuse output stream, which is not as efficient as using html directly.

There are many tags and expressions in JSP, and front-end engineers are strapped to make changes to the page and encounter a lot of pain points.

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

Based on some of the above pain points, we should move the development weight of the whole project forward to achieve real decoupling of the front and rear ends!

The old way:

Client request

The servlet or controller of the server receives requests (routing rules are made by the backend, and most of the weight of the whole project development is in the backend)

Call the service,dao code to complete the business logic

Return to JSP

Jsp shows some dynamic code

New ways:

Browser sends request

Go directly to the html page (the routing rules are made by the front end, and the weight of the whole project development is moved forward)

The html page is responsible for calling the server-side interface to generate data (through ajax, etc.)

Fill html to show dynamic effects.

Interested children's shoes can visit Alibaba and other large websites, and then click F12 to monitor how you refresh the page and how his http is played. Most of them request background data separately and use json to transfer data, rather than a large and complete http request to return the whole page, including dynamic + static.

The benefits of this are:

Real front-end decoupling can be achieved, and the front-end server uses nginx.

The front-end server puts a series of static resources such as css,js, pictures and so on. You can even put css,js, images and other resources on a specific file server, such as Aliyun's oss, and use cdn to accelerate. The front-end server is responsible for controlling page referencing, jumping, calling the back-end interface, and the back-end server uses tomcat.

Here we need to use some front-end engineering frameworks such as nodejs,react,router,react,redux,webpack

Find bug, can quickly locate who is the problem, will not appear to kick the ball each other phenomenon.

The front-end engineer is responsible for page logic, jump errors, browser compatibility issues, script errors, page styles and other problems.

The problems such as interface data error, unsuccessful data submission and response timeout are all solved by the back-end engineer.

The two sides do not interfere with each other, the front end and the back end are a loving family.

In the case of large concurrency, I can scale the front and rear servers horizontally at the same time. For example, a home page of Taobao needs 2000 front-end servers to cluster to withstand the daily average of hundreds of millions of pv.

Go to Ali's technology summit, listen to them say that their web containers are written by themselves, even if he single instance anti-100000 http concurrency, 2000 is 200 million http concurrency, and they can also predict the flood peak to unlimited expansion, very scary, just a home page.

Reduce the concurrency pressure on the back-end server and transfer all http requests except the interface to the front-end nginx.

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 brushed out.

Maybe you also need to have Wechat-related lightweight applications, so that your interfaces can be fully shared, and if you also have app-related services, you can also reuse a large number of interfaces to improve efficiency through some code refactoring.

No matter how many things are displayed on the page, you are not afraid because it is loaded asynchronously.

Note:

In the requirements meeting, the front and rear engineers must all participate, and need to develop interface documentation, the back-end engineers should write test cases, do not let the front-end engineers act as your team full-time test, recommend to use

The test cases for the postman,service layer of the chrome plug-in are written in junit.

The above interface is not the interface in java, to put it bluntly, to call the interface is to call the method in your controler.

It increases the workload of the front-end team, reduces the workload of the back-end team, and improves performance and scalability.

We need some front-end frameworks to solve functions such as page nesting, paging, page jump control and so on. (the front-end frameworks mentioned above).

If your project is very small, or a simple intranet project, you can rest assured, do not need any architecture, but if your project is an extranet project, ha.

In the past, some people used template frameworks such as velocity/freemarker to generate static pages, but now this practice has been eliminated.

The main purpose of this article is to say that JSP has been eliminated in large-scale public network Java web projects, but it does not say that JSP can not be learned at all. for some students, servlet and other related Java web foundations should be firmly mastered, otherwise, what do you think Spring MVC is based on?

After reading the above, do you know why you want to give up JSP? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.