swift – 消息库

听起来你已经提出了类似于我以前使用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免费套餐.作为一般经验法则,专注于构建最佳用户体验比关注过度可扩展性要好得多.总的来说,可伸缩性问题很少发挥作用,因为大多数应用程序都失败了.不是说这是令人沮丧的 – 只是要记住一些事情,以防止你在时间成本的情况下陷入过度工程的陷阱:)