| Guided reading | Recently, the project has entered the acceptance stage, and project deployment is essential. For some reason, we put the front-end project (Angular4) and the back-end project (JavaWeb), because four projects are to be deployed: Angular4 (WeChat), Wechat data service, JavaWeb (PC)*2, and it is placed under the same server. Java projects are easier to deploy, and Tomcat/Jetty can be easily deployed. But Angular is not so easy to deploy (of course, for a rookie like me), let me first explain why I say it is not easy. |
Initially, when I compiled and packaged with ng build --prod --aot. Note here that since it is now officially built-in, you only need to enter ng build –prod when packaging. Here's a comparison with my project volume:
ng build : 8,348,761 bytes ng build --aot : 9,232,405 bytes ng build --prod : 1,839,811 bytes ng build --prod --aot : 1,839,811 bytes
Finally, it can be seen that ng build –prod can complete the minimum product packaging. There is one thing I don't understand here. The precompiled build is larger than the regular build. I hope God can help you answer it.
I won't talk about how to make the project smaller here.
When I copied the files in dist to the ROOT folder of Tomcat and opened http://127.0.0.1, the familiar project page was displayed. Habitually press F5 to refresh, and found a 404 error. I found related problems in Baidu and found that: when entering the page for the first time, running the normal process and the normal process are handled by Angular's routing mechanism. However, if there is a refresh operation, it is a request sent to the back-end service. If the back-end does not redirect your request to index.html (here refers to the entry of a single-page application), it will report 404 not found Page fault.
Wow, so verbose. But at least you understand what the reason is, and if you know the reason, you should think about how to solve it!
Workaround 1:
Configure Angular's url style to hash style, this method is the most I have seen, and it is copied from StackOverflow. Now the pushstate style of H5 is generally used, and Angular officially tells us that if there is no reason to use the hash style, it is better to use the H5 style as much as possible. It is not suitable for you to have a #anchor now? And some people pointed out that if the hash style is configured, there will still be a 404 problem in the deep path of WeChat payment or angular. If you insist on using it, that's fine, see the official documentation for details
Workaround 2:
Since it reports 404, why don't you specify the error page as the root directory in tomcat?
Description: Open the Tomcat container directory, Tomcat/conf/web.xml, move to the bottom, and add the following code on it:
After configuration, restart Tomcat. No matter how to refresh this time, the page is displayed without any problem. But we found that although the page can be displayed, under the network tab, we can see the 404 request. That is to say, when we refreshed, angular could not find the page, but was directed to index.html by Tomcat as 404. Tomcat led a misguided person back on the right track, but at the same time stamped on him the "he was a bad guy" mark. Let's not talk about whether the method of matching error pages is suitable, let's talk about what problems this 404 mark will bring us. First of all, as long as you encounter a platform with 404 error page handling, you are definitely done. For example, on WeChat, he detected that you appeared on page 404, and he immediately gave you a page to help a lost child find a home.
He is very conscientious and kind. He has done a good job in public welfare, but your job is about to be lost. If your page is placed in the official account, as soon as you authorize it, you will enter the page for finding children. It's fine if your manager doesn't hack you to death. So it's up to you whether this method is useful or not!
Solution 3
Then you can't find the page, and I will guide you in the back end! I write an interceptor, or filter. I'll redirect to your index.html before you send any request, that's fine! Of course there is no problem, this is to find a specific medicine for the cause~ It seems to be a perfect solution~ However, we found that we did not mention the theme of today, and we must pick a little problem with this solution! Otherwise, our ultimate ult would appear bland.
Since our project is separated before and after, stateless services. The back-end is responsible for database operations and returns relevant interface data to the front-end, while the front-end is only responsible for processing display logic and interacting with the back-end. Frequent forwarding,
back-end ps: You let me not need to deal with the page, and let me forward it, is it stupid? If your backend just doesn't want to do the work of forwarding, what can you do? Of course, it is bullying the operation and maintenance!
Solution · Ultimate
If you are the god of operation and maintenance, then it is estimated that you can drink tea by the side. If it is... Mengxin? Then as a front-end, you can help (zhuang) busy (bi), use nginx! Reverse proxy, load balancing, balabala…
Pretend here that you have an nginx environment, I am using windows here. Open the nginx.conf file, don't write a specific description, read the comments yourself, if you don't want to read it, you can download the configuration file directly.
It should be noted that the root directory configuration is not location / {}, which means that all requests are forwarded.
The original text comes from: https://www.linuxprobe.com/nginx-tomcat.html