An Introduction to Microsoft Azure Mobile Services
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.
To date, those platforms are:
- Windows Store Apps
- Windows Phone 8/8.1
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:
- Anybody with the Application Key: Allows anyone who makes a request to the service with an application key to perform the respective action.
- Only Authenticated Users: An action is available only to clients with a user who has completed the authentication process for one of the identity providers.
- Only Scripts and Admins: The highest restriction. Allows only other scripts or admin users to invoke the action.
- Everyone: Least strict, as it implies. Any client can perform the action with this permission.
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
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.
- “push.wns” (Windows 8)
- “push.apns” (Apple)
- “push.gcm” (Android)
- “push.mpns” (Windows Phone)
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:
The Tip of the Iceberg
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.