React and express are developed in the same structure. Do you need to separate the data end from the service end?

  node.js, question

At present, the backstage providing data services is also express
At present, we are going to develop a front end, which adopts the homogeneous development mode of react and express, and the server renders the page.
Do I need to separate the react plus express in front of me from the express data in use in the background?
If there is no need, directly add react to the current background to build the front end. Do you want front end engineer to work with the back end engineers to maintain this project? Will there be any trouble?
Thank you! ! !

1. The server-side rendering is just as good as your original background rendering. Return the html string to the react front end, which is responsible for displaying it.

2. I think it is good for one person to maintain it, even if two people maintain it, co-work is originally a part of the work, don’t worry.

3. add a little difference between client-side rendering and server-side rendering (client-side rendering vs server-side rendering)

  • Lantency(Delayed) The server-side rendering will load quickly for the first time, because there is no need to request js, css and data like the client-side rendering, and then assemble and display them. The server-side rendering directly sends html strings to the front end. However, when the page data is locally updated or sub-components need to be re-rendered, the server will render much slower because you have to initiate a network request to re-generate most or all of the updated html strings at the server and then return them to the client. However, if the client renders, it only needs to be updated locally.

  • SEO(SEO) The pages rendered by the client are not friendly to the search engine. The search engine usually only uses the html of the page and does not execute js. When the page rendered by the client returns, there is only one html template. the real content is filled by js, which is not friendly to search engines. of course, there are also solutions (PhantomJSThe introduction and reasons of PhantomJS will be noted later), but this will only increase the complexity of your program and is not recommended. If the server renders, because the server has already generated a complete html string, it is beneficial to the analysis of search engines.

  • Browser Concept and Issues(Browser Concepts and Issues) Server Rendering Guaranteedpages are documentsThe definition of, the client through the URL request page document, you should get the document text, rather than a program and then front-end execution. There is also the problem of browser compatibility. The more operations the client renders to the browser, the greater the possibility of compatibility problems.


  • PhantomJSIs a headless browser

  • PhantomJSThe method can solve the problem that client rendering is unfriendly to search engines, and can be applied to the search engines before data is returned to the clientHTML/JavaScript/CSSPre-rendering, which means that when the page is loaded, all initialized js are executed.

  • Since client rendering is unfriendly to search engines, why not?

Main reasons:

  • If you start one for each requestPhantomJSFor example, if a search engine crawls multiple pages at the same time, the performance of your machine will be affected.

  • PhantomJSRunning an old version of JS;

  • Difficulties in debugging;

  • To put it bluntly, the introduction cost is too high to be worth it! ! ! !