Add register_middleware hook

[davidbrochart]

No description provided.

[adriendelsalle]

Thanks for opening this @davidbrochart . I'm still a bit confused about how to handle a middleware since we should not allow any plugin to register on the app directly without ensuring no collisions or intrusive declarations vs other plugins.
I'll take a look

[adriendelsalle]

fastapi/fastapi#1174

[davidbrochart]

I think it can be useful to have plugins register middlewares at the app-level, so that they change the entire app. This is needed e.g. in Quetz. For router-level middlewares, I think there is nothing to do in FPS, since it happens at router definition.
I'll try and add handling of app-level middleware conflicts.

[adriendelsalle]

Hey @davidbrochart thanks for working on this

I would say:

• a plugin should not be allowed to register at application level something that would change any other plugins behavior (e.g. patching)
• collisions between middlewares is not about same class used multiple times
• the case of plugins dependencies may legitimate the fact that an upstream plugin may want to add a middleware or change the root of its downstream(s) plugin(s)
  • plugin2 depends on plugin1 and plugin-auth and would like to apply some middleware provided by plugin-auth on plugin1 routes
  • in that case we could make it possible for plugin2 to import plugin1 router(s) and inject a middleware. we still need capability to apply a middleware on specific routes, not globally for all plugins
  • collisions could be detected if 2 plugins try to apply a middleware on another one (and should be forbidden to avoid undefined behaviors)
• an App, as a pure collection of plugins, could be also authorized modify the final app
  • the question of app of apps would raise the exact same questions mentioned in the previous bullet

TBH I think the solution to your needs is to push upstream (in fastapi and starlette) to make APIRouter capable to handle middlewares: fastapi/fastapi#1174

[adriendelsalle]

I think the redefinition of a middleware is not related to having the same middleware class registered or not.
One may want to register the same middleware class for 2 different groups of routes (e.g. routers).

[davidbrochart]

Don't we have the same situation for exception handlers?

[adriendelsalle]

when registering an exception handler:

• there is no collision between exception classes or handlers (these are directly Python objects)
• one need to import the exception (from a plugin dependency for example) to use it

So I would say no there is basically no possible interference between exception hanlders

[davidbrochart]

TBH I think the solution to your needs is to push upstream (in fastapi and starlette) to make APIRouter capable to handle middlewares: tiangolo/fastapi#1174

It has been done here: encode/starlette#1286.
But I think an app-level middleware should be allowed too, what do you think @wolfv?

[adriendelsalle]

I haven't said it would not be useful ;)
Sorry for this answer but I think that the point of this project is to ensure by design that a plugin is not trying to act outer its scope.

Maybe we need to think about this at App level yes. And probably not allow multiple active Apps at the same time.

Any other thoughts about plugin systems @JohanMabille @fcollonval?

[wolfv]

I think it needs to be possible to register middleware at the global scope (even if it comes from a plugin).

But maybe the way to go is via declaration in a config file? So that you can say:

[middleware]
register_middleware = [
   my_auth_plugin.middleware,
   fast_api.gzip_middleware]

Then a per-plugin middleware is another problem that needs solving but route-specific middleware doesn't seem to be on a good track (if I interpret the fastapi / starlette responses properly).

[adriendelsalle]

Yeah it could be a way to go to declare the middlewares at FPS config (=the App). Thanks @wolfv for your help

[davidbrochart]

Or maybe enabled_middlewares instead of register_middleware, since we already have a enabled_plugins option to enable a plugin as a whole, and plugins already register their middlewares with register_middleware.

[adriendelsalle]

Just middlewares would be fine

[adriendelsalle]

the order of middlewares is not guaranteed here
I think you need to :

• collect middlewares from enabled plugins
• check middlewares listed in FPS config are found
• add them on the app in the config order

[davidbrochart]

I'm wondering if the middlewares config should specify plugins, or middlewares inside plugins?

[davidbrochart]

It seems natural to let each plugin specify its middlewares' order, and thus the middlewares config should rather specify plugins, but it looks like the middlewares' order we get in grouped_middlewares doesn't respect the registration order.

[masus04]

Any updates on this? Seems like a very promising change.

[davidbrochart]

Actually we are going to use Asphalt instead of FPS in Jupyverse (see jupyter-server/jupyverse#277), so I'm not planning to maintain FPS anymore.