Serverless-application-model: Feature request: Plugin system

[marcy-terui]

Description: I want to add some features to SAM. For example, deployment hooks, language-specific packaging mechanisms, integration of the services outside AWS, and so on. However, I think that it is not realistic to implement all of them in the main system of SAM. So I hope a plugin system. If this request is accepted, I would like to support them as much as possible.

[marcy-terui]

I'm using Serverless Framework now. But I will use SAM if this request is accepted. Because I love Python ✨

[toricls]

I'm also interested in this. maybe the aws-sam-local is the good place to be implemented that?

[Nr18]

What i am missing is a way to have a generic place for your python packages during development. But on a package action that only the requirements of that specific function are included.

This will keep the packages small and only include stuff that is needed.

Is that what you mean with a language specific package mechanism?

The way how i have done it in the past (for nodejs) to place a packages.json file in the folder that contains the lambda function code. Then make use of a Makefile to package make package and use find to locate a packages.json file jump in that directory and install the requirements and move to the next. Eventually zip the folder to a specific place and point the lambda function to that location.

Would be great to have that functionality but my guess is that that should go within aws-sam-local right?

I did check there is no issue open for that functionality: https://github.com/awslabs/aws-sam-local/issues

[marcy-terui]

What i am missing is a way to have a generic place for your python packages during development. But on a package action that only the requirements of that specific function are included.

This will keep the packages small and only include stuff that is needed.

Is that what you mean with a language specific package mechanism?

Yes. We have some Makefiles and/or Shell Scripts to deploy our functions each of us. I think that it is better to integrate the best practices as plugins by each languages.

I think that it is better to integrate the packaging plugins in aws-cli (aws cloudformation package) for now. Anyway, I need some systems and guidelines to expand SAM by myself.

[Nr18]

Right implementing it into the aws-cli would allow non-sam users to benefit too.

I found this issue that looks like that is heading that way: https://github.com/aws/aws-cli/issues/3213

[aletheia]

@marcy-terui do you mean adding the capability to specify a custom transform for CFN? Could be really cool!

[carlsborg]

Bump. User defined distributable plugins is one of the key advantages that the "serverless framework" offers. Its vital to have this in SAM as well. For example, there is an instrumentation library that requires you to add a decorator to every api function. There are plugins available for Serverless Framework, Chalice, and others that make this a one line change, but not SAM because there is no plugin framework. Are you open to design proposals or do you have something in mind already?

[txase]

Plugins seem like a great solution, but they eventually lead to huge problems. As plugins end up being community owned and maintained, there's no centralized mechanism to ensure they work well together.

See https://github.com/dougmoscrop/serverless-plugin-split-stacks/issues/9 for an example of how issues devolve to people listing all the plugins they use together to try to understand why things start breaking.

There are two ways you can achieve the same effect of plugins that are easier to maintain (and, imho, better abstractions anyways):

• For resource manipulation, use a CloudFormation Transformation. SAM itself is one giant transformation. The nice thing about transformations is they can be localized to specific parts of an application template. Even with a global transformation there's still a limited surface area for when transformations are run and what their inputs are.
• For code manipulation, the new SAM CLI build command will be flexible enough for you to specify customizations for how code packages are built. This is the right level to add code-level plugin-like functionality.