Introduction
Image may be NSFW.
Clik here to view.
Firstly if you haven’t heard about the British & Irish Lions App here’s what it is and what it does…This FREE Official App provides all of the fans with an ultimate British & Irish Lions experience; providing all of the build-up to the 2013 Tour to Hong Kong and Australia as well as all of the exclusive and behind the scenes news, tour information, up to date squad announcements and our video content.
Image may be NSFW.
Clik here to view.
This article will run through the background architecture that provides this app on both desktop and mobile devices across both Microsoft and non Microsoft devices.
Now let’s delve into the detail of how this was done…
Server Components
The following is a list of the server-side components used to support the Lions applications.
Umbraco CMS - An Umbraco instance is used to enter and store app content, including the application structure and all textual content. Images and videos are not stored in Umbraco, but in Azure blob storage (see 1.3.) The instance is hosted within an Azure Web Site instance.
WebAPI + Umbraco Data Service - Data from the CMS is served via a WebAPI layer, hosted within the same Azure Web Site instance as the Umbraco install. The WebAPI exposes a number of calls allowing the application to fetch data from the CMS if its cached data is out of date. The WebAPI itself performs no caching, it simply queries Umbraco to return data. The Umbraco Data Service uses uMapper to map document types to the POCO types which are then converted to JSON by the WebAPI to be served to the apps.
Lions Worker Role - The Lions Worker is an Azure Worker Role that performs the following periodic tasks:
1) Image Resizing - The Worker Role polls an Azure Storage queue located in the storage account. The file names of videos and images uploaded to Azure blob storage are placed in the queue for processing. When an item is dequeued, thumbnails are generated and stored along with the original image or video in blob storage.
2) Sotic Data Sync - The Worker Role also periodically pulls non-live data (that is data other than live match statistics) from Sotic JSON feeds, and forwards the data to the WebAPI via the DoSoticUpdate() call.
3) Sotic Live Data Sync - The Worker Role runs a thread every few seconds to poll Sotic live match data feeds. Rather than forwarding this data to the WebAPI, this JSON data is parsed and stored directly in the same SQL Azure database that hosts the umbraco instance in custom tables.
Front-End - The Front-End is a web role that brings together all application data, from both the WebAPI (for standard app content) and the custom SQL Azure tables (for live match statistics.) The Web Role performs no internal caching of standard application data, but CDN caching will be enabled in front of the Web Role to cache data to handle a greater volume of requests. The web role does cache live match data for a short period of time (a few seconds), but CDN caching is also enabled for live data.
Standard App Data Fetch Process
| Image may be NSFW. Clik here to view.  |
The application requests data from a well-known URL hard-coded into the app codebase. The URL points to the Front End web role via the Azure CDN. The majority of requests will be served from the Azure CDN cache. Any cache misses, or requests for expired data will be forwarded to the Front End, which in turn will forward them to the Web API. The WebAPI will then request the data from Umbraco, which will serve the data either from its XML cache or from the database if required.
Standard data requests are made via HTTP GET with parameters (node Ids etc.) included in the query string, which are eventually martialed into parameters by the Web API. All responses are in JSON format. The one exception to this is the submit call, which is made using this standard route, but is made via HTTP POST, with entry data submitted as JSON in the request body.
Image / Video Processing and Requesting
When images are uploaded, they are placed in Azure Blob storage. The file name of the image is then enqueued in a storage queue, from where it is picked up and processed by the worker role to create thumbnails. (see 1.3.) The URLs to these images are then stored in Umbraco and passed to the applications via the WebAPI so that apps can request images from blob storage via the Azure CDN. In the case of videos, an Azure Media Service is used to encode and store the files, and to deliver the videos to clients.
Sotic Data Sync
| Image may be NSFW. Clik here to view.  |
NOTE: The following does not apply to live match data
Sotic data is provided in the form of JSON feeds. The feeds are not parameterized, that is to say that we cannot request particular data by passing parameter to the feed URLS – rather the data for players (for example) is sent back in a large JSON blob which must be picked through to find the relevant data.
The following is an overview process of how Sotic data ends up on the client, using Player Stats as an example:
1) Document types in Umbraco have fields which correspond to the Sotic data – e.g. Players have fields for their caps, tries, yellow and red cards etc.
2) In addition, every Umbraco Node has three fields: Sotic Id, Sotic Update Interval and Last Sotic Update Time.
3) Periodically (currently every 5 minutes), a thread within the Lions Worker Role polls relevant JSON feeds from sotic and forwards the data on to the WebAPI, along with an Update Type flag to indicate what type of update is required.
4) The WebAPI receives the request and passes it to the Umbraco Data Service, which stores it in Umbraco.
Since the Sotic data is placed into the CMS, it is returned to the apps using the standard data fetch process described above just as any other data.
Live Match Stats
| Image may be NSFW. Clik here to view.  | |
Live match statistics will be handled separately by the server infrastructure to other Sotic data, because the data is updated far more frequently (every few seconds), and is likely to be required to deal with a greater number of concurrent requests. As such, a custom process for obtaining live match statistics will be put in place that will bypass Umbraco (which is not lightning-fast to update.)
The process is as follows:
- A thread within the Lions Worker Role will be responsible for polling live match data from SOTIC, parsing the JSON and placing the relevant results in a custom table in the database. The data will be keyed against the Sotic ID of the fixture to which the data pertains.(the same database that hosts the Umbraco instance.)
- The Front End has a controller which can be invoked by the apps to return live data. The Front-End will keep this data cached in memory, but should the data be missing from memory or out of date it will be refreshed from the database.
- The JSON responses of the front-end will be cached by the Azure CDN to handle higher numbers of concurrent requests.
Conclusion
If you would like to try out Windows Azure for free to create your own cross platform applications why not pop over to the Windows Azure website and take out the free trial. The official Lions app has over 120k downloads to date and with Windows Azure the system behind the app can scale as required. Let us know about how you use Windows Azure for app scaling!
Image may be NSFW.Clik here to view.