【发布时间】：2015-03-29 02:44:47
【问题描述】：
我使用 Parse.com 构建了多个应用程序，其中一个刚刚被提升为受资助的产品。就 Parse 实现而言，该应用程序（社交网络）相当复杂。它有：
- 近乎实时的聊天
- 新闻源
- 大量云代码
- IOS 客户端和 Android 将在未来几周内推出
我经历过很多典型的 Parse 陷阱（超时、超出查询宽度等），而且只有大约 2k 用户。有了我们的新资金，明年我们可能会跃升至至少 4 万用户，这将放大问题。
这一切都归结为我认为我们需要摆脱 Parse，但问题是如何避免停机。
您是如何从 Parse.com 转换实时应用程序的？有什么陷阱或经验教训吗？
我最初的想法是实现一个瘦 API（使用单独的服务器）以将客户端交互从 Parse 中抽象出来，这样我就可以转换应用程序。有人采用这种方法吗？
编辑：
鉴于 Parse 正在关闭这个问题与更多人相关，所以我想我会添加我最终做的事情。
我们最终在 NodeJS/Express/Mongoose 上使用 Mongo 后端（使用 Compose.io）构建了应用程序。如果您可以编写云代码，则可以为 Node 编写云代码，而 Parse 使用的是 Mongo。我对选项的分析是，创建某种中间层只会使事情复杂化，这将花费大量时间。我用了大约 3 个月的时间就完成了新版本，它拥有更大且非常活跃的用户群。
【问题讨论】：
-
作为一个希望在未来遇到这个问题的人，你有没有把免费的 30req/sec 水平扩大到以上？你发现了什么问题？
-
如果我们已经超过了 30req/sec，那只是非常短暂的。我们看到的问题主要与使用复杂规则填充新闻源以及解析对所有请求施加的超时有关。
-
您是否考虑过在另一台服务器上执行一些更耗时的方法并上传结果。 （例如，将它们作为 C# 查询运行并上传结果）。这在许多情况下可能没有意义，但它在我们希望 iOS/Android API 易于使用的短期项目中为我们提供了极大的帮助，但我们遇到了云代码超时问题。 （显然不是一个很好的长期方法，但如果您没有多余的开发时间，这很好）。
-
@ardrian 你的建议是我快速接近的“计划 b”，但我确信同样的超时问题对我们来说也指日可待（我们已经有了一些，但它会变得更糟） .在这一点上，我想我们要么立即跳到一个全新的 API，要么继续使用 Parse 并填补我们目前的漏洞。我不喜欢任何一个选项！
标签： android ios api parse-platform