What technology has replaced jsp now?

The old way is:

1. Customer request

2. The servlet or controller of the server receives the request (the routing rules are formulated by the back end, and the important part of the whole project development is in the back end).

3. Call the service and DAO code to complete the business logic.

4. Return to jsp

5.jsp showed some dynamic codes.

The new method is:

1. Browser sends request.

2. Go directly to the html page (the routing rules are formulated by the front end, and the weight of the whole project development moves forward).

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

4. Fill in html to display dynamic effects.

(Interested children's shoes can visit large websites such as Alibaba, and then click F 12. Once the page is refreshed, you can monitor how his http is played. Most of them request background data separately and use json to transmit data, instead of a big and complete http request to return the whole page including motion and static state. )

The advantages of this are:

1. can realize real front-end decoupling, and the front-end server uses nginx.

The front-end server puts a series of static resources such as css, js, and pictures (even you can put css, js, and pictures into a specific file server, such as oss in Alibaba Cloud, which is accelerated by cdn), the front-end server is responsible for controlling page references, jumping to call the back-end interface, and the back-end server uses tomcat.

(nodejs, react, router, react, redux, webpack and other front-end engineering frameworks are needed here. )

2. Finding bugs can quickly locate the problem, and there will be no kicking each other.

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

Interface data error, data can not be submitted, response timeout and other issues. It was all solved by the back-end engineers.

The two sides do not interfere with each other, and the front end and the back end are family members who love each other.

3. In the case of large concurrency, I can horizontally expand the front and back servers at the same time. For example, a home page of Taobao needs 2000 front-end servers as a cluster to resist pv with an average daily average of several hundred million+.

(Go to Ali's technology summit and listen to them say that their web containers are all written by themselves. Even if a single instance can resist 65438+ million http concurrency, 2000 sets are 200 million http concurrency, which can be expanded infinitely according to the predicted flood peak. It's horrible. It's just a homepage. . . )

4. Reduce the concurrency pressure of the back-end server, and all other http requests except the interface are transferred to the front-end nginx.

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

6. Maybe you need a light application related to WeChat, so that your interface can be fully used. If there are still app-related services, you can use some code refactoring to reuse interfaces in large numbers to improve efficiency.

7. You don't have to worry about anything displayed on the page, because it is loaded asynchronously.