52

这在以下情况下很有用：

  • 服务器已关闭，客户端无法连接进行实时同步
  • 没有互联网连接
  • 用户不想上网但想使用应用程序；
4

4 回答 4

55

是的！在大多数情况下，这已经在 Meteor 中实现了。

如果与服务器的连接丢失，客户端仍然可以在本地运行。数据库写入将在客户端上显示为成功并立即反映在屏幕上。一旦重新建立连接，Meteor 将重新发送所有挂起的方法请求到服务器，并使用来自服务器的结果更新客户端显示。这都是延迟补偿的结果，离线被视为服务器非常慢。

客户端可以监控响应式“Meteor.status()”输出以查看当前连接的状态。例如，您可以使用 Meteor.status 来驱动带有重新连接计时器和“立即连接”按钮的弹出窗口，例如 gmail。

编辑：当然，流星不是魔法。如果您点击“重新加载”，或离开页面等，离线时您将失去 Meteor 会话，并且在重新获得网络之前无法重新开始。但是，所有具有离线模式的 Web 应用程序都是如此，因此您的应用程序的用户应该不会感到惊讶。

于 2012-04-13T08:57:05.977 回答
13

还有另外几个选项可以解决“如果您的标签关闭，或者您重新加载”问题。我还没有尝试过，但看起来很有趣。

https://github.com/awwx/meteor-offline-data：

流星离线数据

Meteor 离线数据项目的主页，实现了一个包装 Meteor.Collection 的“离线集合”：

来自服务器的数据永久存储在浏览器数据库中，即使应用程序脱机启动，它也可供应用程序使用。

用户所做的更改也保存在浏览器数据库中，如果浏览器关闭并重新打开，它们会保留下来。下次应用程序上线时，更改将被发送到服务器。

即使在离线时，更新也会在同一应用程序上打开的浏览器窗口之间进行响应式共享。

和 https://github.com/GroundMeteor/Meteor-GroundDB：

特征：

占地面积小

广泛的浏览器支持 Chrome、Safari、Firefox 和 Internet Explorer 9 如果没有本地存储，则回退到正常 Meteor.Collection 恢复集合中的更改 恢复方法 离线更新跨窗口选项卡 支持 SmartCollection 支持仅离线客户端数据库 使用 EJSON.minify和 EJSON.maxify 来压缩 localstorage 中的数据 未来在服务器端会有一个可定制的冲突处理程序

于 2014-05-13T09:37:43.050 回答
0

行的底部：

1）浏览器可以完全保存实际会话（每隔多长时间？每次应用程序请求它，因为得到了更改。对于这样的应用程序，每 10 秒是不够的，我们需要每个事件）。我们可以在 Firefox 中对其进行编程吗？（但它需要保存所有内容（HTML、JS、MinoMongoDB 等），只需进行一次更改！）

2）或者我们有一个客户端完整的流星堆栈来处理本地内容（它自己的本地应用程序），但以某种方式将其 CRUD 操作传达给另一个选项卡或浏览器实例中的另一个在线应用程序。（第二个应用程序将由真正的远程服务器提供服务）问题是这样的两个应用程序是否可以通信。我想浏览器会出于安全原因禁止它）

另一个更有创意的想法可能是：在客户端堆栈上激活 oplog。然后，每次重新上线和在线时，实际客户端的 oplog 可以在主应用程序中导出/导入（这是另一个 oplog 日志），

3) 除非我们可以从客户端的流星全栈发送 call() 请求到服务器上的另一个流星栈。（有可能吗？meteor 中是否有一些关于 URL 域限制的规则）

但它并不能解决在平板电脑上拥有完整流星堆栈的可能性（我不知道这件事是可能的）

于 2015-02-05T17:12:12.520 回答
-1

我不是专家，但让我们想象一个解决方案：

不是在平板电脑/手机上（不确定我们是否可以在此类设备上安装流星堆栈），但在台式机上，用户需要离线可用性，例如销售点、一些交易记录、有限或不是最新的产品清单、定价和库存等（使用非本地库存的交易，应“待确认（离线订单）”（即使已通过离线订单预订，拥有该库存的地点也可能出售，但他们不知道的，因为他们或其他用户离线，特别是如果持有股票的用户是离线用户）

除此之外，某些功能只能在在线时使用（使用另一个 Meteor 网络应用程序）

当然，并非应用程序的所有部分都可以离线使用：敏感记录创建、一些交易、需要完整集合的搜索等。离线功能将通过本地机器网络服务器运行，并且已经安装了工作的本地完整堆栈 Meteor。

Oplog 会将这些离线数据库同步到集中式服务器上的镜像集合，每个用户一个特定的数据库，因此并非所有大数据都可以在用户机器上离线使用。这个想法是保持某些功能的可用性。否则我们可能只有一个 DB 用于所有用户的离线事务，但 oplog 会在所有用户的离线 DB 上同步所有这些事务。我们可以尽快发布并清除这些记录，但对隐私不利。最好的是客户端的离线数据库——并且在集中式服务器上镜像一个——将仅包括该用户创建的记录或用户可能需要的信息，因此每个用户都有一个特定的数据库。

中央服务器端功能将定期验证这些记录并将其发布到更大的包含所有用户的集中式数据库。

一个简单的方法：使用本地离线流星应用程序完成的所有事务，该应用程序将在可用时将事务发布到网络服务。（这样，用户不必管理使用 2 个应用程序，来回。）

我们可以使用 2 个发票编号的概念： 销售发票编号：在交易时生成（文档 ID？）

顺序发票编号：用于会计目的，稍后生成（在线时和 15 到 20 秒的文件。旧的。我们肯定知道在该期间创建的所有新发票）

这里的想法是让本地流星堆栈获取本地持久性，Oplog 与集中式持久性同步（除非我们发送异步 Web 服务调用以在在线时发布事务，但我们会使用更大的 DB 松散自动 sinc）

（毕竟，最好运行两个应用程序：在本地，一个中央服务和一种让这两个应用程序一起交谈的方法，或者一个在线和一个离线应用程序，以一种舒适的方式引导用户优先使用在线应用程序，并且如果离线则离线）

如果更多知识渊博的人社区评估和记录一种工作方式，那就太好了。我还没用Meteor，还在基本的学习过程中。

谢谢，

马克

于 2015-01-31T19:45:39.500 回答