Plugin support?

[Anachron]

Do you plan to allow for pluggable features, such as an administrator UI that could be activated by simply adding 'rocket.register_plugin'?

I am thinking about a system where users have it easy to add or remove a feature (plugin) without having too much stuff to do.

In my mind plugins would have a init method which would do all the stuff a user would normally do to glue the code.

[SergioBenitez]

Many of the things you'd use "plugins" for in other frameworks you can already do with Rocket. For example, you might imagine a library that exposes many "admin panel" routes. Then, your application could simply configure that library and mount those routes. That would look something like this:

fn main() {
    let admin_routes = AdminLibrary::config(param, param, ..);
    rocket::ignite().mount("/admin", admin_routes).launch();
}

You could even get rid of the AdminLibrary::config step if the library is amenable to being configured via Rocket.toml extra parameters, as discussed in the API docs. This is something you can do today, and it doesn't introduce another concept.

I don't have a high opinion of catch-all ideas like plugins and middleware. I'd rather find a solution that works very well for a few things rather than poorly for most things. Many of the things that might lead you to reach for plugins or middleware elsewhere can already be done with Rocket in a different, usually cleaner and more focused way. I'd like to keep the concepts to a minimum.

[aniljava]

There are some use cases like response compression, filters that are applicable for multiple routes (auth, logging, response header alterations .. ). middlewares i think are better fit. But being a rust newbie, i cant rule out if there are language features to achieve the same thing. Any suggestions how these things are going to be addressed.

[stephanbuys]

@SergioBenitez I'm quite interested in using JWT - would a plugin be required for it?

Edit - just APIKey example, I'm guessing that's the road to pursue.

[SergioBenitez]

@stephanbuys That's right. :)

Okay, so looks like we're really talking about middleware here. Closing in favor of #55.