[FEATURE REQUEST] Add ability to write "plugin" apps

[simonwistow]

Is your feature request related to a problem? Please describe.
It would be nice to add features which don't rely on PRs to the main app. Either because they're somewhat throwaway or we don't want to support them as maintainers or because a 3rd party wants to add them.

Examples might include:

• @simonwistow 's real-time chart feature
• @jedisct1 's MCP experiment (Add test implementation of an "mcp" command #1484)
• A user who wants to add a Prometheus Exporter that configures itself from your Fastly config

Describe the solution you'd like
A common pattern in CLIs is to have a list of builtin commands but, if a command is passed that isn't built in the cli app will look for a binary in $PATH called <name>-<command>

So, for example calling

fastly help
fastly sso
fastly user create --login=example@example.com --name="Example McExample"

would call the built in commands but

fastly mcp api --http :8080

would look for a binary called fastly-mcp and then exec that with the command line args api --http :8080.

Describe alternatives you've considered
Go plugins might be a way forward but

• Installation could be a pain (have to write to a specific place rather than just in $PATH)
• Plugins are currently supported only on Linux, FreeBSD, and macOS, making them unsuitable for applications intended to be portable.
• Plugins are poorly supported by the Go race detector. Even simple race conditions may not be automatically detected. See https://go.dev/issue/24245 for more information.

Additional context
app.Init does a lot of work to load configs, capture STDERR and STDIO, trap exit() etc ... it would be nice if that was abstracted in a way that plugins could easily reuse that.

[kpfleming]

This is an interesting idea, although I don't immediately see how any of the 'process setup' mechanisms could be reused by a plugin; I'm pretty sure we don't want to make those things an 'API' which must be maintained.

Let me ask an intentionally pointed question: what benefits do you think would be derived from the external tool being invoked in this fashion by the CLI, instead of being invoked directly?

[simonwistow]

The idea would be to allow plugins that would make it easier to release things if you

a) not a Fastly employee
b) want to do something which is experimental

You don't want to merge Frank's mcp server because you don't want to maintain it - that's fine. But it would be nice to give our customers a way to play around with it.

Swiftcloud could release a plugin that makes it easy to deploy Swift to Fastly just like our other approved languages.

Having it be a 'plugin' is better usability, can reuse auth and active profiles, makes things look more integrated and gives the plugin access to common setup and teardown tasks and internal api calls that make pulling relevant data down (list of datacenters for example) easier.

Aesthetically it is nicer

fastly compute build
fastly compute deploy # deploys to fastly
fastly-deploy-to-netlify  # third party script

is uglier than

fastly compute build
fastly compute deploy # deploys to fastly
fastly compute deploy-netlify  # third party script

It is also a statement to the world that we are a platform that should be built on, not a walled garden.

[kpfleming]

Thanks!

There are some aspects to the benefits that you listed which are already in the works: I'm working on a fastly run command which will be able to run any external command while passing along FASTLY_API_KEY (even if that came from an SSO-linked profile).

I don't have a clue at this time how we'd offer 'access to common setup and teardown tasks' or 'internal api calls'; I've never seen a plugin framework in my limited time working with Go other than the one that Terraform uses, and it's totally inappropriate for this sort of thing.