This is a story about simplicity and robustness, two terms that apparently don"t fit very well together in the same sentence while speaking of software development. And this was a reality back in the days when everybody was building their own backend solution, their own communication stack, their own language, their own … whatever. Cloud based platforms transformed this complicated world into a world where the most challenging matter is to have the right world and business understanding; technical stuff? - forget about it, it"s in the cloud, up and running, just use it.
This is how I recently rediscovered the beauty of the public clouds: being in the rush of preparing the next IT community conference in Iasi (it speaks for itself here: http://iasi.codecamp.ro/ ); and rush is like hell, it just blurs your mind. The event website (browser version) was ready, but in a world where you don"t exist unless you"re mobile, that"s a serious issue. Luckily enough, communities are made of smart people and, without us (the event organizers) even knowing, the native mobile CodeCamp applications were already in the app markets (Apple, Google, and Microsoft) - and are still there, go check them out. "That"s so cool" - we said; "but where are these apps getting the event data from (speakers, sessions, agenda and so on)"? We shortly found out that our friends - brilliant pPhone, Android, Windows Phone developers -, were using a static JSON file with a copy of the data posted on the event web site. Of course, apps and web site were constantly out of sync and the JSON file had to be updated on a daily basis to accommodate the web site changes. The agilists would probably say that this is an emergent architecture . And we decided we need to "emerge" more and build a proper backend for all those apps and the web site.
So we started to look around for a technical solution, having on top of our minds the following serious constraints:
That led us to the very obvious question: is there anything out there in the cloud kind enough to consider all the above and offer out of the box support? The answer is yes, nowadays there"s a quite good offering: Parse, Pusher, Azure Mobile Services and others. Azure Mobile Services was the way to go for us, given some previous experience with the Microsoft"s Cloud. Let"s see it at work.
Speaking of simplicity, I logged on into my Windows Azure portal (https://manage.windowsazure.com/ ) and it took me literally not more than 5 clicks and 1 minute to create a Windows Azure Mobile Service.
Very simply put (and the above picture will assist the explanations), the mobile service is just a bunch of relational tables in a SQL Server database, provisioned during service creation, accessible via HTTP RESTfull services to provide CRUD access to the data by the means of the POST (create), GET (read), PATCH (update), DELETE (delete) verbs and JSON payload. Having the aforementioned JSON structure already used by the mobile apps, it was very easy to define tables such as Events, Locations, Sessions, Speakers, Tracks - that was the place where my data was going to be stored and read from. Wanted to see all lines stored in my Events table? Just do a HTTP GET https://codecampevents.azure-mobile.net/tables/Events and you"ll get the data in JSON format. On top of this very simple data access model there"s security - each table operation can be accessed either in the presence of some secret keys (managed in the portal) or for authenticated users (microsoft, google, facebook, twitter identities supported aut of the box).
What if I want to programatically do my own processing when the HTTP request hits my service and not just do CRUD data storage? Take a look at the picture below, that"s where the Server Side scripts enter the scene. The HTTP request hits Layer 1, built into the Mobile Service - this is where the HTTP request and JSON payload are interpreted, mapped into Java Script object and passed to the Scripting Layer, which is in your hands. Java Script? Oh, yes - the scripts run on top Node JS which is hosted somewhere into the platform. There"s simple API out of the box for accesing databases, calling other HTTP web services, sending push notifications to iOS, Android, Windows Phone and Windows 8 devices, accesing Azure Service Bus and others. After you do your stuff the execution control goes to Layer 2 where the java script objects are mapped onto database fields.
The picture below presents the interaction between the mobiles apps, the backend and me sending push notifications to all registered devices.
Each operation has a pretty straigthtforward corresponding Server Script written in Java Script. The rest was some simple identity and push notification related configuration in the portal. Would you believe me saying that I"ve done all that stuff in just a couple of days (well, give or take a few extra hours for some mind-twisting Java Script bugs )? And that"s not me being a genius, it"s just the simplicity of Azure Mobile Services.
I"ll leave you with some food for though: is what we"ve seen so far enough for a robust and ready to production service? How about monitoring & logging; scalability; scheduled tasks? It"s already there, try it out! http://www.windowsazure.com/en-us/develop/mobile/
by Ovidiu Mățan
