Cloud services for mobile developers: Google vs. Amazon vs. Azure vs. Parse

Cloud-based back ends for mobile applications combine key services with varying degrees of complexity

1 2 3 4 5 6 Page 3
Page 3 of 6

I'm not sure how this will go over with the brand managers who want to deploy concepts like "brand extension," but I liked using the mobile cloud with a simple HTML5 app. Microsoft did a great job opening this up to everyone, which means it'll be easy to use for projects that need to span the traditional Web, the legacy desktop machines, and the new world of mobile apps.

Not every part is so simple or accessible. The push services are mainly for Windows apps. It's simpler to build them with Visual Studio. These can be linked with Apple's and Google's cloud messaging systems too with a bit of work. The programming on the Azure server is done in JavaScript, and you merely insert a library to send a message to the right channel ID. The programming for the client, though, is trickier and more involved.

There are more parts to Azure Mobile Services, and Microsoft is continuously adding to the stack. Features like scheduling and scaling are listed as "previews," though they seemed to work. The scheduled job is a JavaScript function, while scaling changes the capacity level of the service tier.

The entire package shows what can be done with JavaScript. If you're comfortable with the language, you'll enjoy spinning up fairly complicated systems with a few functions and some inputs to the forms. It's quite easy to add simple business logic to funnel data in and out of the databases. If you don't like JavaScript -- well, it's not too hard to learn what you need for this.

I suspect that more ambitious projects will rapidly hit the limits of this system. If you think you'll need to rework a low-level call or add complicated logic, you'll probably start to encounter the restrictions of putting some JavaScript into a text field of a browser. But you can do quite a bit with what Microsoft provides here.

Google Mobile Backend Starter
Google offered one of the first app platforms sold as a metered service: App Engine. Now Google wants to be the mobile back end as well, and to do this, it has bundled together some of its existing cloud infrastructure. Google already had a storage engine with a REST API, an authentication system for your Google log-in, and a messaging system. Turning it into a cohesive mobile product wasn't hard.

The basics for a mobile app can be built with any of these parts. Google's collection of APIs is huge, and it's always been a good start for any app or desktop tool. It's easy to begin storing information in the Google cloud with just a bit of work.

The Mobile Backend is focused more on messaging, authentication, and continuous queries, the last being a tool for dealing with the endless stream of information from the hypersharing world. While the App Engine will accept code in PHP, Python, and Go, all of the examples for the Mobile Backend come as Java.

Digging into these tools was surprisingly onerous. After hours of downloading plug-ins for Eclipse, I couldn't get the libraries and the code into a magic alignment. A big part of the problem was the Google Play Services, the closed source pathway for more and more of what we think of as Google. There will always be debate about the right amount of openness, but I spent hours trying to get the library to install. Part of the problem was that the simulators now come in two flavors: Google and Android. Keep the difference straight because the code won't run on Android alone without Google Play Services.

Google App Engine Mobile Backend
Google's Mobile Backend API Explorer lets you test and debug your API calls.

The newer features are fascinating and a bit scary. Google wants to compete with some of the newer, seemingly continuous services like Twitter. If you write one of the new continuous queries, you can ask App Engine to search either the past, the future, or both. The searches of the future don't use a time machine; they just sit on the server waiting for new data to be stored. If the new information matches the query, it's pushed out to the client. The documentation notes there's a current limit of 10,000 clients who can be waiting. You won't be spinning up a project as big as Twitter right away, at least until Google deals with this limit.

1 2 3 4 5 6 Page 3
Page 3 of 6
How to choose a low-code development platform