Azure Mobile Services: lessons learned
Posted
by svdoever
on ASP.net Weblogs
See other posts from ASP.net Weblogs
or by svdoever
Published on Fri, 28 Jun 2013 00:04:54 GMT
Indexed on
2013/07/01
10:22 UTC
Read the original article
Hit count: 365
When I first started using Azure Mobile Services I thought of it as a nice way to:
- authenticate my users - login using Twitter, Google, Facebook, Windows Live
- create tables, and use the client code to create the columns in the table because that is not possible in the Azure Mobile Services UI
- run some Javascript code on the table crud actions (Insert, Update, Delete, Read)
- schedule a Javascript to run any 15 or more minutes
I had no idea of the magic that was happening inside…
- where is the data stored? Is it a kind of big table, are relationships between tables possible?
- those Javascripts on the table crud actions, is that interpreted, what is that exactly?
After working for some time with Azure Mobile Services I became a lot wiser:
- Those tables are just normal tables in an Azure SQL Server 2012
- Creating the table columns through client code sucks, at least from my Javascript code, because the columns are deducted from the sent JSON data, and a datetime field is sent as string in JSON, so a string type column is created instead of a datetime column
- You can connect with SQL Management Studio to the Azure SQL Server, and although you can’t manage your columns through the SQL Management Studio UI, it is possible to just run SQL scripts to drop and create tables and indices
- When you create a table through SQL script, add the table with the same name in the Azure Mobile Services UI to hook it up and be able to access the table through the provided abstraction layer
- You can also go to the SQL Database through the Azure Mobile Services UI, and from there get in a web based SQL management studio where you can create columns and manage your data
- The table crud scripts and the scheduler scripts are full blown node.js scripts, introducing a lot of power with great performance
- The web based script editor is really powerful, I do most of my editing currently in the editor which has syntax highlighting and code completing. While editing the code JsHint is used for script validation.
- The documentation on Azure Mobile Services is… suboptimal. It is such a pity that there is no way to comment on it so the community could fill in the missing holes, like which node modules are already loaded, and which modules are available on Azure Mobile Services.
Soon I was hacking away on Azure Mobile Services, creating my own database tables through script, and abusing the read script of an empty table named query to implement my own set of “services”.
The latest updates to Azure Mobile Services described in the following posts added some great new features like creating web API’s, use shared code from your scripts, command line tools for managing Azure Mobile Services (upload and download scripts for example), support for node modules and git support:
- http://weblogs.asp.net/scottgu/archive/2013/06/14/windows-azure-major-updates-for-mobile-backend-development.aspx
- http://blogs.msdn.com/b/carlosfigueira/archive/2013/06/14/custom-apis-in-azure-mobile-services.aspx
- http://blogs.msdn.com/b/carlosfigueira/archive/2013/06/19/custom-api-in-azure-mobile-services-client-sdks.aspx
In the mean time I rewrote all my “service-like” table scripts to API scripts, which works like a breeze.
Bad thing with the current state of Azure Mobile Services is that the git support is not working if you are a co-administrator of your Azure subscription, and not and administrator (as in my case). Another bad thing is that Cross Origin Request Sharing (CORS) is not supported for the API yet, so no go yet from the browser client for API’s, which is my case. See http://social.msdn.microsoft.com/Forums/windowsazure/en-US/2b79c5ea-d187-4c2b-823a-3f3e0559829d/known-limitations-for-source-control-and-custom-api-features for more on these and other limitations.
In his talk at Build 2013 Josh Twist showed that there is a work-around for accessing shared script code from the table scripts as well (another limitation mentioned in the post above). I could not find that code in the Votabl2 code example from the presentation at https://github.com/joshtwist/votabl2, but we can grab it from the presentation when it comes online on Channel9.
By the way: you can always express your needs and ideas at http://mobileservices.uservoice.com, that’s the place they are listening to (I hope!).
© ASP.net Weblogs or respective owner