[Exploration] Plugins

[jfuss]

Currently we are exploring ways to extend SAM CLI’s (Serverless Application Model Command Line Interface) functionality by allowing developers to build plugins. We are considering three kinds of plugins -

IaC plugins enable SAM CLI build and package steps to be run on IaC frameworks that are not currently supported.
Local Emulator Plugins increase the local testability of infrastructure by creating emulators for dependencies not currently supported.
Workflow Customization allows plugins to add custom steps in the SAM CLI build workflow.

Of the three options above, which is the most useful to you and why? Which is the least useful?

This was migrated from Issues. Original Issue can be found at #3265

[igorlg]

Personally, a plugin structure for the build stage, where one could have more control over how functions are built and packaged, would be really useful.

Today, if not using the 'native' build/package methodology of each language, one has to resort to Makefiles. While I like make as much as the next person, make is reallyt opinionated - and designed for - C-style languages. Yes, it is possible to use Make as a script-runner, but often times doing pretty simple things in Make can be difficult for the non-initiated.

If, instead, the entire build/package functionality of SAM was pluggable, the community could easily contribute with better language-specific build methodologies without requiring users to resort to project-level hacks or customisations.

Example: I use Poetry for managing Python dependencies and packaging. That requires me to run the entire project lifecycle through Make - including SAM commands. It is easier now that I have the Makefile, but not having to do it in the first place would be better...

[igorlg]

As a side note: there are a number of ways to build a Plugin structure. If I may make a suggestion, consider using the Git* approach of 'subcommands' being simply standalone executables in the $PATH, all prefixed with a common name, e.g.

git crypt xyz == git-crypt xyz

You could then pass as an argument a serialized dict to the subcommand with internal information from SAM that the plugin might need.

*: IDK if Git originally did it, I just learned about it from Git

[randallb]

(2) for me... I need to test graphql locally and that seems difficult with SAM right now.

[ianwremmel]

I think I'd really be looking for a fourth category of plugin: I want to be able to do additional transformations on the cloudformation template prior to its emission. (That seems different from your first category). As it is, I've written a bunch of tooling that takes a human authored template, then adds a bunch of stuff to it, then passes it to sam build. Prior to deploy, I do another quick sed to strip out the source map instructions because sam cli is a bit heavy handed in that regard (I want to generate source maps, but don't want to ship them).

[joshriverscambia2019]

In addition to build workflow plugins, I'd like to be able to hook into and replace the publish functionality to provide hooks or limitations for my environment.

[kbolino]

Which of these options would enable WebSocket APIs to be locally testable (#896)?

Maybe "Local Emulator Plugins"? Though, this is part of API Gateway and thus a pretty core feature rather than a "dependency".

[yelvert]

Hey amazon, 5 years and counting on this missing feature. I cant use api gateway with websockets in production if I cant test them locally.

[randallb]

I have a fix for this. I'll post about it sometime.

[mbklein]

@randallb Are you able to share your fix/workaround for running websocket APIs locally? We're really struggling with this.