Do we need to formalize YARP extensions?

[samsp-msft]

What should we add or change to make your life better?

Today we look at YARP extensions through the lens of middleware, but usually from the perspective of the middleware being developed by the proxy author. Is there a scenario where we have libraries of extensions to YARP that are consumed by the proxy author, but they are supplied as pre-built libraries?

What changes in this model that we need to think about?

• They should be listed in the middleware pipeline like the built-in YARP modules. They should not need to have any explicit parameter passing.
  • Even better would be is if they could self-register as going in a specific position in the pipeline relative to YARP stages. Eg have an enum with before/after for each built-in stage. If the user doesn't customize the pipleline, then they would be called based on their default position. If the user has multiple extensions and the order becomes critical, then they can explicitly specify the order.
• Controlled through config - as part of the Routes, Clusters.
  • Do we need to have extensibility of the reverse proxy node itself, or should the extension just use its own root node in the config file?
• Ideally the only code required by the consuming developer would be to register the extension during the startup class, as part of the services.AddReverseProxy() chain.

@Tratcher, @davidfowl

[davidfowl]

A good example will be rate limiting, imagine that was built an an extension. What would that look like? (config, code etc)