场景是: 某些用户向某些人 发送消息。
我正在考虑为该特定对话创建一个 ROW 到一个 CLASS 中。该行中的 WHERE 包含诸如“发件人姓名”、“接收者”和附加信息之类的信息，我有一列(PFRelation)将该特定行连接到另一个类，其中从用户到接收者的所有消息都将被保存(反之亦然)。
所以这个 Action 会在每次用户开始一个新的对话时发生。
这个前景的好处:
隐私，因为唯一被保存的 convo 仅来自用户和接收者组。
这个前景的缺点:
我们都知道 parse 只免费提供 30reqs/s，这意味着 1 min = 1800 reqs。所以每次我创建一个新类来跟踪 convo。我使用了很多请求吗？
在实现这个 Messenger 库之前，我正在寻找理想方式的建议和想法。
最佳答案
听起来您想出了一些类似于我之前使用 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 类的每一行(对象)对应于发布的单个文本、图片或视频消息。每个 Message 都属于一个 Group 。一个 Group 可以小到 2 个 User(私有(private)对话)，也可以根据需要增长。RecentMessage 类是我想出的解决方案，用于快速轻松地填充 UI。每个 RecentMessage 对象对应于给定 Group 可能属于的每个 User。 User 中的每个 Group 都有自己的 RecentMessage 对象，该对象使用 beforeSave/afterSave cloud code triggers 保持最新。每当创建新的 Message 时，在 afterSave 触发器中，我们要更新属于 RecentMessage 的所有 Group 对象。您的应用程序中很可能会有一个表格，用于显示用户参与的所有对话。这可以通过查询该用户的所有
RecentMessage 对象来轻松实现，这些对象已经包含在选择时加载其余消息所需的所有 Group 信息，并且还包含要显示在表中的最新消息数据(因此名称)。或者， RecentMessage 可以包含指向最新 Message 的指针，但是我认为复制数据是一种有益的权衡，因为它简化了 future 的查询。信息
最近消息
Message 文本的字符串) User 的 Message 的指针) 团体
安全/隐私
在您的应用程序中创建消息传递功能时，安全和隐私是必不可少的。请务必通读 Parse Engineering 安全博客文章，并花时间让它们全部吸收: Part I 、 Part II 、 Part III 、 Part IV 、 Part V 。
在我们的案例中最重要的是第三部分，它描述了 ACL 或 Access Control Lists 。
Group 对象将有一个对应于其所有成员 User 的 ACL。 RecentMessage 对象将对其所有者 User 具有受限的读/写 ACL。 Message 对象将继承它们所属的 Group 的 ACL，允许所有 Group 成员读取。我建议在 afterSave 触发器中禁用写入 ACL，以便无法修改消息。一般说明
关于 Parse 和请求限制，您需要接受这样一个事实，即您将很快超过 30 req/s 免费层。作为一般经验法则，专注于构建最佳用户体验比过多关注可扩展性要好得多。总的来说，可扩展性问题很少出现，因为大多数应用程序都失败了。并不是说这令人沮丧——只是要记住一些事情，以防止您以时间为代价陷入过度设计的陷阱:)
关于swift - 消息库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34012298/