Consider adding default Runtime for all Functions about serverless-application-model HOT 7 CLOSED

For that matter, same goes for other properties that could in some cases be set globally:

CodeUri
MemorySize
Timeout
Role
Policies
Environment
VpcConfig

The non-trivial decision would be how to deal with overrides for some these properties (namely Role, Policies, Environment and VpcConfig) for each Function, i.e. if it should be a replacement, an intersection, or a union.

from serverless-application-model.

This is an interesting approach. The problem with assuming global defaults that are not explicitly written in the template is

1. People should be aware that defaults exist. When Lambda service & CloudFormation does not assume a default runtime, it would be confusing if we Serverless::Function assumes one
2. Default value might change: nodejs4.3 might reach end-of-life in which case we should change the defaults breaking existing templates. Subsequently, AllowedValues array will also change.

Does this make sense?

from serverless-application-model.

Sounds reasonable!

Even if we cannot rely on implicit defaults, it would still be very useful to be able to specify global overrides, similar to how it's done in the Serverless framework. So the users would need to explicitly specify global "defaults" (as an option), which could still be explicitly overridden for specific functions as needed. If the user doesn't specify a global default, SAM would use the current behavior.

Would this approach still break things?

from serverless-application-model.

You can still use Parameters will default values today and !Ref the parameter in your Runtime. You have to write a few extra redundant lines for the first time you write the template.

But yes, your proposal keeps the template a bit more terse. One could view the global defaults as a system-configuration for their entire app. But then, SAM has to make assumptions about name of the parameter used by global defaults, which is bad.

When you override defaults, now your template suddenly has an implicit if-then-else logic which isn't explicitly written down. It makes the template harder to reason about.

This is certainly an interesting proposal, but for sake of simplicity I would vote against it.

Thoughts?

from serverless-application-model.

It's nice that we can already reference them in each function, and that solves the issue of hard-coded parameters. But we still have to put the same reference into all Functions (if we use the same Runtime, for example), which in a way goes against the goals of simplifying serverless configuration. An already existing counter-example of that (IMO) is the implied API resource that gets created if we don't specify RestAPI ourselves. I think such convention-over-configuration is good for keeping things concise and simple, as long as we clearly state what the default behaviors are.

I agree that defaults specified as "parameters" may/will lead to conflicts. Maybe it'd be better to create a dedicated section (e.g. 'DefaultProperties'), not related to the 'Parameters' section (if only through references), which would explicitly state which defaults are used throughout the template. This way, there would be only one logical path, at least in how I see it: 'apply DefaultProperties' -> 'apply Properties', where 'by default' the DefaultProperties section is implied to be empty, and the behavior of 'apply Properties' would be to set the final values, overwriting any modifications made in DefaultProperties. Or does the internal logic for parsing properties for each Function act independently of any 'global context' of the template (if there's any)?

Thanks

from serverless-application-model.

Or we could use a 'Template' resource, as suggested in #26

from serverless-application-model.

This is now available in Globals section: https://github.com/awslabs/serverless-application-model/releases/tag/1.3.0

from serverless-application-model.