extend firefly-core with plugins without requiring a fork

[hosie]

trafficstars

It seems that the only way to package a plugin into firefly-core is to make code changes in the firefly repo itself. Which means that the plugin developer effectively needs to maintain a fork and track origin.

A couple of thoughts on how we could make this more elegant

• rather than ( or at least, as well as) having a hard coded list of transport providers we could introduce a way to dynamically register implementations of the event.Plugin interface. i.e. similar to the registration of policy engines in firefly-transaction-manager
• move the bootstrapping code into pkg so that a plugin developer can build their own golang executable to extend firefly-core with their plugin and only provide a very thin cmd package that simply invokes the firefly-core bootstrap ( after registering the plugins as my first bullet 1)

Full disclosure: I am not a golang expert so there may be a much more elegant way to achieve this that I am not seeing.

[peterbroadhurst]

Think both of these are a great step forwards. They match how Firefly Transaction Manager evolved, and we already took part of pattern and back-ported to a small piece of Core (via common) with the API authentication plugin: https://github.com/hyperledger/firefly-common/blob/8463e27fe490a87061a6b75080b45a0b9a535f32/pkg/auth/authfactory/factory.go#L39-L46

[nguyer]

I think this is a great idea as well. There is actually an instance of the first pattern in firefly-common with the auth plugin.

https://github.com/hyperledger/firefly-common/blob/main/pkg/auth/authfactory/factory.go#L39-L46

We wanted to have the same auth mechanism available for all FireFly microservices, so the plugin interface, and the basic auth implementation went into firefly-common. But other services could call RegisterPlugins() to "install" their own authorizer function.

It's probably a bit different than how we want the general case to work here, but just thought I'd point it out in case it's useful.