Home > Java > javaTutorial > Why was jsp eliminated?

Why was jsp eliminated?

(*-*)浩
Release: 2019-05-11 11:22:50
Original
8439 people have browsed it

Most of the previous projects were Java programmers who were both father and mother, working on front-end (ajax/jquery/js/html/css, etc.) and back-end (java/mysql/Oracle, etc.) .

With the development of the times, many large, medium and small companies have gradually begun to distinguish the boundaries between the front and back ends more and more clearly. Front-end engineers are only responsible for front-end things, and back-end engineers are only responsible for back-end things. As the saying goes, there are Specialization, if a person knows everything, then he is not good at anything after all.

Recommended course: Java Tutorial.

Why was jsp eliminated?

Large and medium-sized companies need professionals, and small companies need generalists. But for personal career development, I suggest they be separated. If you are just going to eat Java for the rest of your life, don't study CSS, JS, etc.

Focus your energy on java, jvm principles, spring principles, mysql locks, transactions, multi-threading, large concurrency, distributed architecture, microservices, and related project management, etc., so that your core Competitiveness will become higher and higher. As the saying goes, what you invest in life will be what life will give you back.

(Full of positive energy:

Once you become an elite in the industry, believe me, when the time comes, cars, houses, women, money, and opportunities will all come to you. , don’t worry, really.

It’s really simple to be a Java programmer. The more knowledge you have, the more money you will make. Of course, you also need to have a certain amount of emotional intelligence...

The stronger your ability, the more value you create than others. You create value for the company, and the company gives you various benefits, a win-win situation!)

Once upon a time, Our java web projects all use several backend frameworks, springmvc/struts spring spring jdbc/hibernate/mybatis, etc.

Most projects are divided into three layers in the java backend, the control layer (controller/ action), business layer (service/manage), persistence layer (dao).

The control layer is responsible for receiving parameters, calling relevant business layers, encapsulating data, and routing to jsp pages. Then use various tags (jstl/el) or handwritten java (<%=%>) on the jsp page to display the background data.

Right?

Let’s look at this situation first. The requirements have been determined, the code has been written, and the tests have been completed. What next? Is it about to be released?

You need to use maven or eclipse and other tools to package your code into a war package, and then publish this war package to the web container in your production environment (tomcat/jboss/weblogic/websphere/jetty/ resin), right?

After publishing, you need to start your web container and start providing services. At this time, you can access your website by configuring the domain name, dns, etc. (assuming you are a website).

Let’s see, are all your front-end and back-end codes in that war package? Including your js, css, pictures, and various third-party libraries, right?

Okay, let’s enter your website domain name (www.xxx.com) in the browser. What happens after that? (This question is also an interview question in many companies)

I just picked it up and said, please search for children's shoes with poor foundation.

The browser routes to your service through IP. After the TCP three-way handshake, it starts accessing your web server through the TCP protocol. After your web server gets the request, it starts to provide services, receives the request, and then passes response returns your response to the browser.

So let’s take a look. Let’s first assume that your homepage has 100 pictures and a single-table query. At this time, the user’s seemingly one HTTP request is actually not one. The user first During the first visit, there will be no cache in the browser. For your 100 pictures, the browser will request 100 http requests in succession (someone will tell me about the problem of long and short http links, which will not be discussed here). Your When the web server receives these requests, it needs to consume memory to create a socket for TCP transmission.

Here’s the important point. In this case, the pressure on your web server will be very high, because all requests in the page are only requested to your server. If there is only one person, it will be fine. If there are 10,000 people concurrently As for access (let’s not talk about web server clusters, let’s talk about single-instance web servers), how many TCP links can your server handle? How much memory does your server have? How many IOs can you withstand? How much memory have you allocated to the web server? Will it be down?

This is why, the larger and medium-sized web applications are, the more they need to be decoupled.

Theoretically, you can put your database, application service, message queue, cache, user uploaded files, logs, etc. on one host, but this is like putting all your eggs in one basket, and there are hidden dangers. Very big.

Normal distributed architecture must be disassembled, your application server cluster (front, back) file server cluster, database server cluster, message queue cluster, cache cluster, etc.

Let’s get down to business. First of all, we should try to avoid using jsp in future java web projects, decouple the front and backends, 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 true dynamic and static separation cannot be achieved. The server is under great pressure because the server will receive various http requests, such as css http requests, js, pictures, dynamic codes, etc. Once there is a problem with the server, the front and backends will be played together, and the user experience will be extremely poor.

2. After the front-end engineer completes the html, a java engineer needs to modify the html into a jsp page. The error rate is high (because a large number of js codes often appear in the page), and both parties need to collaborate when modifying the problem. Development, inefficiency.

3.jsp must be run in a web server that supports Java (such as tomcat, etc.), and nginx cannot be used (nginx is said to have up to 50,000 single-instance http concurrency, this advantage must be used), and the performance cannot be improved. .

4. The first time you request jsp, it must be compiled into a servlet in the web server. The first run will be slower.

5. Every time you request jsp, you access the servlet and then use the output stream to output the html page, which is not as efficient as using html directly.

6.jsp contains many tags and expressions. Front-end engineers will be stretched when modifying the page and encounter many pain points.

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

Based on some of the above pain points, we should move the development weight of the entire project forward to achieve true decoupling of the front and back ends!

The old way was:

1. Client request
2. Server-side servlet or controller receives the request (routing rules are formulated by the backend, and most of the weight of the entire project development In the backend)
3. Call service, dao code to complete business logic
4. Return jsp
5.jsp displays some dynamic code

The new way is:

1. The browser sends a request
2. Directly reaches the html page (routing rules are formulated by the front end, and the weight of the entire project development is moved forward)
3. The html page is responsible for calling the server interface to generate data (through ajax, etc. etc.)
4. Fill in html to show dynamic effects.

(Interested children can visit large websites such as Alibaba, and then press F12 to monitor how http works when you refresh the page. Most of them request background data separately. Use json transmits data instead of a large and comprehensive http request to return the entire page including movement)

The benefits of this are:

1. It can achieve true front-end and back-end decoupling , the front-end server uses nginx.

The front-end server places a series of static resources such as css, js, pictures, etc. (You can even put css, js, pictures and other resources into a specific file server, such as Alibaba Cloud's oss, and use cdn Acceleration), the front-end server is responsible for controlling page references, jumps, and calling back-end interfaces. The back-end server uses tomcat.

(You need to use some front-end engineering frameworks such as nodejs, react, router, react, redux, webpack)

2. If you find a bug, you can quickly locate the problem. No There is a phenomenon of kicking the ball at each other.

Page logic, jump errors, browser compatibility issues, script errors, page styles and other issues are all the responsibility of front-end engineers.

Interface data errors, data not submitted successfully, response timeout and other problems are all solved by back-end engineers.

Both parties do not interfere with each other. The front-end and back-end are a family that loves each other.

3. In the case of large concurrency, I can horizontally expand the front-end and back-end servers at the same time. For example, a homepage of Taobao requires 2,000 front-end servers to be clustered to withstand the average daily PV of billions.

(I went to Alibaba’s technology summit and heard them say that all their web containers are written by themselves. Even if a single instance can withstand 100,000 http concurrency, 2,000 units can withstand 200 million http concurrency, and they can also use It’s scary to predict that the peak will come and expand infinitely, just one homepage...)

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

5. Even if the back-end service temporarily times out or is down, the front-end page will be accessed normally, but the data cannot be refreshed.

6. Maybe you also need to have a light application related to WeChat, so that your interfaces can be shared. If there are also app-related services, you can also reuse a large number of interfaces through some code reconstruction to improve efficiency.

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

Note:

1. When holding a requirements meeting, all front-end and back-end engineers must participate, and interface documents need to be formulated. Back-end engineers must write test cases and do not let front-end engineers To act as a full-time tester for your team, it is recommended to use the

chrome plug-in postman, and the service layer test cases are written with junit.

2. The above interface is not the interface in java. To put it bluntly, calling the interface means calling the method in your controller.

3. Increases the workload of the front-end team, reduces the workload of the back-end team, and improves performance and scalability.

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

5. If your project is very small, or a simple intranet project, then you can rest assured that it does not require any architecture, but if your project is an external network project, hahaha.

6. 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 external java web projects, but it does not say that jsp can be completely ignored. For some student friends, jsp/servlet, etc. The relevant java web basics still need to be firmly grasped. Otherwise, what do you think the springmvc framework is based on?

The above is the detailed content of Why was jsp eliminated?. For more information, please follow other related articles on the PHP Chinese website!

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template