mvc - The server renders the globally required data, and the client uses React to render it. Is such a solution feasible?

Question

After using React, the process of rendering View from data is relatively easy,
But more practical applications require server support, multiple users, real-time synchronization, etc.,
I encountered some problems in the existing practice (I am not very familiar with the back-end architecture, so I look at it from the front-end perspective):

• When the browser caches data, sometimes external data can only be captured from the server.
  The server does not always know what data the browser needs

• The browser has a data backup, which requires manual maintenance, keeping updated with the server, etc.
  Similar operations are also performed when the server pushes data, so that there are duplicate codes on both sides

So I am thinking of a solution to make the whole process clearer and simpler (for small applications, performance is not considered first):

• Data operations are performed on the browser side, and all changes are made based on data pushed by the server
  In other words, there will be a complete data required by the user on the server, and the browser will only passively synchronize

• The server saves all the current status of each user, such as which table the browser goes to, etc.
  In this way, the server can calculate all the data required by the current user

• The client's data-related actions are all sent to the server through WebSocket and processed by the server.
  The server updates the local data backup through jsonpatch and WebSocket

I have been thinking about this idea for a long time, but I haven’t started to delve into it. Have any classmates thought about such a plan?
Also note that the scenario I am considering is a small application where dozens of people are online at the same time...

Answer 1

This shouldn’t be considered the answer, let’s just discuss it together. I don’t think I understand some of the things you described, so I’ll ask first to make sure we’re on the same page:

When the browser caches data, sometimes external data can only be captured from the server, and the server does not always know what data the browser needs

Wait a minute, when grabbing data from the server, don’t you have to declare the request type? Why does the server need to "know" what data the browser needs? I mean, assuming your cached data is missing (say) "author information", that should GET /author/:id right? How does this mean that the server "doesn't always know" what data the browser needs? Can you give an example to clarify what you mean?

The browser has a data backup, which requires manual maintenance, keeping updated with the server, etc. Similar operations will also be done when the server pushes data, so there will be duplicate code on both sides

I think "push" means: the browser actually doesn't know that the data has been updated, the server knows, so the server pushes the updated data to the browser. The data you manually maintain in the browser means: you know that the data has changed, so you have to manually maintain it and submit it to the server to synchronize the data.

Don’t you think that these two are exactly two ends of the same line, and they are not contradictory? Why is there duplicate code? Are you referring to the code used to synchronize data?

---

So the solution you are thinking about:

Data operations are performed on the browser side, and all changes are made based on data pushed by the server
Does it mean that the client does not cache data? As long as there is a data change operation, the complete data will be obtained from the server immediately (or in other words, if a user performs an operation, the data update will be pushed to all other clients immediately)?

...Which data from which table
If I understand correctly, what you mean is that assuming I am user A and I am looking at the data of /author/5, there should be a cursor mechanism on the server that indicates: "User A is browsing the data with id 5 in the authors table", right? In other words, whenever the URL changes, it should send "my current location" to the server, and then the server will push the corresponding data to me. Is this what you mean?

Then...how big is the difference between this and me getting the data directly GET /author/5?

---

I can see that you have your own thoughts on what you described, but I think the scene is still too vague. I would like to hear more specific things. What problems have been solved using specific scenarios as examples?

Answer 2

And the server doesn’t always know what data the browser needs

The communication between the server and the browser needs to be based on specifications. The communication between backend and fontend is very important in application development

The browser has a data backup, which requires manual maintenance, keeping updated with the server, etc.

In fact, business data must ultimately be saved on the server, and databases (mysql, etc.) provide such services. The data interacts between the server and the client. To put it simply, the browser's data can be called cache. The cache range is very wide, last_modified and etag are also one of the caches, as well as the cache inside the server application

As for the repeated code, it is actually probably caused by the unclear division of labor between backend and fontend, and the technical architecture. However, sometimes projects allow duplication of code in order to start quickly. It can be reconstructed slowly later. In the early stage, you can only choose based on the current technical level, and you should not get too deep into the technology, causing the project to be unable to be completed on schedule

Data operations are performed on the browser side, and all changes are made based on data pushed by the server
In other words, there will be a complete data that the user needs on the server, and the browser will only passively synchronize

Applications are all like this, and the data is ultimately landed on the server.

The server saves all the current status of each user, such as which table the browser goes to, etc.
This way the server can calculate all the data needed for the current user

Generally speaking, servers are designed to be stateless. This will be the need for server expansion when the project develops in the future. When the browser needs data, it goes to the server to obtain the data. The server provides data according to the parameters and interface protocols sent by the browser, and the browser can easily know which table and position the current user is in. For example, the Sina Weibo website takes the initiative to pull data from the server when it reaches the end of the page. After reaching a certain amount, it takes the link of the next page to obtain the next page of data.

The client’s data-related actions are all sent to the server through WebSocket and processed by the server,
The server updates the local data backup through jsonpatch and WebSocket

The implementation of this technology is mainly related to the application scenario. Websocket is suitable for long connections to obtain data. If you just generally update data, it is enough to use the ordinary http protocol.