Last week one of my colleagues had a question: Is there a performance penalty when you add multiple Azure Blob storage bindings in an Azure Function? Or is the connection only established when you access one of those blobs? Answering this grew into a way to have Dynamic output bindings in Azure Functions.
This post elaborates on [blog/using-triggers-bindings-in-azure-functions-v2](Using Triggers & Bindings in Azure Functions V2).
The idea was simple:
Create a Blob-triggered Azure Function.
Add two Azure Blob storage output bindings.
Have some logic determine which of the bindings to actually use.
The initial idea was that only the Blob that was actually accessed would be created. But since it’s default behavior for an output binding to expect the binding to be necessary, it is created as soon as the Function is executed. So the fact that both containers hold a blob with the same name is expected.
The details are in the Size column. Although both containers contain the blob, only one contains the contents. This matches the logic of the Function: based on some very complex logic, only one of the two Blob bindings is copied to.
To be able to actually have a dynamic binding, a binding that only creates a Blob when it is actually needed, we use the Binder class (the terribly complex SomeValue method was left unchanged ?) to dynamically bind against one of either Blobs.