我们正在考虑使用parse.com作为我们的数据库后端,我们目前正在寻找用于解析的Java SDK.据我所知,有两个,一个是杏仁(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天就会查看一次请求.Parse.com还提供更高级别的服务,称为Parse Enterprise.有关此计划的详细信息未发布.
其次,Parse.com的目标是成为移动应用程序的轻量级后端后端.我相信Parse.com是一个非常好的移动后端即服务(MBaaS - 关于该主题的Forrester文章的链接).
我正在使用Parse.com构建服务器端应用程序.我使用REST接口,云功能和云作业.在我看来,Parse.com是一个笨拙的应用服务器.它没有公开强大的工具来操纵数据.例如,删除表的唯一方法是单击Parse的Web数据浏览器中的按钮.另一个例子是Parse在首次保存对象时设置属性的类型.如果在对象中更改了数据类型,比如从字符串到指针,Parse.com将拒绝保存对象.
Cloud Function编程模型构建在Node.js上.复杂的业务逻辑将很快让您陷入回调地狱,因为所有数据库查询和保存操作都是异步的.也就是说,当您保存或查询对象时,您可以手动解析函数并说"保存/查询完成后,运行此函数".对于LISP程序员来说,这可能是自然而然的,但对于在Java或.Net上提出的OO程序员来说则不然.如果您打算为您的应用程序编写Cloud Code,请注意这一点.当我开始编写云功能时,我的工作效率急剧上升.
我在Parse.com上遇到的最大挑战是往返时间.以下是一些非正式基准:
通过REST API获取单个对象具有相当一致的800毫秒RTT
ICMP被阻止,但只需敲门就需要400-800毫秒,具体取决于当天.
Parse.com位于亚马逊北部弗吉尼亚州的数据中心.我使用Ookla的Speedtest来估计我在该区域的延迟.到达Ashburn的里士满商务中心服务器(75.103.15.244)给我一个95ms的ping时间.DC中的服务器给了我97 ms的ping时间.200毫秒的互联网开销不是问题.
云功能执行的查询或保存操作越多,响应时间就越长.具有一个或两个查询或保存操作的云功能具有1到3秒的RTT.具有多个查询和保存操作的云功能的RTT在3到10秒之间.
发送到Parse.com的HTTP请求在15秒后超时.我有一个用于测试的云功能,可以删除数据库中的所有对象.此云功能可在超时前删除几百行.我将云功能转换为云作业,因为作业可以运行长达15分钟.作业删除400-500个对象,需要30-60秒才能完成.作业状态仅可通过Web浏览器使用.我不得不创建一个轻量级的工作状态系统,以便其他开发人员可以查询他们的工作状态.
Parse的最佳用例是iPhone开发人员编写游戏并需要存储用户的高分,但对服务器一无所知.在强大的地方使用Parse.