Home >Backend Development >PHP Tutorial >Questions about front-end and back-end separation mode
At this stage, the front-end and back-end work are mixed together. The front-end writes the demo and hands it to the back-end to render the data. Once a bug occurs, debugging is time-consuming and labor-intensive. Therefore, there is an urgent need to separate the front-end and back-end. I searched online for a long time, usually SPA mode and node Pattern
SPA mode uses cross-domain requests to solve data acquisition problems. But it is not conducive to SEO optimization.
So I took a look at the NODE-based separation model:
I don’t know if this model is correct. If you have other good solutions, please let me know in the comments. Thank you very much!
At this stage, the front-end and back-end work are mixed together. The front-end writes the demo and hands it to the back-end to render the data. Once a bug occurs, debugging is time-consuming and labor-intensive. Therefore, there is an urgent need to separate the front-end and back-end. I searched online for a long time, usually SPA mode and node Pattern
SPA mode uses cross-domain requests to solve data acquisition problems. But it is not conducive to SEO optimization.
So I took a look at the NODE-based separation model:
I don’t know if this model is correct. If you have other good solutions, please let me know in the comments. Thank you very much!
There are roughly three types:
1. The front-end maintains the page template and is responsible for development; it is pushed to the back-end when publishing, and the back-end is deployed and operated. For example, vm, there is velocityjs that can complete compilation, filling in and display on the node side, and the front end can complete page development locally. The coupling part with the backend is to render data for the page. It must be agreed in advance to determine the data format and local mocking is enough;
2.spa is not necessarily cross-domain. The page is maintained in the backend, a unified shell, and the backend only needs to maintain it. Just use js referenced by different pages. The js stuffs things into the page. Of course, the data is completed asynchronously on the client side. As for seo, you can use phantomjs to capture the page and save it, and then configure ng to deal with crawlers. In fact, the biggest problem with this solution is that the page is not displayed initially after it comes in, which means the white screen time will be relatively long. Instead, js must be executed and the data will be displayed asynchronously. This problem is quite common. Of course, you can use offline packages or cache to optimize this experience in app and other links, which is relatively common;
3.node, I think there is nothing wrong with your picture, but there are various implementations of the php part, java, node You can wait and see. As for json, it is nothing more than reducing front-end and back-end coupling. It can be determined in advance, do not change, and can be developed in parallel. The introduction of node is nothing more than allowing the front end to directly provide pages for access. However, if the front end writes one node page rendering each time, it will also cause a relatively large development cost. Then there is the idea of isomorphism, such as the isomorphism of reactjs. Node only provides a router, and other page processing server and client are completely consistent.
My humble opinion, hope it helps
We are basically responsible for providing JSON or JSONP data in the background. After the front-end gets the data, it displays and renders the data. No problems are found. I don’t know what the questioner said: Once a bug occurs, debugging is time-consuming and laborious, and I don’t quite understand what the big problem is
All data is handled by the backend, and the frontend is responsible for page implementation. Data can be obtained from the backend server through ajax.