The system should scale reasonably well, but it's easy to see how some complex tasks might fail. According to the documentation, the basic functions are "killed after 15 seconds of wall clock time." Functions that run before and after saves to the database only get three seconds to live. I can understand why the developers chose what sound like arbitrary limits. It's the simplest way to maintain boundaries between so many apps living together on a shared box. But it sure makes complex systems less predictable when resources become tight.
It's hard to know whether you can take much of your Parse code with you if you decide to move to your own servers. Of course if you're building a lightweight app that doesn't store too much, you'll be fine. If it's all simple tables, you can be up and running in little time.
Pick a PaaS for mobile
Figuring out the right way to use the cloud to support mobile apps is now a key part of the development process. All four clouds offer solid solutions for squirreling away data in case someone's kid drops the phone.
There are other solutions of course. While researching this story, I was building an application that needed cloud storage. For my mobile back end, I ended up installing Drupal on a spare server. It was neither as clean or as organized as Microsoft's back end, nor as well documented as Parse's, but it wasn't hard to get something running that would handle the data I was sending its way. All it takes is a module that adds JSON Web services to Drupal. The best part: It also came with all of the display code for browsing the data and presenting it in a nice way. There are hundreds of themes for Drupal, so creating a nice look isn't too hard.
My traditional Web stack can't push notifications, but I'm not sure they're necessary for many applications. It's much simpler to ask the client to poll the server periodically. It may not be as interactive or as instantaneous, but it's simpler than jumping through the hoops the different push systems require.
It's not always as easy to scale code like Drupal either, but it can be simpler and more flexible. Google's App Engine stack, for instance, isn't particularly portable. If you decide you don't like Google's cloud, you'll need to do quite a bit of coding. Microsoft's Node.js code is probably the simplest to move if needed.
In the end, all the APIs offer a substantial boost for anyone building a basic database-backed server, which is the bulk of the job for mobile code. The job of pushing data to the users, though, is still a work in progress. The code was messy and the APIs complex. Much of it is still experimental. It's not simple to create something that will push bits to millions of clients, even using these tools.
Mobile back end services at a glance
|Amazon Web Services||Google Mobile Backend||Microsoft Windows Azure Mobile Services||Parse|
This article, "Cloud services for mobile developers: Google vs. Amazon vs. Azure vs. Parse," was originally published at InfoWorld.com. Follow the latest developments in cloud computing and application development at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
Hot or not? From the web to the motherboard to the training ground, get the scoop on what's in and...
Confidence in our power over machines also makes us guilty of hoping to bend reality to our code
Sponsored by Cisco DevNet
Sponsored by Hewlett Packard Enterprise
Microsoft says its new Azure cloud database is all types of databases in one. Here's why that might be...
Edge computing will not replace cloud computing, though the two approaches can complement each other ...
The Rust-like open source language tackles application development where asynchrony leads to...
The popular code repository is trying to be a one-stop shop for developers to get more of their work...