You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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:
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, likemy_plugin.add_on_commit_handler(my_custom_function, my_condition)
.Plugins as Traits
Macros
Add Macros to functions like so:
On compilation, we add a function and add it to some Struct.
The text was updated successfully, but these errors were encountered: