Hacker News Reader

Comment by pfalafel | Hacker News Reader

What exactly does it mean to say that plugins "can then be swapped out"? I assume a binary Go plugin can not in fact be unloaded from memory. So modifying and reloading a Go plugin will result in multiple versions of it to then stay in memory. This is a shortcoming of the current Go implementation. Is my understanding correct?

View on HN

Do not assume "Go Plugin" in this context. We are not using the Go plugin system. Plugin is a name used to describe something that can be "plugged in" or that is "plug and play". In our case as mentioned, we use the Go interface as an abstraction and the "Plugin" is an implementation of that interface which can replace what you're using.

You will import plugins for rabbitmq, kafka, etc as a Go import. You can then use env vars and flags to choose which you want to use. Internally we are taking an initialiser for New[Plugin] from a list and executing it to set it up. There is no Go language plugin loading, its all still compiled code. Its just how we use the abstraction.

Please see the readme for our plugins for more detail https://github.com/micro/go-plugins

I think you are confusing whatever go micro is offering with https://golang.org/pkg/plugin/

I'm pretty sure go micro's plugins are just additional packages each for its purpose ready to be imported and used in your project.

Basically a collection of community maintained packages for the most common utils\middleware\MQ clients etc

The runtime you build will have all plugins micro supports by default at time of compile, and any custom plugins you create that implement the interface. They are hot-loaded at runtime, but you are correct in that you cannot unload them. Since the switching is done by environment variables, you'd have to restart to reload with other plugins.

Plugins are really specific by platform combinations and support, so you're unlikely to change them much after initial launch. It's only useful if you're going from metal to cloud provider or changing the method of interaction between you API layers.

It's pluggable in that large parts of it can be replaced or disabled at compile time. Runtime reconfiguration isn't well supported.

Well if you pack in a new communication bus plugin, you'd still have all of the defaults (rabbitmq, and so on) available in addition to the one you add. You can use Environment variables to pick the one you want by its name.

Reply on news.ycombinator.com