The dilemma
I like writing code. If I had unlimited time and resources, I’d start each project in an empty
window of my favorite text editor (Programmer’s Notepad) and peck out every line of code, soup to nuts. On even the most trivial mobile apps these days that usually means the app itself, a support website, and some kind
of REST backend.
If you’re lucky, that backend piece is something that can
exist in a shared hosting environment alongside your website — maybe a LAMP
stack that runs you several bucks a month. Chances are, if you’ve been writing mobile apps for awhile, you’ve already
had the opportunity to cut your teeth on the server-side tech, say maybe PHP
and MySQL. And yet even when all
the pieces fall into place and the winds of good fortune smile upon me, I find
it’s tough to crank out apps with any real velocity when
I’m flying the entire project solo.
Take my latest title, which I released for Kindle Fire last week. Not only does it require I keep up with
user logins, high scores, and player statistics, but it has a social aspect
that allows users to play turn-based games against their friends. I implemented the first pass
at the backend myself, but I was spending so much time on that side of the house that I
couldn’t concentrate on the actual game.
After a lot of stalling, I began to explore the Platform as a Service (PaaS) options targeted at mobile developers; some of the PaaS options are for mobile development in general, while others target a
specific vertical like gaming. All of the platforms I looked at
had things I liked and things I didn’t like, but I chose Parse because it best fit
this particular project, and because the pricing model allowed me to ramp up
gradually as my user base increases.
On my previous two projects, I wrote the backend from
scratch. Let’s look at how using Parse compared.
Pros
- It didn’t cost me one cent to get started. Parse allows up to one million API
requests per month before billing kicks in. (This wasn’t necessarily
unique to Parse; most of the
PaaS offerings I explored had a minimum level of service before you had to get out your credit card.) - Getting started was faster. I didn’t have to set up MySQL
permissions, upgrade my version of PHP, or any of those other tedious tasks
that are often associated with shared hosting. - Simple CRUD operations were a dream.
- The REST API was straight-forward and easy to
use. - Handling push notifications to the end-user
devices was greatly simplified.
Cons
- I am locked into Parse. Its API is specific to the platform, and if I decided to move my backend, or worse yet, Parse
flipped the off switch on all its servers, I would be out of
business for weeks while I scrambled to find a new provider. - Relational queries are a little harder to
implement, as a PaaS platform must abstract you from the underlying
database. - Creating triggers on the server side was more
challenging. I pushed a lot of logic down to the
mobile device that I probably would have handled on the server if I had direct
access to it. - I couldn’t find a way to make database writes
truly atomic. I had to
take additional steps at the client to insure data synchronization. - Push notifications on Android were implemented
using a custom service rather than Google Cloud Messaging (GCM). This means you must add the Parse
service to all your Android and Kindle applications to get notifications to
run.
Conclusion
I feel like using a PaaS platform was the
right call for my latest project; I estimate that offloading the task of the backend onto the PaaS platform got me to market three to six months earlier. I admit, however, that it was hard to give up control, and it required me to make compromises.
Since
the turnover of mobile games is high, I will likely
continue to leverage services like Parse. I believe these services will only get better and more competitive over
time.
Share your thoughts
Have you moved
away from or are you thinking about moving away from a custom backend for your Android apps? If so, do you have experience with one or more PaaS options? Let us know in the discussion.