I’ve been working with Azure Mobile Services since last year. At first I thought it was just a back-end service, where I could store data from mobile devices, but it actually goes much further than that and this is what I would like to tell you to start the week.

If you’re already using Microsoft Azure platform, you may have noticed that many of the services are supported between them. For example, Azure Media Services uses Azure Storage to store assets, Azure Notification Hubs uses Azure Service Bus for sending notifications, and so on. Azure Mobile Services is a linked service to all those that facilitate: the hosting for Apis (on Azure Websites), data storage (Azure SQL Database by default), notifications to users (Azure Notification Hubs ) and identity management (Access Control). Initially Node.js appeared as backend, but now we can work with .NET, relying on ASP.NET Web APIs for the creation of Apis.

Getting Started

If you’re a .NET developer, the easiest way to start working with the service is through Visual Studio. When you select the New Project … option you can see a project called Azure Mobile Service in the Cloud section.

After choosing a name and location, a new window appears where the ASP.NET Web Api option is selected by default. This window also allows us to link the new project with a Mobile Services account on your Microsoft Azure account.

If you select the «Hosted in the cloud» checkbox, it automatically asks for information in order to create the new account.

While the account in the cloud is provisioning in the background, we can see in the Solution Explorer window the typical structure of an ASP.NET Web API  application with sample code.

• TodoItemController: your first controller which works with Azure Mobile Services. In it there are some differences for us: First, this class is not inherited from ApiController but TableController <>, where the entity on which it operates is specified. This base class belongs to Azure Mobile Services, which gives us a set of standard operations on the data storage and DomainManager class which is used to inject what is the source of data we want to work with (It uses EntityFramework SQL Azure Database by default).
• TodoItem: in the sample code is the class on which the previous controller is based. It is inherited from EntityData because EntityFramework is used to access the database.
• Microsoft.ServiceBus.MessagingPerformanceCounters.man: A number of counters are generated by default for Notification Hubs that may be useful to us, for example: the number of messages sent successfully and not, latency and so on.
• SampleJob: Azure Mobile Services is supported on Azure Websites, so we can make use of WebJobs.
• Services property: To make use of all the services that are linked together, we have a property called Services which allows us to log events, trigger notifications, and so on.

We can run the project locally and get a screen like this:

If we click on try it out we can see the methods exposed in TodoItemController and our SampleJob. We can use any program like Fiddler, Postman, Paw, among others without creating a client.

After making your tests, the last step is to publish. To do this, simply go back to Visual Studio and select the Publish … option on the project.

If you paired your solution with an account of Azure Mobile Services in the first step, the configuration would be completed from the beginning, so we just have to click the Publish button to deploy it. When the process is complete the browser launches with the same page that we saw in the previous step, although in this case we need to use credentials to access the test page. The credentials are a blank username and  the APPLICATION KEY is used as a password, for which we have to access the portal, select the service account and click on MANAGE KEYS.

With this post you have a basic understanding about getting started with Azure Mobile Services.

Cheers!