A little problem about introducing node.js into the front end as the middle layer to communicate with the back end.

Let"s start with the picture above. The questions are listed below. I hope you can greatly solve your doubts.
in order to prevent cross-channel responses, first talk about your understanding of front-end separation. The back-end manages the model layer, business processing / data, etc., and the front-end is responsible for the view or Controller layer (such as the jump after form submission, etc.). For example, suppose there is a SPA application that only provides API (not managed by the Controller layer and view layer) in the development process, and all the front-end pages are displayed. Jump and so on are all controlled by the front end itself, and the only way to communicate between the front and back end is API.

< H2 > questions are as follows < / H2 >
  1. suppose that there is a list that requests directly with node, rendering the template to finally display the page, and directly initiating an ajax request on the page, and then rendering the page with js, will there be any difference (regardless of SEO)
  2. suppose I have a form submission now. Normally, I call the API to get the return value and then make the corresponding operation. In the case of node as the middle tier, the service of node is invoked, and then node invokes the back-end service (such as: API),). What is the difference between calling api directly from the front end?
  3. What are the advantages and disadvantages of
  4. node as the front-end architecture of the middle tier? (similar to the seo, before and after the separation of professional people to do professional things, needless to say, feel that the online things are too scattered, each global vision)
Mar.13,2021

  1. the final result makes no difference. But if you have a high demand for time, I suggest server-side rendering, such as page caching. If the requirements are not too high, I prefer front-end rendering (development is much easier). SEO can return a complete page through ua , which is not too big a problem.
  2. in this way, the front end does not have to care about the back-end service, does not have to send a bunch of requests and then assembles the needed view data, which is handed over to the node , and the back-end changes only need to update the node service at the same time.
  3. I didn't think of the deficiency for the time being. Wait for the boss to point out.
< H2 > add < / H2 >

seeing the answer downstairs reminds me of an article by teacher href= Ice and Fire of distributed system Architecture
question 3 has roughly the same logic


1. Conditional use of node of course to add node, you can not expose the front-end design structure, more in line with the architecture idea.
2. Continue to promote the micro-service architecture, using node as the middle layer to facilitate modular processing.
3. It is obvious that if you increase the development complexity and annoyance of your friends, the maintenance of the business will increase. But it is very architectural and has the idea of design pattern.
4. Thank you, Brother Black fly.


Q1: if it's just a list, it doesn't make a big difference. You can have a good first screen experience by returning to html with node.js rendering. But if the list is paged, you need to load the full page again. At this point, ajax can avoid this problem. The first screen experience can be optimized by front-end technology. Server rendering ultimately depends on the configuration and performance of the server. If you give the rendering to the front end with a large number of visitors, your server will reduce a lot of pressure and configuration savings.
Q2: difference
adding a layer of node as the middle layer obviously adds an extra layer of network requests. Nodejs starts a web server. Your Ajax request was originally made by:
front-end = > nginx= > application server (Java/Server)
now one more layer becomes:
front-end = > nginx= > nodejs middle tier = > application server (Java/Server)
negative situation: if you foolishly deploy node.js middle-tier in a completely different environment from the application server. This layer of network requests will affect the efficiency of requests. If deployed in the same environment, the impact is smaller. But it still makes a difference.
positive case: the nodejs middle layer provides you with the ability to integrate interfaces. In the face of ever-changing front-end business changes. You can flexibly integrate the interfaces you need.
Q3: as a whole, if it can be implemented, the advantages still outweigh the disadvantages. There is an increase in the requirements of the middle tier for front-end personnel (personnel costs) and an increase in maintenance costs (unit testing, test costs). Even the influence of troubleshooting sometimes. The original business logic error may be in the front end, otherwise it is the back end (database, operation and maintenance level is also included). It is still possible to appear covertly in the middle layer. The benefits I feel are flexibility and maintainability. The interface seems to be friendlier and more stable for the front end.

the above are all personal opinions. If there are any mistakes, please help to point them out, because the node.js middle tier has not been practiced yet.

Menu