Azure / Azure/azure-functions-dotnet-worker
Conditional middleware - provide standard conditions OOTB
- Dominant language
- C#
- Stars
- 466
- Forks
- 215
- Avg merge
- 3d 10h
- Merged PRs (30d)
- 7
Description
[Conditional middleware](https://github.com/Azure/azure-functions-dotnet-worker/issues/855) is excellent.
What's not so great is the repetitive code to identify the standard types of triggers (HTTP, ServiceBus, StorageQueue, etc.) as every Functions user created the same code that doesn't need to be maintained.
The suggestion is to provide the standard triggers conditions OOTB to remove the need in the boilerplate code to identify trigger type to invoke middleware such as below:
```
.ConfigureFunctionsWorkerDefaults(workerApplication =>
{
workerApplication.UseWhen((context) =>
{
// We want to use this middleware only for http trigger invocations.
return context.FunctionDefinition.InputBindings.Values
.First(a => a.Type.EndsWith("Trigger")).Type == "httpTrigger";
});
})
```
Ideally, I'd like to see something that abstracts the boilerplate code and allows simple filtering in the following way.
```
.ConfigureFunctionsWorkerDefaults(builder =>
{
builder.UseWhen(Is.ServiceBusTrigger);
builder.UseWhen(Is.HttpTrigger);
builder.UseWhen(Is.EventGridTrigger);
}
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the linked conditional middleware issue and the UseWhen examples in this request. Trace how trigger types are currently identified through FunctionDefinition.InputBindings, then determine the scope of standard condition helpers and how they should be exposed. Done means the requested built-in trigger conditions are available for middleware filtering with coverage for the standard trigger types.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, csharp
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100