[Exploration] Plugins

[praneetap]

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 -

1. IaC plugins enable SAM CLI build and package steps to be run on IaC frameworks that are not currently supported.
2. Local Emulator Plugins increase the local testability of infrastructure by creating emulators for dependencies not currently supported.
3. 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?

[ghost]

Option 3 would be quite useful for me to address problems like aws/serverless-application-model#2150.
In the case CloudFormation does not end up with semantics to express embedded data types, I would want to develop a way to do so. By authoring that as an extension I could also share it with the broader community.

[ghost]

Option 2 does not seem as useful to me because of the discrepancies between local emulators and sam deploy combined with Cloudwatch logs. I feel like the clearest way to test SAM and relevant AWS services is to simply deploy, assert, then delete.

[iongion]

This is great, waiting for it so much, dreaming of being able to extend and make it able to:

• Hot reload code on local fille change avoiding sam full build for those languages where it is not needed
• Control schedule functions, disable auto trigger or trigger manually
• Ability to add custom web pages as dashboards, for example one that mounts api docs, the swagger ui collected from parsing http events
• Use other container engines besides docker

For all above my current solution is a custom sam local emulator, built on flask, but I needed to implement a custom cloudformation parser, far from what real sam supports. And it just lives in my own world instead of sharing with others.

Great ideea and hope it shapes up!

[ghost]

@iongion Great list!
I love the suggestion for an alternate container engine. That enable experimentation and potentially improved CI infrastructure.

[ghost]

I see Lambda Layer optimizers as another pertinent example of option 3.
For python dependencies, I need to use something like https://github.com/tobilg/python-lambda-layer-builder

[Hobbit71]

I can see benefits for all 3 options.

I am especially interested in option 3 as it would allow a neat way for us to emulate our own downstream services that might be consumed by the current SAM application and simplify local testing.

Custom build actions would also be useful, we use monorepos and custom build steps could allow us to add integration back to our mono-repo framework we use.

[praneetap]

Option 2 does not seem as useful to me because of the discrepancies between local emulators and sam deploy combined with Cloudwatch logs. I feel like the clearest way to test SAM and relevant AWS services is to simply deploy, assert, then delete.

We just announced SAM accelerate which does exactly this. Here is a helpful video to learn more about it, and here is the installation instructions for the beta version. Try it out and let us know if this is helpful!

[dominics]

Option 2 is most useful to us, because we use AppSync and we have no simulator support otherwise, since the earlier PR to add it was turned down. (We have built our own on Apollo Server, for example)

Option 1 is least useful to us: any good IaC system like Terraform will have myriad ways to exec commands and take content-addressed input packages, not do deploys that aren't necessary etc. etc.. So, there's no need for SAM to try to coordinate those; that seems the wrong way around: IaC tools would coordinate SAM instead (or the wider CI/CD system will), if they wanted to use the SAM build? (And can already, today?) So, it's not clear to me what this brings exactly: probably more a question for the thread at #3154 to answer first, before the value would be clear to me.

An aside: SAM accelerate is not useful for us because of shared resources, not being near the target region, and we just fundamentally find the local development experience to be much better than any sort of watch-deploy, even with good low-latency internet connections. So, we vastly prefer simulators, and are happy to take a knock in the small details where they might fail to simulate correctly: those almost never cause problems.

Primary advantage of Option 2 IMO: then Lambda development can "work in the same way as everything else" (that you can "just start up on localhost:3000", for example, i.e. traditional web backends - we have this already for API GW, but nothing for AppSync, as I understand it)

[revmischa]

I need the ability to run AppSync locally. I don't care about the VTL junk but being able to hit my GraphQL API locally and call lambda functions would be a huge boost to developer productivity, instead of having to do a deployment each time we make a change.

[johnc44]

Option 2 for me. There are a few things that would be handy if SAM could do/help with when running locally:

1. Authorizers. I'd be quite happy with a mock authoriser, just something so I don't have to fudge my code to run locally.
2. Integration with other local emulations. E.g. being able to use local SQS/SNS/Dynamo etc and have the Events defined in my template just work.
3. Other things beyond API Gateway and raw lambda invocation. E.g. AppSync or using lambda behind an ALB.
4. Ways to retrieve environment variables from the cloud. (E.g. SSM parameters)

The first one is most important, the other 3 can be worked around, but something more nicely integrated would avoid the need for extra scripts.

Out of the others, I'm personally only using CloudFormation so option 1 not that interesting.
I'm not 100% sure what Option 3 would give, but off the top of my head a few things that might be useful (some of which tie into Option 1)

1. Our own custom Events, e.g. an ALB event source
2. Something that could create extra resources if needed. I'm thinking of explicitly lcreating a Cloudwatch log group for a serverless function and with an extra property to set its expiration period.
3. sometimes event sources have issues and we end up having to use full CFN resources instead. I'm thinking in particular of scheduled events and how it's not possible to disable it based on a condition, but we've had other little things like that.

Sorry about the random brain splurge - just a few things that come to mind. Annything in sam that allows us to tweak any behaviour would be great. It might be that option 2 and 3 are really the same - a sort of pipeline where we can transform data on its way through that can be applied to various places in the sam workflow inc local.

[kjones]

Just a comment on plugins in general...

Part of the reason I stopped using serverless.com framework and switched to SAM was the reliance on 3rd party plugins to provide functionality. A few of these plugins were slow at fixing bugs or just stopped being maintained at all. It's been a few years so I don't remember exactly what features these plugins provided. I do remember thinking that the features these plugins provided should have been core functionality. Or perhaps any plugin that became widely used should in some way (monetary or developer resources) be supported by serverless.com.

[nouman91]

Option 3 for me. We have a couple of projects in our organization, where local testing can really help developers and increase developer productivity.

[travishaby]

Option 2 for us at Guild...we are leaning into GraphQL + serverless across our platform and not being able to emulate AppSync locally with SAM is a big pain point

[jfuss]

Moved to Discussions: #4692

Closing

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.