Parse and/or Backend-as-a-Service

09 Jul 2012

So I recently wrote a response of our findings with Parse over at YCombinator News. Here it is, since it might be handy and will rapidly cease being available as the thread drops off. So here it is:

Will [Parse] change how the entire app industry works? Not really. Will it make life easier for some developers? Probably. Having used Parse in the past and ultimately dropped it for a custom backend, let's take a look at where Parse fits really well:

1) You're a one-off or small dev shop with no web experience, and making a basic data store with a JSON API as a backend is beyond your technical means (this is by far the best use).

2) Your data isn't that complex (stuff like high scores and the like), so the fact that this is just a big Key/Value store won't harm your performance much.

3) You also don't need any server-side intelligence, just a data store an an API.

4) Your growth and revenue model is in line with the pricing model of the service you selected.

Now here's the things I struggle with, and why where I work when we develop mobile apps, we stay away from Parse/Stackmob/Kinvey/Appcelerator ACS/Whoever. These apply to our customers / projects, and may not be the same for you.

1) We almost always want our server to be intelligent, not just an API-wrapped database. When I want to trigger push notifications, I want to do it with server-side logic, not everything running in the app. Our big beefy AWS servers are way more capable than someone's 2-year-old free Smartphone.

2) It doesn't take long for monthly fees to outpace the cost of just having your own server, or eat into your profitability. Most of these services work out to about 3-5 cents per user per month. Depending on the size and complexity of the app, and what the revenue generated from it looks like, that can be vastly more expensive than a small AWS or Heroku deployment.

3) It's rare that we need a data store as simple as "users + key/value". It's one thing to build a basic chat app or worldwide high score in a system like that. It's another to try and build an inventory tool or CRM.

4) Mobile data connectivity is high-latency and unreliable. Making a dozen API calls to populate a single screen is not only inefficient, it can be very frustrating to your users. An API call for a screen/view/fragment should return exactly the data needed, no more, no less. Let the database do what databases do best: sort and collect data. Let the phone just display it.

So really, for small apps or apps with relatively simple data requirements, Parse does a fine job, especially if you don't have server people on your team (in which case, BaaS is your only real option). If the app's data is going to be complex, require server-side logic or have any kind of complexity that would involve optimized API calls? You're probably better building your own.