Attribute-based mechanism to hook before and after the trigger

[xin9le]

Summary

In #1811, I created a Pull-Request for the application of middleware using attributes. Here, I will explain the background of creating the Pull-Request and lay the groundwork for discussing the features necessary to meet the requirements.

The features needed

I would like a mechanism to hook before and after a specific trigger. For example, I would like to do the following.

• Authenticate API keys at the time of executing HTTP requests
• Embed logs before and after the process
• Load cache and/or customer data (etc.) before executing the trigger

While this feature can currently be realized using the .UseWhen<TMiddleware>() method, this method only allows filtering by specifying the function name as a string. The implementation to apply the middleware and the function to be applied need to be written in separate files, which presents challenges in terms of maintainability. Therefore, by applying a "declarative approach like the ActionFilterAttribute provided in ASP.NET Core", I believe we can achieve both maintainability and convenience. Currently, Azure Functions does not have a filter feature like ASP.NET Core, so I created PR #1811 as a substitute using middleware feature. Please refer to #1811 for how to use it and what it feels like.

Points to discuss

The following comment was made regarding PR #1811.

1. There are concerns about the reflection approach being used to find the target function (@fabiocav)
2. Using attributes to apply middleware is not preferable as it can cause confusion (@kshyju)
3. The concept of ActionFilterAttribute might be good (@kshyju)

Given the above exchanges, I would appreciate it if we could discuss the following.

• The pros and cons of using attributes for a declarative approach
• Whether it's less confusing to make middleware applicable with attributes, or to add a new filter feature (similar to middleware, like ASP.NET Core)

[fabiocav]

The key concern about the approach is the assembly enumeration over the AppDomain, as it will be problematic with multiple contexts and it's also sensitive to the state of the application at the time enumeration takes place, so that's not an approach we'd be able to use.

While the above is addressable, we also have concerns about the expansion of the surface area at this point with competing features.

The proposed feature may indeed cause some confusion for developers coming from an ASP.NET background. Filters are currently a WebJobs feature and something we've discussed bringing to the worker, so we'd also need to understand how those would combine.

For this to come in as a new feature, this would also require a thorough set of tests, documentation and samples, and at the moment, we're driving a large set of features that will compete with this in priority. We'd also need to validate the need for such a feature.

Would you be open to releasing that as a separate NuGet package? This is something that can be done with no changes to the current runtime/SDK, and we can discuss anything that might be needed to enable the integration.

[fabiocav]

I'll close the PR based on what I've shared above. But we can continue the discussion here.