Doubts about Front and Rear End Separation Models
At this stage, the front and back work are mixed together. demo is written by the front end and rendered by the back end. Once a bug occurs, debugging is time-consuming and laborious. Therefore, it is urgent to separate the front and back ends. It has been searched on the Internet for a long time and is generally Specialty retailer of Private label Apparel and node mode.
Specialty retailer of Private label Apparel uses cross-domain requests to solve data acquisition problems. But it is not conducive to SEO optimization.
So I looked at the NODE-based separation model:
I don’t know if this model is correct, if there are other good solutions, please comment and let me know, thank you very much!
There are roughly three types:
1. Front-end maintenance page template, responsible for development; Pushed to the back-end when publishing, back-end deployment operations. For example, vm, there is a velocityjs that can complete compilation and fill-in number display at the node end, and the front end can completely complete page development locally. And the local mock is sufficient.
2.spa is not necessarily cross-domain. The page is maintained in the back end, a unified shell. The back end only needs to maintain js referenced by different pages. js inserts something into the page. Of course, the data is completed asynchronously by the client. As for seo, you can use phantomjs to save the page as well as ng configuration to deal with crawler. In fact, the bigger problem with this scheme is that the page was not displayed initially after it came in, that is, the white screen time would be longer, but js should be executed, and it would be displayed only after asynchronous data acquisition. This problem is more common. Of course, offline package or cache can be used to optimize this experience under app and other links, which is quite common.
3.node, I don’t think there is any problem with your picture, but php has various implementations, java, node, etc. As for json, it is nothing more than to reduce the coupling between front and back ends, to be able to determine in advance, not to change, and to develop in parallel. The introduction of node is nothing more than to enable the front end to directly provide pages for access. However, if the front end writes one node page rendering at a time, it is also a relatively large development cost. Then there is the idea of isomorphism, such as the isomorphism of reactjs. node provides a router, and other page processing servers and clients are completely consistent.
Personal humble opinion, hope a little help