.NET, code, personal thoughts
Why Event Sourcing?
Manually Completing Service Bus Messages with Functions
Message settlement with Azure Service Bus has undergone some changes over the past few iterations of the Service Bus SDK for .NET. In the latest SDK (Azure.Messaging.ServiceBus), the settlement is performed via the
ServiceBusReceivedMessage. In the previous SDK, this was accomplished with the help of the
Updating Azure Functions Tools
Azure Functions Tools is at the heart of providing local development for Azure Function. Whenever you use Visual Studio, Rider, VS Code, or anything else, you need it to be able to run your bits. For command line folks, the installation process is outlined in the tools repository. For Visual Studio (2022) and Rider, it is less evident as it depends on the tool. So, where am I heading with this? Right, the need to update the Azure Functions Tools.
Fixing NServiceBus default databus serializer in .NET 6
Upgrading to .NET 6, updating all the packages, boosters turned on, launching testing.
Sagas with Azure Service Bus
Handling messages out of order is always tricky. The asynchronous nature of messaging makes it challenging. On top of that, systems in the real world are messy and unpredictable. That's why handling workflows always brings more complexity than just handling messages. To illustrate the challenge, I'll use a scenario where my workflow depends on two different services.
Executing Azure Timer function manually
Service Bus Message to Blob
About 5+ years ago I blogged about turning messages into audit blobs. Back then, it was for Storage Queue messages and the early Azure Functions implementation that required portal configuration. Since then, Storage Queues has been replaced by Azure Service Bus and Azure Functions has gained the ability to declare everything through the code. And not only that but also in two different ways, using
Azure Functions Isolated Worker - Sending multiple messages
Azure Functions Elevated
A recent talk I gave online at ServerlessDays Amsterdam