Description
Relates to #73
I'm trying to make the architecture of Atomic-Server as modular as possible, and basically dog-feeding a future Plugin interface. This interface should allow other developers to add functionality to Atomic Server. Ideally, one day, allowing these to be loaded at runtime as WASM binaries.
Anyways, we should have a really clear API for these Plugins. Currently, plugins are rust files with a bunch of functions, which are imported at the right place. This approach has a couple of issues:
- It's hard to discover which plugin functions are available, e.g. at which times you can add middleware logic
- It becomes tempting to make custom function signatures for specific plugins, which leads to a lack of a standardized API
So we want that developers can easily import something, describe their logic, and load the plugin.
Maybe I'm missing something, but I think the only three approaches are traits, structs, or with macros
Plugins as Structs
The plugin does something like atomic_lib::Plugin::new()
, and calls a bunch of builder methods, like my_plugin.add_on_commit_handler(my_custom_function, my_condition)
.
- Calling these setters may feel a little unintuitive
- Allows for setting multiple handlers
Plugins as Traits
- Intuitive API for rust devs
- A handler can only be implemented once
- Can have internal state
Macros
Add Macros to functions like so:
#[atomic_lib::on_commit("urls::MESSAGE")
fn my_handler_for_messages() {}
On compilation, we add a function and add it to some Struct.