New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin API changes #855
Plugin API changes #855
Conversation
✅ Deploy Preview for apollo-router-docs canceled.
|
This comment has been minimized.
This comment has been minimized.
Previously the Plugin trait has three lifecycle hooks: new, startup, and shutdown. Startup and shutdown are problematic because: * Plugin construction happens in new and startup. This means creating in new and populating in startup. * Startup and shutdown has to be explained to the user. * Startup and shutdown ordering is delicate. The lifecycle now looks like this: 1. `new` 2. `activate` 3. `drop` Users can migrate their plugins using the following: * `Plugin#startup`->`Plugin#new` * `Plugin#shutdown`->`Drop#drop` In addition the `activate` lifecycle hook is now not marked as deprecated, and users are free to use it.
a88267b
to
2c1e70b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't quite figure out from the review, but part of the motivation behind "previous_plugins" was so that we could safely recover from a failing configuration. Is that not a requirement now? Does the IndexMap insert change means that is now handled in there?
Added some notes in the description, but here's the elevator pitch. The user can use Drop to clean up resources. And we will ensure that plugins are not dropped until they are no longer in use (they end up in the state machine private state). Using Drop is much safer for everyone as it means that if we modify our code we don't have to make sure that every error case is handled to ensure that we call The downside is that if any async work needs to be done in drop then users have to create a tokio runtime to do this. But in general this shouldn't be needed, and it's likely only to be Otel with it's weird hanging behaviour that requires it. |
@@ -18,6 +19,8 @@ use tower::{BoxError, ServiceBuilder, ServiceExt}; | |||
use tower_service::Service; | |||
use typed_builder::TypedBuilder; | |||
|
|||
pub type Plugins = IndexMap<String, Box<dyn DynPlugin>>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using indexmap is a nice touch :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is much nicer than the previous workflow 👍
9fe95e2
to
9afd1b0
Compare
…and shutdown. Startup and shutdown are problematic because: * Plugin construction happens in new and startup. This means creating in new and populating in startup. * Startup and shutdown has to be explained to the user. * Startup and shutdown ordering is delicate. The lifecycle now looks like this: 1. `new` 2. `activate` 3. `drop` Users can migrate their plugins using the following: * `Plugin#startup`->`Plugin#new` * `Plugin#shutdown`->`Drop#drop` In addition the `activate` lifecycle hook is now not marked as deprecated, and users are free to use it.
Co-authored-by: Gary Pennington <gary@apollographql.com>
9afd1b0
to
15e2e64
Compare
Plugin API changes PR #855
Previously the Plugin trait has three lifecycle hooks: new, startup, and shutdown.
Startup and shutdown are problematic because:
The lifecycle now looks like this:
new
activate
drop
Users can migrate their plugins using the following:
Plugin#startup
->Plugin#new
Plugin#shutdown
->Drop#drop
In addition the
activate
lifecycle hook is now not marked as deprecated, and users are free to use it.Implementation notes
new
async and removing thestartup
andshutdown
methods.For state there can only be one