Support imperative runtime binding

[richardweaver]

Investigative information

I am trying to write a generic HTTP webhook that determines the queue to put the payload into based on some piece of data within the payload, that can only be determined at runtime. As per the binding documentation this imperative binding is only possible on .NET runtimes. This feels like a siginificant omission from the new Node.js programming model.

Repro steps

Create a function with a storageQueue output binding. The queue name must be hardcoded and cannot be altered at runtime.

const queueOutput = output.storageQueue({
  connection: 'AzureWebJobsStorage',
  queueName: 'hardcoded',
});

export async function httpFunction(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {
  // ...
    queueOutput.queueName = queueName;
    context.extraOutputs.set(queueOutput, payload);
  // ...
}

Expected behavior

I should be able to override queueName within the function handler body as per the above. Alternatively, it could be specified as an output binding (queueName: '{queueName}') and then a runtime output object provided as a parameter to extraOutputs.set().

Actual behavior

Setting the queueName property as per the above does not cause an error, but is ignored and the payload created on the hardcoded queue.

Known workarounds

I am currently having to define an array of storageQueue objects, specify each of them in the extraOutputs array, and then determine which to actually populate at runtime. As the list of possible queues grows, this is becoming unwieldy.

Alternatively, I could create a separate http trigger function for each queue, but this involves a large amount of boilerplate.

[ejizba]

@richardweaver sorry for the delayed response. If you want full dynamic ability to change things like queueName, our recommendation would be to use the @azure/storage-queue azure sdk npm package instead of an output binding. In general we have a lot of internal debates about output bindings vs azure sdks. If you have thoughts on why you prefer output bindings and want to use them here - please let us know

[sethtjf]

Personally, I like not having to download and configure another SDK compared to the bindings just working. I'd like to be able to use binding params computed at runtime. If this was supported for blobs it would have saved me several hours today.