我已经用 Parse.com 构建了几个应用程序，其中一个刚刚被提升为资助产品。 就 Parse 实现而言，该应用程序（社交网络）相当复杂。 它具有：
- 近乎实时的聊天
- 新闻源
- 大量的云代码
- IOS客户端和安卓将在未来几周内开始
我经历过很多典型的 Parse 陷阱（超时、超出查询广度等），而这仅适用于大约 2k 用户。 有了我们的新资金，我们很可能会在明年跃升至至少4万用户，这将扩大这个问题。
这一切都归结为这样一个事实，即我认为我们需要远离 Parse，但问题是如何避免停机。
您是如何从 Parse.com 过渡实时应用程序的？ 有什么陷阱或经验教训吗？
我最初的想法是实现一个瘦 API（使用单独的服务器）来将客户端交互从 Parse 中抽象出来，以便我可以转换应用程序。 有人采取这种方法吗？
编辑：
鉴于 Parse 正在关闭这一事实，这个问题与更多人相关，所以我想我会添加我最终做的事情。
我们最终在NodeJS/Express/Mongoose上构建了带有Mongo后端的应用程序（使用 Compose.io）。 如果你能写云代码，你可以为Node编写，而Mongo就是Parse使用的。 我对选项的分析是，创建某种中间层需要花费大量时间，只是使事情复杂化。 我在大约 3 个月内一起拥有新版本，它拥有更大且非常活跃的用户群。
我建议您首先重新审视您的数据模型。设计不当的数据模型将花费您很多。在设计数据模型时，需要考虑的几件事是：
- 您有巨大的数据存储限制，但查询执行较少限制。因此，如果您可以正确管理，最好有一些冗余以减少对服务器的查询/请求。
- 您必须通过拥有这样的模型来尽力避免批处理数据插入/更新操作。
关于迁移，我认为由于您有云代码，因此相对更安全。
- 确保数据已迁移。这将有点痛苦，可能需要一些额外的努力来确保完整性。
- 数据迁移完成后，将云代码制作为包装器。在您自己的服务器上拥有自己的 api，然后使用 Parse.Cloud.httpRequest 从云代码向这些 API 发出请求并提供响应。
- 发布应用更新，以便新用户可以直接与您自己的 API 进行交互。