mvc – Der Server rendert die global erforderlichen Daten und der Client verwendet React, um sie zu rendern. Ist eine solche Lösung machbar?

Question

Nach der Verwendung von React ist das Rendern einer Ansicht aus Daten relativ einfach,
Aber praktischere Anwendungen erfordern Serverunterstützung, Mehrbenutzer, Echtzeitsynchronisierung usw.,
Ich bin in der bestehenden Praxis auf einige Probleme gestoßen (ich bin mit der Back-End-Architektur nicht sehr vertraut, daher betrachte ich sie aus der Front-End-Perspektive):

• Beim Zwischenspeichern von Daten auf der Browserseite können externe Daten manchmal nur vom Server erfasst werden,
  Der Server weiß nicht immer, welche Daten der Browser benötigt

• Der Browser verfügt über eine Datensicherung, die manuell gepflegt, mit dem Server auf dem neuesten Stand gehalten werden muss usw.
  Ähnliche Vorgänge werden auch ausgeführt, wenn der Server Daten überträgt, sodass auf beiden Seiten doppelter Code vorhanden ist

Deshalb denke ich über eine Lösung nach, um den gesamten Prozess klarer und einfacher zu gestalten (bei kleinen Anwendungen steht die Leistung nicht an erster Stelle):

• Datenoperationen werden auf der Browserseite ausgeführt und alle Änderungen werden basierend auf den vom Server übertragenen Daten vorgenommen
  Mit anderen Worten: Auf dem Server befinden sich alle vom Benutzer benötigten Daten und der Browser synchronisiert sich nur passiv

• Der Server speichert den gesamten aktuellen Status jedes Benutzers, z. B. zu welcher Tabelle der Browser wechselt usw.
  Auf diese Weise kann der Server alle für den aktuellen Benutzer benötigten Daten berechnen

• Die datenbezogenen Aktionen des Clients werden alle über WebSocket an den Server gesendet und vom Server verarbeitet,
  Der Server aktualisiert die lokale Datensicherung über jsonpatch und WebSocket

Ich habe schon lange über diese Idee nachgedacht, aber ich habe noch nicht begonnen, mich damit zu befassen. Haben irgendwelche Klassenkameraden über einen solchen Plan nachgedacht?
Beachten Sie auch, dass es sich bei dem Szenario, das ich in Betracht ziehe, um eine kleine Anwendung handelt, bei der Dutzende Menschen gleichzeitig online sind...

Answer 1

我这个应该不算答案，就当是一起探讨一下吧。你描述的一些东西我觉得看不明白，我先来问问清楚好保证我们在同一条线上：

浏览器端缓存数据时, 有时会遇到外部的数据只能从服务器抓, 而服务器并不总是知道浏览器端需要什么数据

等一下，从服务器上抓数据的时候，难道不是要声明请求类型的吗？为什么服务器需要“知道”浏览器需要什么数据？我的意思是，假设你缓存的数据缺少（比方说）“作者信息”，那就应该 GET /author/:id 对吗？这样怎么会变成服务器“并不总是知道”浏览器需要什么数据？能否举一个例子说清楚你的意思？

浏览器有一份数据备份, 就需要手动维护, 保持跟服务器更新等等、而类似操作在服务器推送数据时也会做, 这样两边就有重复代码

我觉得“推送”就意味着：浏览器其实不知道数据有更新，服务器知道，所以服务器推给浏览器更新后的数据。而你在浏览器手动维护的数据则意味着：你知道数据变化了，所以才要手动维护，并且要提交给服务器以同步数据。

你不觉得这两者恰好是一条线的两端，其实不矛盾吗？为什么会有重复代码？你指的是用于同步数据的代码？

---

所以你所思考的方案：

浏览器端进行数据的操作, 全部靠服务器推送的数据进行更改
意思是客户端不做数据缓存？只要有数据变更操作就从服务器即时获取完整的数据（或者说，一个用户做了操作就立刻把数据更新推给其他所有的客户端）？

……哪个表的哪个数据
若我没理解错，你的意思是假设我是用户 A，我正在看 /author/5 的资料，服务器上应该有一个游标机制注明：“用户 A 正在浏览 authors 表 id 为 5 的数据”，是吗？换句话说，每当 URL 改变的时候就应该发送给服务器“我当前的位置”，然后服务器就把相应的数据推送给我，是这个意思？

那……这和我直接 GET /author/5 拿到数据有多大的区别？

---

你描述的东西，我能看得出来有你自己的想法，但是我觉得场景还是太模糊了。更想听听具体的东西，以具体场景为例到底解决了哪些问题？

Answer 2

而服务器并不总是知道浏览器端需要什么数据

服务器和浏览器端的沟通需要依据规范，backend和fontend的沟通在应用开发中，本身就很重要

浏览器有一份数据备份, 就需要手动维护, 保持跟服务器更新等等

其实业务数据最终都是要保存到服务器上，数据库（mysql等）提供这类服务。而数据在在服务器和客户端之间交互，准备的讲，浏览器的数据可以叫做缓存。缓存范围很广，last_modified和etag也是缓存之一，还有服务器应用内部的缓存

至于重复代码，其实很可能由于backend和fontend的分工不明确导致的，技术架构。不过有时候项目为了快速启动，是允许重复代码的。后期可以慢慢重构。前期只能根据目前的技术水平选择，而不应该陷入技术太深，导致项目无法按期完成

浏览器端进行数据的操作, 全部靠服务器推送的数据进行更改
也就是说服务器上会有一个用户需要的完整的数据存在, 浏览器端仅仅被动同步

应用都是这样子的，数据最终都是落地在服务器上。

服务器上保存每个用户当前所有的状态, 比如浏览器到哪个表的哪个位置等等
这样服务器就能计算出当前用户所需的全部数据

一般来讲，服务器都是设计成无状态的，这个以后项目发展壮大时，服务器扩展的需要。而浏览器需要数据时去服务器获取数据，服务器根据浏览器的发送的参数和接口协议提供数据，并且浏览器很容易知道当前用户在哪个表哪个位置。比如，新浪微薄网站，快到页面尾部的时候，就主动去服务器拉数据，到达一定数量后，采取下一页的链接去获取下一页数据。

客户端与数据相关的 Action 一律通过 WebSocket 向服务器发送由服务器处理,
服务器通过 jsonpatch 和 WebSocket 对本地的数据备份进行更新

这个技术实现主要跟应用场景有关，websocket适合长连接获取数据。如果仅仅一般的更新数据用用普通的http协议就够了。