我们正在考虑使用 parse.com 作为我们的数据库后端，我们目前正在寻找用于解析的 Java SDK。据我所知，有两种，一种是 Almonds ( https://bitbucket.org/jskrepnek/almonds )，另一种是 Parse 的官方 Android SDK ( https://parse.com/downloads/android/解析/最新）。
我们计划从基于 Java 的服务器 (Jetty) 调用 Parse，我们没有 Android 应用程序或计划在可预见的将来拥有一个。
我倾向于 Android SDK，因为它是官方的。但是，我主要关心的是它在多线程环境中的性能，当它被 Jetty 服务器使用时，它可能会同时针对相同或不同的数据集发起许多 Parse 请求。
我的另一个选择显然是使用他们的 REST API 并编写我自己的实用程序来封装这些函数。如果有人有这方面的经验并可以与我们分享，我将不胜感激。谢谢！
我在 2014 年 1 月写这篇文章。Parse.com 正在迅速发展和扩展他们的平台。我不能说这些信息会正确多久，或者我的观察会保持多久。
那就是说...
第一。Parse.com 按交易次数收费。许多小交易可能会给应用程序所有者带来更高的成本。我们正在使用 Parse.com 的专业计划。专业计划有以下限制：
如果您有 4,500 个用户，每个用户每天向 Parse.com 发送 125 个 HTTP 请求，那么您已经在每 30 天查看 16,850,000 个请求。Parse.com 还提供更高级别的服务，称为 Parse Enterprise。有关该计划的详细信息未公布。
其次，Parse.com 的预期目的是成为移动应用程序的轻量级后端。我相信 Parse.com 是一个非常好的移动后端即服务（MBaaS - 链接到有关该主题的 Forrester 文章）。
我正在使用 Parse.com 构建服务器端应用程序。我使用 REST 接口、Cloud Functions 和 Cloud Jobs。在我看来，Parse.com 是一个笨拙的应用服务器。它没有公开强大的工具来操作数据。例如，删除表的唯一方法是单击 Parse 的 Web 数据浏览器中的按钮。另一个例子是 Parse 在第一次保存对象时设置属性的类型。如果对象中的数据类型发生更改，例如从字符串更改为指针，Parse.com 将拒绝保存该对象。
Cloud Function 编程模型基于 Node.js 构建。复杂的业务逻辑会让你很快陷入回调地狱，因为所有数据库查询和保存操作都是异步的。也就是说，当你保存或查询一个对象时，你递给 Parse 一个函数并说“当保存/查询完成时，运行这个函数”。这对于 LISP 程序员来说可能很自然，但对于在 Java 或 .Net 上长大的 OO 程序员来说却不是。如果您打算为您的应用程序编写云代码，请注意这一点。当我开始编写 Cloud Functions 时，我的工作效率急剧下降。
我在 Parse.com 遇到的最大挑战是往返时间。以下是一些非正式的基准：
通过 REST API 获取单个对象的 RTT 相当一致，为 800 毫秒
ICMP 被阻止，但敲门需要 400-800 毫秒，具体取决于日期。
Parse.com 位于北弗吉尼亚的亚马逊数据中心。我使用 Ookla 的 Speedtest 来估计我对该区域的延迟。到达 Ashburn 的 Richmond Business Center 服务器 (75.103.15.244) 后，我的 ping 时间为 95 毫秒。DC 的服务器给了我 97 毫秒的 ping 时间。200 毫秒的 Internet 开销不是问题。
云函数执行的查询或保存操作越多，响应时间就越长。具有一两个查询或保存操作的 Cloud Functions 的 RTT 介于 1 到 3 秒之间。具有多个查询和保存操作的 Cloud Functions 的 RTT 介于 3 到 10 秒之间。
发送到 Parse.com 的 HTTP 请求在 15 秒后超时。我有一个用于测试的云函数，用于删除数据库中的所有对象。这个云函数可以在超时之前删除几百行。我将 Cloud Function 转换为 Cloud Job，因为作业最多可以运行 15 分钟。该作业删除 400-500 个对象，需要 30-60 秒才能完成。作业状态只能通过 Web 浏览器获得。我必须创建一个轻量级的工作状态系统，以便其他开发人员可以查询他们的工作状态。
Parse 的最佳用例是编写游戏并需要存储用户的高分但对服务器一无所知的 iPhone 开发人员。在强大的地方使用 Parse。