A new Flogo CLI

The flogo-cli is a great tool to get started with Project Flogo. Over time the flogo build command has grown from a simple build, to be able to handle tons of options. As we want to support more targets and options, now is a good time to think about the structure of what flogo build should look like. This proposal is aimed to:

• Update the CLI experience using a CLI framework
• Provide a cleaner build experience
• Build a plugin-based CLI
• Change dep

CLI Framework

The current version of the CLI uses our own implementation of certain core features of Golang. This is awesome, but we could also leverage an existing framework like Cobra or Urfave CLI. This will make it easier to maintain and extend the CLI. An example of how the CLI would look can be found here. This implementation makes use of Cobra to generate the commands and help texts (Cobra is also capable of handling things like bash completion)

Cleaner build experience

$ flogo build [-e] [-gen | -nogen] [-target] [-trigger]

Flags

Flag	Usage
e	Embed the application configuration (flogo.json) into the executable
gen	Generate the metadata only (does not perform build)
nogen	Perform build only (does not generate metadata)
target	The target platform to build for
trigger	The trigger to start the app with (only used in combination with the target flag)

Targets

The new target flag would get the following options

• docker
• lambda
• sam
• shim

docker

This will trigger the build of an executable, a Dockerfile, and a docker image (based on Alpine Linux). By default it will expose ports for each trigger that exists. If you only want to expose the port for a single trigger you can use the -trigger flag, which would specify the id of the trigger to use.

lambda

This will trigger the build and creation of an executable and zip file that can be uploaded and deployed to AWS Lambda. By default it will create an executable for each Lambda trigger that exists. If you want to build for a specific trigger you can use the -trigger flag, which would specify the id of the trigger to use.

sam

This will trigger the build and creation of an executable and zip file (like with the lambda target) and also generate a SAM template. By default it will create an executable and a service entry in the SAM template for each Lambda trigger that exists. If you want to build for a specific trigger you can use the -trigger flag, which would specify the id of the trigger to use.

shim

A shim build, in which case the trigger flag must be set as well, is a "catch all" for all other targets. This will require the trigger to have a build.go file which will be triggered

What happens to the existing flags

Flag	Usage	Status
o	optimize for directly referenced contributions	will be removed, this flag wasn't used in the code anymore
e	embed application configuration into executable	stays
gen	ONLY perform the build, without performing the generation of metadata	stays
nogen	ONLY perform generation of metadata, without performing the build	stays
sp	skip prepare	will be removed, this flag was deprecated already
shim	trigger shim creates an app as shim, pass trigger id as value	will be removed, replaced with -target
docker	create a docker image based on Alpine Linux	will be removed, replaced with -target

What happens to the existing triggers

Trigger	Impact	New command
cli	Change (-target shim)	flogo build -e -target shim -trigger cli_trigger
coap	No change
kafkasub	No change
lambda	Change (-target lambda)	flogo build -e -target lambda or flogo build -e -target sam
mqtt	No change
rest	No change
timer	No change

Plugin-based

The example CLI here, has added commands to be able to work with "plugins". In this model, we can extend the CLI with new commands that could come from other repositories. For example, someone can create a specific plugin to deploy apps to a new PaaS platform. Each plugin would have a TOML file describing the name, the repository and the files:

[[plugin]]
name = "flogowebloader"
repository = "https://github.com/retgits/flogowebloader"
files = ["cmd/flogowebloader.go"]

A command like flogo plugin install --url ... would get the files and put them in the flogo-cli folder and do a new build (like we're currently doing as you do a go get or when you build from source). Other commands will be able to remove the plugin and list the plugins that are currently installed. A plugin could, for example, help with loading and storing apps from the Flogo Web UI. The current Flogo-CLI would be broken down into three parts:

• flogo-cli-core: the core framework containing the root command flogo and the plugin commands
• flogo-apps: the capability to build, create and generate flogo apps (like the Flogo CLI has today)
• flogo-device: the capability to build, create and generate flogo device apps (like the Flogo CLI has today)
• flogo-generate: the capability to generate new extensions (for which we have a different binary, flogogen, today)

This way a developer that has no interest in building device apps today, can select to only install the core and the apps part. Later on he can decide to install other plugins as needed

Change dep

dep is a great management tool, but currently the Go community is moving towards vgo. At the same time, we're seeing tons of issues with dependencies and branches. As we're moving to build a new CLI we should consider deprecating our usage of dep and investigate whether vgo will work.