我正在考虑为一个CLASS创建一个特定对话的ROW.在哪里ROW包含诸如“发送者名称”,“接收者”和添加的信息,我有列(PFRelation)将该特定行连接到另一个类,其中从用户到接收者的所有消息将被保存(反之亦然).
因此,每次用户开始新会话时都会发生此操作.
这个前景的好处：
隐私,因为正在保存的唯一控件仅来自用户和接收器组.
这个前瞻性的缺点：
我们都知道解析只能免费提供30reqs / s,这意味着1分钟= 1800 reqs.所以每次我创建一个新类来跟踪convo.我使用了很多请求吗？
在实现这个信使库之前,我正在寻找理想方式的建议和想法.
听起来你已经提出了类似于我以前使用Parse作为后端在应用程序中实现消息传递的东西.考虑UI如何查询数据也很重要.一般而言,确保读取数据非常简单快捷是最重要的.对于大多数社交应用程序,来自 Facebook’s engineering team on Haystack的以下引用特别相关.Haystack is an object store that we designed for sharing photos on
Facebook where data is written once, read often, never modified, and
rarely deleted.
这里的关键信息是一次编写,经常阅读,从未修改过,很少删除.无论您决定采用何种方法,在设计解决方案时都要牢记这一点.我在使用Parse实现消息传递系统之前使用的方法如下所述.
概观
Message类的每一行(对象)都与发布的单个文本,图片或视频消息相对应.每条消息都属于一个组.一个组可以小到2个用户(私人对话)或者随意扩大.
RecentMessage类是我想出的解决方案,可以快速轻松地填充UI.每个RecentMessage对象对应于给定用户可能属于的每个组.组中的每个用户都将拥有自己的RecentMessage对象,该对象使用beforeSave/afterSave cloud code triggers保持最新.每当创建新消息时,在afterSave触发器中,我们希望更新属于该组的所有RecentMessage对象.
您很可能在应用中有一个表格,其中显示了用户所属的所有会话.这很容易通过查询所有用户的RecentMessage对象来实现,这些对象已经包含在选择时加载其余消息所需的所有组信息,并且还包含要在表中显示的最新消息的数据(因此名称).或者,RecentMessage可以包含指向最新消息的指针,但是我决定复制数据是一种有益的权衡,因为它简化了将来的查询.
信息
> group(指向哪个消息所属的组的指针)
> user(指向创建它的用户的指针)
>文字(字符串)
>图片(可选文件)
>视频(可选文件)
RecentMessage
>组(组指针)
>用户(用户指针)
> lastMessage(包含最新消息文本的字符串)
> lastUser(指向发布最新消息的用户的指针)
组
> members(用户指针数组)
>姓名或您想要的任何其他信息
安全/隐私
在您的应用中创建消息传递功能时,安全性和隐私是必不可少的请务必仔细阅读Parse Engineering安全博客文章,并花些时间将其全部放入：Part I,Part II,Part III,Part IV,Part V.
在我们的案例中最重要的是描述ACL的第III部分,或Access Control Lists.组对象将具有对应于其所有成员User的ACL. RecentMessage对象将对其所有者User具有受限制的读/写ACL.消息对象将继承它们所属的组的ACL,允许所有组成员读取.我建议在afterSave触发器中禁用写入ACL,以便不能修改消息.
一般说明
关于Parse和请求限制,您需要接受这样一个事实,即您将很快超过30 req / s免费套餐.作为一般经验法则,专注于构建最佳用户体验比关注过度可扩展性要好得多.总的来说,可伸缩性问题很少发挥作用,因为大多数应用程序都失败了.不是说这是令人沮丧的 – 只是要记住一些事情,以防止你在时间成本的情况下陷入过度工程的陷阱:)