Using Parse.com Android SDK in Java server as opposed to Android app

Question

We are considering to use parse.com as our database back end and we are currently looking for a Java SDK for parse. As far as I can tell, there are two, one is Almonds (https://bitbucket.org/jskrepnek/almonds) and the other is the official Android SDK from Parse (https://parse.com/downloads/android/Parse/latest).

We are planning to make calls out to Parse from a Java based server (Jetty) and we do not have an Android app or plan to have one in foreseeable future.

I am leaning towards the Android SDK since it's the official one. However, my primary concern is its performance in a multi-threaded environment when used by a Jetty server which potentially could be initiating many requests to Parse at the same time for the same or different sets of data.

My other alternative is obviously to use their REST API and write my own utilities to encapsulate the functions. I would highly appreciate if anyone has experience with this and can share with us. Thanks!

Answer 1

I write this in January, 2014. Parse.com is rapidly growing and expanding their platform. I cannot say how long this information will be correct or how long my observations will remain relevant.

That said...

Number one. Parse.com charges by the number of transactions. Many small transactions can result in a higher cost to the app owner. We are using Parse.com's Pro Plan. The Pro Plan has these limits:

• 15 million HTTP requests per month
• Burst limit of 40 requests per second

If you have 4,500 users, each sending 125 HTTP requests to Parse.com per day, then you are already looking at 16,850,000 requests every 30 days. Parse.com also offers a higher level of service called Parse Enterprise. Details about this plan are not published.

Second, Parse.com's intended purpose is to be a light-weight back-end back-end for mobile apps. I believe Parse.com is a very good mobile backend-as-a-service (MBaaS - link to a Forrester article on the subject).

I am building a server-side application using Parse.com. I use the REST interface, Cloud Functions, and Cloud Jobs. In my opinion, Parse.com is a clumsy application server. It does not expose powerful tools to manipulate data. For example, the only way to drop a table is by clicking a button in Parse's Web Data Browser. Another example is that Parse sets the type of an attribute when an object is first saved. If data type is changed in an object, say from string to pointer, Parse.com will refuse to save the object.

The Cloud Function programming model is build on Node.js. Complex business logic will quickly land you in callback hell because all database queries and save operations are asynchronous. That is, when you save or query an object, you hand Parse a function and say "when the save/query is complete, run this function". This might come naturally to LISP programmers, but not to OO programmers raised on Java or .Net. Be aware of this if you intend to write Cloud Code for your application. My productivity took a nose dive when I started writing Cloud Functions.

The biggest challenge I experience with Parse.com is round-trip-time. Here are some informal benchmarks:

Getting a single object via the REST API has pretty consistent RTT of 800ms

• GET https://api.parse.comapi.parse.com/1/classes/Element/xE5sZCQd6D
• Response: Status=200, Round trip time=0.846

ICMP is blocked, but just knocking on the door takes 400-800 ms, depending on the day.

• GET https://api.parse.comapi.parse.com/1
• Status=404, Round trip time=0.579

Parse.com is in Amazon's data center in Northern Virginia. I used Ookla's Speedtest to estimate my latency to that area. Reaching the Richmond Business Center server (75.103.15.244) in Ashburn gives me a ping time of 95ms. A server in D.C. gave me a ping time of 97 ms. Two hundred milliseconds of Internet overhead is not the problem.

The more queries or save operations a Cloud Function performs, the longer response time. Cloud Functions with one or two queries or save operations have an RTT between 1 and 3 seconds. Cloud Functions with multiple queries and save operations have an RTT between 3 and 10 seconds.

HTTP requests sent to Parse.com time-out after 15 seconds. I have a Cloud Function I use for testing that deletes all objects in the database. This Cloud Function can delete a couple hundred rows before timing out. I converted the Cloud Function into a Cloud Job because jobs can run for up to 15 minutes. The job deletes 400-500 objects and takes 30-60 seconds to complete. Job status is available only through the Web browser. I had to create a light-weight job status system so other devs could query the status of their jobs.

Parse's best use case is the iPhone developer who wrote a game and needs to store the user's high scores, but knows nothing about servers. Use Parse where it is strong.