I write this in January 2014. Parse.com is growing rapidly and expanding its platform. I can’t say how long this information will be correct or how long my observations will remain relevant.
That said ...
Number one. Parse.com transaction costs. Many small transactions can add value to the application owner. We use the Parse.com Pro Plan. Pro Plan has the following limitations:
- 15 million HTTP requests per month
- Maximum load limit of 40 requests per second
If you have 4,500 users, each of whom sends 125 HTTP requests to Parse.com per day, then you are already viewing 16,850,000 requests every 30 days. Parse.com also offers a higher level of service called Parse Enterprise. Details of this plan have not been published.
Secondly, the goal of Parse.com is to be an easy back-end back-end for mobile applications. I believe Parse.com is a very good mobile backend-as-a-service ( MBaaS - link to Forrester's article on this).
I am building a server 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 provide powerful data management tools. For example, the only way to delete a table is to click a button in the Parse Web Data Browser. Another example is that Parse sets the attribute type when the object is first saved. If the data type changes in an object, say, from a string to a pointer, Parse.com will refuse to save the object.
The cloud function programming model is built on Node.js. Comprehensive business logic will land quickly in the opposite hell because all database queries and save operations are asynchronous. That is, when you save or request an object, you pass the parameter "Parse" and say "when the download / request is completed, run this function." This may come in handy for LISP programmers, but not OO programmers who are using Java or .Net. Keep this in mind if you intend to write a Cloud Code for your application. My productivity took over when I started writing Cloud Functions.
The biggest problem I encounter at Parse.com is round-trip time. Here are some unofficial landmarks:
Getting one object through the REST API has a fairly consistent RTT of 800 ms.
ICMP is blocked, but just knocking on the door takes 400-800 ms, depending on the day.
Parse.com is located at the Amazon Information Center in Northern Virginia . I used Ookla Speedtest to evaluate my delay in this area. Reaching the server of the Richmond Business Center (75.103.15.244) in Ashburn gives me a ping time of 95ms. The server in DC gave me a ping time of 97 ms. Two hundred milliseconds of Internet overhead is not a problem.
The more requests or save operations performed by the Cloud function, the longer the response time. Cloud functions with one or two queries or save operations have an RTT of 1 to 3 seconds. Cloud functions with multiple queries and save operations have an RTT of 3 to 10 seconds.
HTTP requests sent to Parse.com timeout after 15 seconds. I have a cloud function that I use for testing, which removes all objects in the database. This cloud feature can delete a couple of hundred lines before time runs out. I turned Cloud Function into a cloud job because tasks can be completed within 15 minutes. The task deletes 400-500 objects and takes 30-60 seconds. Job status is only available through a web browser. I had to create an easy task status system so that other developers could request the status of their tasks.
The best use case for analysis is the iPhone developer, who wrote the game and needs to store user high scores, but knows nothing about servers. Use Parse where he is strong.