mvc - 服务端渲染全局所需数据, 客户端用 React 呈现, 这样一套方案可行吗?

Question

用了 React 以后, 从数据渲染 View 流程就相对轻松了,
但是更实用应用需要是有服务端支持, 多用户, 实时同步, 这些等等,
我在已有的实践当中遇到一些问题(我不是很熟悉后端的架构, 所以从前端角度看):

滿天的星座 · Answer

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

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

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

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

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

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

所以你所思考的方案：

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

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

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

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

淡淡烟草味 · Answer

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

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

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

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

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

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

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

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

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

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

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

mvc - 服务端渲染全局所需数据, 客户端用 React 呈现, 这样一套方案可行吗?

全部回复(2)我来回复