Cela ne devrait pas être considéré comme la réponse, discutons-en simplement ensemble. Je ne pense pas comprendre certaines des choses que vous avez décrites, je vais donc d'abord vous demander de m'assurer que nous sommes sur la même longueur d'onde :

Lorsque le navigateur met en cache les données, parfois les données externes ne peuvent être capturées qu'à partir du serveur, et le serveur ne sait pas toujours de quelles données le navigateur a besoin

Attendez une minute, lors de la récupération des données du serveur, n'êtes-vous pas obligé de déclarer le type de requête ? Pourquoi le serveur a-t-il besoin de « savoir » de quelles données le navigateur a besoin ? Je veux dire, en supposant qu'il manque (disons) des "informations sur l'auteur" à vos données mises en cache, alors elles devraient être GET /author/:id, n'est-ce pas ? Comment cela signifie-t-il que le serveur « ne sait pas toujours » de quelles données le navigateur a besoin ? Pouvez-vous donner un exemple pour clarifier ce que vous voulez dire ? GET /author/:id 对吗？这样怎么会变成服务器“并不总是知道”浏览器需要什么数据？能否举一个例子说清楚你的意思？

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

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

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

---

所以你所思考的方案：

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

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

那……这和我直接 GET /author/5

---

Le navigateur dispose d'une sauvegarde des données, qui nécessite une maintenance manuelle, une mise à jour avec le serveur, etc. Des opérations similaires seront également effectuées lorsque le serveur envoie des données, il y aura donc du code en double des deux côtés

🎜Je pense que « push » signifie : le navigateur ne sait pas que les données ont été mises à jour, le serveur le sait, donc le serveur envoie les données mises à jour au navigateur. Les données que vous conservez manuellement dans le navigateur signifient : vous savez que les données ont changé, vous devez donc les maintenir manuellement et les soumettre au serveur pour synchroniser les données. 🎜 🎜Ne pensez-vous pas que ces deux-là sont exactement les deux extrémités d’une même ligne, et qu’ils ne sont pas contradictoires ? Pourquoi y a-t-il du code en double ? Faites-vous référence au code utilisé pour synchroniser les données ? 🎜 🎜 🎜Alors la solution à laquelle vous réfléchissez : 🎜 🎜 🎜Les opérations sur les données sont effectuées côté navigateur et toutes les modifications sont apportées en fonction des données transmises par le serveur
Cela signifie-t-il que le client ne met pas les données en cache ? Tant qu'il y a une opération de modification de données, les données complètes seront immédiatement obtenues du serveur (ou en d'autres termes, si un utilisateur effectue une opération, la mise à jour des données sera immédiatement transmise à tous les autres clients) ? 🎜 🎜 🎜 🎜...Quelles données de quelle table
Si je comprends bien, ce que vous voulez dire, c'est qu'en supposant que je suis l'utilisateur A et que je regarde les informations de /author/5, il devrait y avoir un mécanisme de curseur sur le serveur qui indique : "Utilisateur A parcourt la table des auteurs. Données avec l'identifiant 5", n'est-ce pas ? En d'autres termes, chaque fois que l'URL change, elle doit envoyer « ma position actuelle » au serveur, puis le serveur me transmettra les données correspondantes. Est-ce ce que vous voulez dire ? 🎜 🎜 🎜Alors... quelle est la différence entre cela et le fait que j'obtienne les données directement via GET /author/5 ? 🎜 🎜 🎜Je vois que vous avez vos propres réflexions sur ce que vous avez décrit, mais je pense que la scène est encore trop vague. J'aimerais entendre des choses plus précises. Quels problèmes ont été résolus en utilisant des scénarios spécifiques comme exemples ? 🎜

Et le serveur ne sait pas toujours de quelles données le navigateur a besoin

La communication entre le serveur et le navigateur doit être basée sur des spécifications. La communication entre le backend et le fontend est très importante dans le développement d'applications

.

Le navigateur dispose d'une sauvegarde des données, qui nécessite une maintenance manuelle, une mise à jour avec le serveur, etc.

En effet, les données métiers doivent in fine être sauvegardées sur le serveur, et les bases de données (mysql, etc.) fournissent de tels services. Les données interagissent entre le serveur et le client. Pour faire simple, les données du navigateur peuvent être appelées cache. La plage de cache est très large, last_modified et etag font également partie des caches, ainsi que le cache à l'intérieur de l'application serveur

Quant au code répété, il est probablement dû à la division peu claire du travail entre le backend et le fontend, ainsi qu'à l'architecture technique. Cependant, les projets permettent parfois de dupliquer du code afin de démarrer rapidement. Il pourra être reconstruit lentement plus tard. Au début, vous ne pouvez choisir qu'en fonction du niveau technique actuel, et vous ne devez pas approfondir la technologie, ce qui empêcherait le projet d'être achevé dans les délais

Les opérations sur les données sont effectuées côté navigateur et toutes les modifications sont apportées en fonction des données transmises par le serveur
En d'autres termes, il y aura toutes les données dont l'utilisateur a besoin sur le serveur, et le navigateur ne se synchronisera que passivement

Les applications sont toutes comme ça, et les données sont finalement débarquées sur le serveur.

Le serveur enregistre tout l'état actuel de chaque utilisateur, comme la table à laquelle le navigateur accède, etc.
De cette façon, le serveur peut calculer toutes les données nécessaires à l'utilisateur actuel

D'une manière générale, les serveurs sont conçus pour être sans état. Cela sera nécessaire pour l'expansion du serveur lorsque le projet se développera à l'avenir. Lorsque le navigateur a besoin de données, il se rend au serveur pour obtenir les données. Le serveur fournit des données en fonction des paramètres et des protocoles d'interface envoyés par le navigateur, et le navigateur peut facilement savoir dans quelle table et dans quelle position se trouve l'utilisateur actuel. Par exemple, le site Sina Weibo prend l'initiative d'extraire les données du serveur lorsqu'il atteint la fin de la page. Après avoir atteint un certain montant, il faut le lien de la page suivante pour obtenir la page de données suivante.

Les actions liées aux données du client sont toutes envoyées au serveur via WebSocket et traitées par le serveur,
Le serveur met à jour la sauvegarde des données locales via jsonpatch et WebSocket

La mise en œuvre de cette technologie est principalement liée au scénario d'application. Websocket convient aux connexions longues pour obtenir des données. Si vous mettez simplement à jour les données, il suffit d'utiliser le protocole http ordinaire.