Introduction
Azure Functions provides integration out of the box with several Azure components such as Azure storage - Queues, Table and BLOBs, Event Hubs and has support for CRON timers. It also has an extensibility SDK, which allows many more providers of first and third-party service such as Cosmos DB, Twillio, SendGrid to integrate with Azure Functions as either triggers or bindings.
Having used Azure Redis Cache with Azure Functions in couple of projects, I missed the ease and code reduction and cleanliness that binding provides. So, I decided to use the extensibility SDK for Azure Functions v2 and build one myself and share it with community.
Caveat
At the time of writing this blog entry - April 2018, the Azure Functions v2 SDK is currently in beta and may encounter breaking changes. Not recommended for production yet.
Visual Studio Tooling
To be able to use the code successfully in Visual Studio, you must have Azure Functions and WebJobs Extension version 15.0.40405.0 or higher.
Code Repository
The code for this WebJobs Extension is available on GitHub
https://github.com/codepossible/WebJobs.Extensions.AzureRedis
Usage
Azure Redis Cache as Async Collector
The Async Collector is the most common use for most target bindings. In the case of Azure Redis Cache, that would be updating the cache - adding or updating existing keys.
The extensibility SDK provides a simple way to achieve this using interface. - IAsyncCollector, which requires implementation of two methods - AddAsync and FlushAsync.
The most common efficient of writing items to a store and cache being no exception is to write it in batches (or buffered writes).
The implementation of the Async collector can include an internal collection to support buffered writes, where AddAsync method would write to a internal collection and performed a buffered/batch update, once the item count reaches a certain limit (for example 100 items) or other event such as a timer. User can also perform a forced write as FlushAsync method.
In most cases for cache, values to be updated immediately.
So to simply things, I chose to create two constructs - interface called -IRedisCacheItem and a class called RedisCacheItemsBatch which is just a wrapper generic list of IRedisCacheItem instances. (The beta version of SDK support does not support nested collection for Async Collectors).
public interface IRedisCacheItem
{
RedisKey Key { get; set; }
RedisValue Value { get; set; }
}
{
RedisKey Key { get; set; }
RedisValue Value { get; set; }
}
public class RedisCacheItemsBatch
{
private List _items = new List();
public List Items
{
get { return _items; }
}
}
It is the RedisCacheItemsBatch class which is bound to Collector. An example signature of the Azure Function would be.
public static async Task Run(
[BlobTrigger("%SourceBlob%", Connection = "BlobStorageConnection")] Stream myBlob,
[AzureRedis] IAsyncCollector redisCache,
TraceWriter log
){ ...
[BlobTrigger("%SourceBlob%", Connection = "BlobStorageConnection")] Stream myBlob,
[AzureRedis] IAsyncCollector redisCache,
TraceWriter log
){ ...
In the sample code, the Azure Function is triggered by update to a CSV file stored in a BLOB storage, which is assumed to contain a comma-delimited key-value pair.
Azure Redis Cache as IDatabase
To use more richer native functionality to the Redis Cache, the extension also allows binding to an instance - StackExchange.Redis.IDatabase interface as the Redis Cache client.
Though not required, IRedisCacheItem can help simplify the code. The sample Azure Function code uses the IDatabase Binding to accomplish the same updates.
An example signature of the Azure Function would be.
public static async Task Run(
[BlobTrigger("%SourceBlob%", Connection = "BlobStorageConnection")] Stream myBlob,
[AzureRedis] IDatabase redisCache,
TraceWriter log
){ ...
[BlobTrigger("%SourceBlob%", Connection = "BlobStorageConnection")] Stream myBlob,
[AzureRedis] IDatabase redisCache,
TraceWriter log
){ ...
Azure Redis Cache Configuration
The Azure Redis Cache binding requires a connection string to the Azure Redis Cache instance to work. This can be specified inline in the function or enclosing the name of AppSettings key within the "%" signs.
If not specified, the code looks for a value for the Redis Cache connection string in AppSettings under the name of - "AzureWebJobsAzureRedisConnectionString"
Feedback and Sharing
If you find the code useful, please share it with your fellow developers, Twitter followers, Facebook groups, Google+ Circle and other social media networks.
Since this is built on a beta release of the SDK, updates and breaking changes are expected. If that happens, please raise an issue in the GitHub project - https://github.com/codepossible/WebJobs.Extensions.AzureRedis
Noteworthy
Another colleague of mine at Microsoft - Francisco Beltrao in Switzerland, has also written WebJobs Extensions which include one for Redis Cache. Do check out Francisco's work at https://github.com/fbeltrao/AzureFunctionExtensions
3 comments:
Thank you Tony. Please feel free send me any feedback on improvements or issues.
Please share with friends and colleagues. I would love hear about projects where this is used. (Production instances may have to wait).
I just updated the blog with the information on new VS Tooling for Azure Functions and WebJobs. The workaround in blog earlier no longer required after the upgrade.
The Azure Functions concept is awesome, I started to use it, and plan to make my next projects with it, instead of a more traditional ASP Net Core WebAPI Project. I hope the cold startup time of azure functions get faster.
I am having a little issue using Azure Key Vault on Azure Functions can you give a answer there:
https://stackoverflow.com/questions/49836145/how-to-use-azure-key-vault-from-azure-functions-v2
Tony:
Thank you for trying out - Azure Functions. The Azure Functions hosted under App Service Plan should not have the penalty of cold startup times, but obviously it comes at higher cost and beats the concept of the serverless.
I will look into the Stack overflow question.
Post a Comment