Starport plugin system

Inspiration

Blockchain technology is changing our life very fast and it proves how decentralization is valuable in the future. So, many developers all around the world, try to build their idea and business on the blockchain ecosystem.

Unfortunately it is not feasible to build everything up from scratch because blockchain technology is so comprehensive. That is a reason why Cosmos SDK and Starport are valuable and it makes developers focus on implementing their idea and business without full knowledge and understanding of blockchain.

For developers, flexibility is one of the key important values to realize their idea. Solid and flexible tools will be strong weapons for developers, and that’s why we built a flexible plugin system for Starport.

What it does

Plugin system for Starport that makes 3rd party code can be imported and executed inside of Starport. Any developers can implement plugins that are based on Golang’s plugin packages and publish them to a public Git repository.

For the chain developer side, developers can import and use 3rd party plugins which are published on Git repository.

If chain developers import plugins, Starport’s plugin system downloads and builds plugin binaries on their local machine. And then, Starport loads plugins and provides new plugin commands to use them.

Visit How to test plugins systems to test new plugin system.

How we built it

Core of plugin system is built on reflection of Golang.

At the beginning of this project, our team tried to define the protocols that the plugin system should follows. But we realized that predefined protocols make developers be restricted.

We think flexibility is one of the most important values for developers especially for extensible systems like plugins. So we decided to minimize these protocols and provide a fully flexible plugin environment by using reflection.

Challenges we ran into

Minimizing pre-defined protocol was most hardest part of this project. CLI commands should be loaded dynamically and the developer can run any functions defined on the plugin. Both should be possible at runtime.

To solve this challenge, we use reflection to get object's information at runtime. Plugin system loads plugin objects at runtime and inspects inside of this object with reflect package.

After that, the plugin system understands which functions are available and how to call them. So it is possible to provide CLI commands for the plugin dynamically.

Accomplishments that we're proud of

Introducing a fully flexible plugin system to Starport.

We minimize predefined protocols which the plugin should follow. That means any features can be implemented on a plugin and imported by the Starport plugin system.

What we learned

How to work with the plugin package of Golang.
How to use and work on reflection of Golang.
Understanding of Starport's CLI and scaffolding system.

What's next for Starport plugin system

Implement more commands: Implement more plugin commands to manage plugins like update, delete etc.
Version selection of plugin: Current version of plugin system automatically get latest commit of master branch. But the version should be selectable because of management stuff.
Package deployment tool: utility command for validating plugin code. It will prevent mistakes for developers.