In the progress of my last few “@Dvlup challenges, I had to employ a backend data provider to both store and sync data from my client applications as part of the requirements for those challenges. This gave me the opportunity to properly evaluate what the options were and who was offering the best services for my requirements.
So here’s the output of my research for the three big “out of the box” solutions out there.
 |  |  |
| Azure Mobile Services (WAMS) | Telerik Everlive Portal | Parse |
Requirements
For the basis of this review, I’ll set out my requirements that I wanted to satisfy. Everyone’s requirements are different and each platform has different ways to handle those, it’s up to you to pick the one that suits you best for each situation.
My baseline requirements were:
App1
- 3 Basic objects (
person, friend, data) - Data sync between client and server (offline data)
- Facebook, Twitter & Microsoft auth authentication
App2
- 2 Data objects, 1 basic (
person/user), 1 complex (GeoPosition data plus detail) - Push data (backup / notification only)
- Facebook authentication
SO for the purpose of the review, these were the kind of things I was looking for. There are various other scenarios for mobile devices / websites, if you have a specific case, drop me a comment and I can feedback based on my experiences to date.
Additionally, during the trial, the service should not incur any cost and have enough resources to complete at least the Beta. Preferably the running costs for the 1st year should be kept to the minimum.
High Level Comparison
Below is a base comparison of the three services based on their FREE tier:
| 
|  |  |
| Client OS Support |
Windows 8/WinRT
Windows Phone
iOS
Andriod
HTML / JS
Rest
|
.NET
Windows Phone
HTML / JS
|
.NET
Windows 8/WinRT
Windows Phone
iOS
Andriod
HTML/JS
Rest
Xamarin
|
| Auto Table creation |  | |  |
| Auto Column creation | | | |
| Supports complex datatypes | | | |
| Scripting support | | | |
| Request Limit* | 500,000 | N/A | 1 mil / 20 per second |
| Bandwidth limit* | N/A | 5Gb outgoing | N/A |
| Storage Limit* | 20Mb*** | 100mb db / 1GB files | 1Gb |
| Connection Limit | 100 devices** | N/A | N/A |
| Dashboard and Analytics | | | |
* limits unless specified are on a Per Month basis unless specified
** Limited to 100 devices activated on the service across all apps per month (devices inactive for 30 days are released)
*** The Azure db limit is for your account, you get just 1 20Db for all 10 WAMS apps you can register
The Story for App1
For the backend service in App 1, I needed to be able to register friend data and use the backend to keep track of those friends, I wanted as little hassle as possible keeping both the backend in sync and the client plus I only wanted each user to see the data they owned and data that their friends said they could see. Also to keep things efficient and not over create data, so there should only be one “connections” table between friends.
| WAMS alone would not surface the needs for my app but it has a very extensible custom API set using JavaScript which makes it very flexible. By using SQLite or other DB service, it would be easy to manage the requirements.
For an app where ALL clients would need to sync would not work even the trial in the FREE tier so the only option would be to pay due to the device and db limits.
|
| Again Everlive alone would not suffice BUT Telerik have released a beta of their cloud sync service which gives seamless data synchronicity between client and server.
The limits on the service cut it a little close to the bone but should be enough to begin with, although on-going running costs would mean a higher charge to clients.
|
| Parse with a local SQLite local db would suffice however with the lack of custom API support on the backend would make complex queries problematic or require multiple calls to serve data more than halving the request limit imposed on the service.
|
Conclusion
For App1, Telerik’s Everlive service paired with the new Cloud sync controls was a no brainer really. The service is still in its infancy but that gives the ability for any developer getting involved at the ground level to help to shape it for the future. It also provides the best “out of the box” experience and removes a lot of the complexities with resolving conflict issues on data.
The only downside is that because it is just getting started that there will be a few tricks to learn on the way which may put some beginners off.
The Story about App2
App2’s requirements are a lot simpler than App1, no synchronisation required for a start but it had more complex data to work with since it involved storing a lot of geo position data and detail behind it for reporting and tracking. The service would also have to support a rich backend website for a reporting dashboard (possibly also on tablets later).
| WAMS seemed to be the obvious choice here but the Facebook authentication on Azure mobile services is not great, users are always presented with a blank white screen on start-up which isn’t a great experience, using another FB authenticator and passing the “AccessToken” to WAMS just doesn’t work.
|
| Everlive would work but doesn’t currently support FB auth and didn’t want the hassle of two authentication systems to handle. Using the native SDK instead of the cloud sync works fine but is a bit of an overkill in this case.
|
| Parse’s basic nature lends itself to this kind of pattern for just having a basic data store plus it supports almost every platform under the sun with as many authentication patterns as you would like.
However, its lack of support for complex objects does create some challenges.
|
Conclusion
For App2’s use case where I just need to throw logging data at the server, Parse is an excellent fit. There are some things to take into account though. The complex types I was using had to be flattened to store them in my structure (I’ll blog more about my Parse use in another article) but putting it simple, it just worked and the methods for interacting with Parse are the easiest I’ve come across (their documentation is first rate also).
The Cutting Room Floor
In my investigations, I did also try a few other providers, some got a glance, some I tried my best to use but failed to do so.
The most notable of these was Buddy (This is Nokia’s preferred go to solution for backend data for apps and games), I call this out because as it stands the system is awful. The documentation is unwieldy and substandard and their API is so hard to use, it’s a wonder it’s used by anyone.
This really is a shame because they obviously have really geared up their backend to offer lots of services that are very useful, especially to game developers (great leaderboard and ranking systems, Messaging, Friends and achievements, they really offer a great deal).
But at the time of writing, I would not recommend anyone try implementing it at this time. This really is a shame considering Nokia’s backing and free tokens to use their services.
I will still keep an eye out and if I have time, work with them as I have done others to help get things moving.
Community Reaction to WAMS
I really tried to use Azure Mobile services for my solutions, it was in fact my platform of choice especially with their (now) per minute charging, fantastic range of capabilities and the extended API that is second to none.
However, myself and a lot of the community have been mulling over some of the forced limitations being placed on WAMS which makes it all but unusable in a Free bracket. In reality, it shouldn’t be called free, more rather Developer sandbox or Test / POC bracket. a 20MB database or all your services is plain daft (20MB per service might have helped better) and the 100 device limit is crazy. A maximum of 100 registered user devices are allowed to access your service each month which is made worse if you support multiple platforms and users have more than one device. Guessing Microsoft really want to just pay from the start for Azure which is fine but they just don’t say that. (the notices about MSDN access cannot be used for Live services further deepens the divide but I cannot complain with that view, MSDN isn’t meant for that.)
This approach is leading many away from WAMS (at least almost every dev I have talked to), here’s hoping that something comes back from the UserVoice requests regarding these issues, else Azure will be unapproachable to all but enterprise customers. Certainly no way to run a Free Apps/Service from Azure let alone an Ad Supported ecosystem.
Wrap Up
This post was just an overview of some of the things I’ve been up to while I’ve been quiet, expect a lot more over the next few days until I start delving again. 
Keep watching the skies.
