收藏
回答

关于最新推出的“实时数据推送”的几点建议。为什么“实时数据推送”还有局限性?

首先必须赞一个,实时数据推送解决了很多问题,实现的效果非常棒!给小程序工程师加鸡腿🍗!!


我在使用过程中也遇到了一定的麻烦,我觉得在api层面如果能提供更多支持,那这个功能会更棒!


  1. 希望能够控制init获取记录的数量。在对话列表的场景中,无限制的数据获取意味着吞吐量的可怕增长。对于实际体验来说,数据量一旦达到一定规模,网络、渲染都必定会出现一定问题。权宜之计是设置数据查询时的时间范围,但这无法灵活地解决矛盾。不过当然,控制数量也意味着先实现排序,工作量的确不小。

  2. 希望提供watcher的暂停、恢复功能。在多个不同的watcher间切换,为了减轻网络负担,常常会先关闭一个watcher,再打开下一个。但watcher重启后,要么会将本来已有的数据重新获取一次,浪费网络与配额、要么对已经获取到的数据失去监听权限(设置条件,排除已经获取到的数据),用户体验不太好。

  3. watcher对于date的处理,是否支持“现在”?比如数据库中有个含有未来某个时间点的记录,我希望watcher能够到达那个时间再触发,能否实现?根据目前的where的文档,貌似是不可以的。


回答关注问题邀请回答
收藏

1 个回答

  • 邓坤力
    邓坤力
    2019-09-04

    感谢反馈

    1. 后续我们会支持控制数量

    2. 我们考虑下怎么样才合理

    3. 意思是发起监听,但是希望等到某个时间点的时候才真正发起监听?

    2019-09-04
    有用 2
    回复 1
    • 2019-09-05
      感谢回复!关于第三点,其实是想让db.command对Date类型的数据提供一个与当前时间(即时的,而不是固定一个时间)比较的方法。
      2019-09-05
      1
      回复
登录 后发表内容
问题标签