Data-Driven iOS Development with ReactiveCocoa
iOS MacEditor’s note: This post was co-authored by Howard Vining and Matt Mathias.
Microsoft Azure, a cloud storage and computing platform, is a one-stop shop for virtual machine hosting, web hosting, machine learning analysis, web-enabled databases, content delivery and more.
Azure offers specialized services like API Management, which can act as a proxy that limits how often a developer can hit his or her APIs within a given time frame. You can push notifications to various mobile platforms using Notification Hubs. And if you are looking for a lightweight data store, then the Azure Redis Cache may be of interest. To that extent, Azure Mobile Services is a piece of the larger puzzle that enables devices of various platforms to take advantage of a core cloud-powered service. It is a RESTful data service that can be written in JavaScript (Node.js) or C#/VB.NET. As a data service, it’s backed by SQL Azure as the default, but there are options for MongoDB and Azure Table.
In this entry, I will introduce features of Azure Mobile Services from the JavaScript perspective. You can access Azure here, which requires a Windows Live account. Once a new service is created, you will begin at the quick start page, which contains all the platforms Azure Mobile Service supports with client SDKs.
To date, those platforms are:
The SDKs are open source and live here. Now let’s take a look at some of the features of Azure Mobile Services.
Under the Data tab, we are able to create entities in the data store that will back this mobile service. As stated before, by default Azure Mobile Service uses Azure SQL Database for storage.
When creating the table, you have the option to apply permissions to the CRUD (create, read, update, delete) operations on that table. These options are:
Upon creating a new table, four columns are created automatically; id, __createdDate, __modifiedDate and __version. The id column is a String data type (nvarchar(MAX)) that acts as the primary key of the record, and as such it is automatically indexed. This value is automatically assigned a GUID when new records are added to the table. __createdAt and __updatedAt are straightforward. __version is a read-only timestamp column that changes upon each modification of the record. It is used during conditional requests as the Etag header. This helps in determining if a record is modified, thus removing the chance of updating a record with old or stale data.
One of the more powerful aspects of Azure Mobile Services is the use of table scripts, which act very similarly to table triggers. On any of the actions that permissions are applied, we can establish side effects that invoke validation, business logic, relationship management, auditing/logging, etc.
Each script takes in three arguments: request, user and item. The request is the structure that contains the headers and body content (using request.js). The user is a representation of the current logged-in user through an identity provider who sent the request. If no user is logged in, the level property holds a value of anonymous
. Item is the object (JSON representation of the entry) that the action is applied to.
You are capable of creating arbitrary APIs without needing to interact with a table. You can create a “listener” for the following HTTP methods:
Each HTTP method can have a permission applied to it (same model as table actions). In an API, you have access to the request and response objects. In a sense, an API allows the same amount of functionality as the table scripts. You are also capable of passing in parameters to the API for GET methods. The parameters reside in the request.query
object, while the other HTTP method parameters appear in the request.body
object.
Similar to table scripts and APIs, Mobile Services provides scheduled tasks that can be invoked at an interval per minute, hour, day, month or only on demand. The Scheduler is great for nightly jobs, tasks, clean-up processes or data gathering.
Besides data storage and access, Azure Mobiles Services also provides the ability to send Push Notifications to supported platforms: Windows Store Apps, Windows Phone, iOS and Android. With the following functions, your mobile service can send small messages globally or to individual devices.
I mentioned earlier that table script permissions can determine if an action can be invoked, depending upon whether an authenticated user invokes it. This is possible because Azure Mobile Services allows users to authenticate through identity providers like Facebook, Google, Windows Live or Windows Active Directory. Mobile Services tries to simplify this process by providing a one-stop area for maintaining your OAuth credentials. An example of this is the ability to add scopes to the App Settings in the Configure area:
As we have seen, you can create new tables and new columns that have a predefined set of trigger-like scripts. In addition, arbitrary APIs can be created to provide additional operation. But this only the tip of the Azure Mobile Services iceberg. There are other neat offerings available, like Git publishing, custom authentication, SignalR and Service Bus integration, along with support for third-party services like Twilio, Pusher and SendGrid. If you would like to learn more about how to get started with Azure Mobile Services, check out Azure Mobile Services’ Getting Started Content and their Mobile blog posts.
Editor’s note: This post was co-authored by Howard Vining and Matt Mathias.