Plugin Architecture Proposal

Amplify plugin architecture Proposal

Amplify CLI is built such that it can be extended using plugins. All the categories and providers are plugins. It uses gluegun to support plugins. Gluegun plugin system allows users to easily add command using plugins. It exposes an context/toolbox object for each plugin command.

Why move away from gluegun based on plugin system

Gluegun makes it easy to add new commands to CLI using a plugin. Currently each category provides a new command to support a functionality. But the number of commands each category needs to support are

• add
• remove
• update
• configure

Each category is designed such that they could support multiple providers. But the core support only cloudformation as a provider. If anyone wants to add an additional provider, they have either have to write a new plugin with a different name or contribute code back to core plugin if they want to keep the name of the command common. For instance, if someone wants to add auth which uses a different provider, then they either have to create a new plugin amplify-category-auth-foo and the command that they will have to run amplify auth-foo add instead of running amplify auth add. If they want to support amplify auth add then they will have to contribute their plugin data to amplify-category-auth which means that core team will have to either give access to the repo or take up the maintenance.