This post is part of a series
In a previous post, I shared how you can deploy a Serverless Request Bin using Azure Functions. I also shared how I built it using a memory cache as a persistence layer. With that approach, I was able to leverage the new constructor Depending Injection capabilities of Azure Functions that allowed me to use a memory cache across multiple functions. However, the main limitation of that particular method was lack of control of the state lifecycle. I could try to keep the Function App in memory with a timer-triggered function, however, the platform can change the hosting instance at any given time, which would result in the unpredictable loss of the in-memory state.
In this post, I will show how I leveraged a new feature, currently in preview, of Azure Durable Functions called Durable Entities. These allow me to make my Serverless Request Bin stateful. With this approach, now I can have full control of the lifecycle of the bins.
As with the previous post, this solution’s code is available on GitHub. However, please consider this a sample solution for personal use. Compared to the previous solution, this time, I used Durable Entities to persist the state of the bins. I kept the rendering to HTML on the Serverless side with DotLiquid templates.
The Function App is composed of three HTTP-triggered functions described as follows:
Additionally, I introduced a new Durable Entity called RequestBin.cs
shown below. As you can see, with very few lines of code, I was able to have a simple and intuitive persistence layer. Durable Entities are persisted in Azure Storage behind the scenes, but all of that is abstracted from us.
During my refactoring to change the persistence layer from an in-memory cache to Durable Entities, I learned some characteristics of Durable Entities:
The Serverless Request Bin that I showed in my previous post, provides some benefits, including:
In addition to the above, with the Stateful Serverless Request Bin, we now also get:
You need an Azure Subscription and access to deploy resources (contributor role) in a resource group. Similar to the previous version, deploying your own instance of the Stateful Serverless Request Bin is very easy. You just need to click on the button below, and this will take you to a page similar to the one shown after.
At the time of writing, the deploy button option does not allow you to choose the region for a new resource group. Therefore, if you are planning your deployment in a new resource group, it is highly recommended to create the resource group in advance, so you can choose the region for it.
Please read the following section to understand the purpose of each of the settings.
The configuration options and settings of the Stateful Serverless Request Bin are described in the table below. Some of these options are available only at deployment time, while others are also available after deployment as Application Settings of the Function App created.
Setting |
Description |
Can it be updated after deployment? |
Directory |
Azure Active Directory Tenant that you want to use to deploy the solution |
No |
Subscription |
Azure subscription in which you want to deploy the solution |
No |
App Name |
Used to name the different components of the Serverless Request Bin; including the Function App, the consumption plan, Application Insights, and the Azure Storage account. |
No |
App Insights Region |
Defines the App Insights region (Given that Application Insights is not available in all regions, choose the closest region to the resource group). |
No |
Request Bin Renderer |
App Setting to configure the Request Bin Renderer to return the Request Bin history to the user. Currently, only |
Yes |
Request Bin Renderer Template |
Filename of the Liquid template to use while rendering the request bin history. Currently, only the |
Yes |
Request Bin Max Size |
The maximum number of requests to store in the Request Bin. |
Yes |
Request Body Max Length |
The maximum number of characters to read and store from the request body. If a request body is larger than this limit, the body will be truncated. |
Yes |
Headers to Ignore |
Azure Functions add some headers to HTTP requests. If you prefer a cleaner request bin, you can ignore the specified HTTP headers. Specify the headers to ignore as a pipe-delimited list. |
Yes |
Using the Stateful Serverless Request Bin is very easy. The usage operations are the same as the previous version. Once you have successfully deployed the Stateful Serverless Request Bin, you can use in the following:
https://<yourfunctionapp>.azurewebsites.net/<binId>
POST https://<yourfunctionapp>.azurewebsites.net/1234567890?a=1&b=2
GET
call including the Bin identifier to https://<yourfunctionapp>.azurewebsites.net/history/<binId>
GET https://<yourfunctionapp>.azurewebsites.net/history/1234567890
DELETE
request tohttps://<yourfunctionapp>.azurewebsites.net/history/<binId>
DELETE
https://<yourfunctionapp>.azurewebsites.net/history/1234567890
Throughout this post and the companion sample code, I’ve shown how you can deploy and configure your own Stateful Serverless Request Bin. I also shared how I built it, leveraging Durable Entities. Feel free to use it for your own development tasks. I hope you found it useful, either as a HTTP request inspector or as sample code. Please feel free to raise issues or contribute by submitting your pull requests on GitHub! :)
Happy coding!
Cross-posted on Paco’s Blog
Follow Paco on @pacodelacruz