Android Parse.com上的转换应用程序

我已经使用Parse.com构建了几个应用程序，其中一个刚刚被提升为资助产品。就解析实现而言，应用程序（社交网络）相当复杂。它有：

• 近实时聊天
• 新闻提要
• 大量的云代码
• IOS客户端和Android将在未来几周启动

我经历过很多典型的解析陷阱（超时、超出查询宽度等），只有大约2k个用户。有了我们的新资金，我们很可能会在明年增加到至少4万用户，这将加剧这一问题

归根结底，我认为我们需要远离解析，但问题是如何避免停机

您是如何从Parse.com转换实时应用程序的？有什么经验教训吗？

我最初的想法是实现一个瘦API（使用一个单独的服务器），将客户端交互从解析中抽象出来，这样我就可以转换应用程序了。有人采取这种方法吗

编辑：

考虑到Parse正在关闭这个问题，这个问题与更多的人有关，所以我想我应该补充一下我最后做的事情

---

我们最终在NodeJS/Express/Mongoose上用Mongo后端构建了这个应用程序（使用Compose.io）。若您可以编写云代码，那个么您就可以为Node编写代码，而Mongo就是Parse使用的。我对选项的分析是，创建某种中间层需要花费大量时间，这会使事情变得复杂。我在大约3个月的时间内完成了新版本，它的用户群更大、更活跃。

我建议您首先重新审视一下您的数据模型。设计不当的数据模型会使您付出很多代价。在设计数据模型时，很少需要考虑的是：

您有巨大的数据存储限制，但查询执行较少 限制。因此，如果你能妥善管理，最好有一些 冗余以减少对服务器的查询/请求

您必须通过使用这样的模型来尽量避免批处理数据插入/更新操作

关于迁移，我认为由于您有云代码，所以相对来说您更安全

确保数据已迁移。这将是一个有点痛苦，可能需要一些额外的努力来确保完整性

数据迁移完成后，将云代码作为包装器。在自己的服务器上拥有自己的api，然后使用Parse.cloud.httpRequest从云代码向这些api发出请求并提供响应

发布应用程序更新，以便新用户可以直接与您自己的API交互

---

作为一个希望在将来遇到这个问题的人，你是否已经超出了免费30req/秒的水平？你看到了什么问题？如果我们已经超过了30req/秒，那只是非常短暂的。我们看到的问题主要与使用复杂规则填充新闻提要以及解析对所有请求施加的超时有关。您是否考虑过在另一台服务器上执行一些更耗时的方法并上载结果。（例如，将它们作为C#查询运行并上载结果）。这在许多情况下可能没有意义，但它在短期项目中对我们帮助很大，我们希望iOS/Android API的易用性，但我们遇到了云代码超时的问题。（显然，这不是一个很好的长期方法，但如果你没有多余的开发时间，这是很好的）。@ardrian你的建议是我很快就要执行“计划b”，但我相信同样的超时问题也即将发生（我们已经有了一些，但它会变得更糟）。在这一点上，我认为我们要么立即跳转到一个全新的API，要么继续解析并堵塞目前存在的漏洞。两种选择我都不喜欢！