template resource

[nalbion]

One of the downsides of the micro services architecture model is that there is more overhead because the configuration, management and deployment tasks are duplicated for each service. Our swagger schemas and Cloudformation templates are full of copy-and-pasted snippets.

In the example below, the commonality is extracted into LambdaTemplate, reducing the PutFunction to 3 lines and allowing the differences between the other functions to be more obvious.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  LambdaTemplate:
    Type: AWS::Serverless::TemplateFunction
    Properties:
      Handler: index.handler
      Runtime: nodejs4.3
      Policies: AWSLambdaDynamoDBExecutionRole
      CodeUri: s3://bucketName/codepackage.zip
      Environment:
        Variables:
          TABLE_NAME: !Ref Table

  PutFunction:
    Type: AWS::Serverless::Function
    Properties:
      # extra points if this can (optionally) be imported from an external file, even in a separate but shared repository
      Template: !Ref LambdaTemplate
  GetFunction:
    Type: AWS::Serverless::Function
    Properties:
      Template: !Ref LambdaTemplate
      Handler: index.getHandler
  DeleteFunction:
    Type: AWS::Serverless::Function
    Properties:
      Template: !Ref LambdaTemplate
      Events:
        Stream:
          Type: DynamoDB
          Properties:
            Stream: !GetAtt DynamoDBTable.StreamArn
            BatchSize: 100
            StartingPosition: TRIM_HORIZON

   DynamoDBTable:
     Type: AWS::DynamoDB::Table
     Properties: 
       AttributeDefinitions: 
         - AttributeName: id
           AttributeType: S
       KeySchema: 
         - AttributeName: id
           KeyType: HASH
       ProvisionedThroughput: 
         ReadCapacityUnits: 5
         WriteCapacityUnits: 5
       StreamSpecification:
         StreamViewType: streamview type

[dinvlad]

That looks great, and would also solve the problem of 'default' parameters as in #24.
We'd only need to make sure that the properties from the 'template' would be overwritten if we also specified them locally.

[sanathkr]

I am starting to pick this task back up.

How do you imagine the local override to work for nested structures like Environment Variables. There are two options. Let me illustrate:

Assume this is the template (obvious properties omitted for simplicity):

FunctionTemplate:
  Type: AWS::Serverless::Template
  Properties:
    Environment:
      Variables:
         TableName: foo

MyFirstFunction:
  Properties:
    Template: !Ref FunctionTemplate
    Environment:
       Variables:
          DBName: bar

MySecondFunction:
  Properties:
    Template: !Ref FunctionTemplate

There are two options:

1. Environment variables get merged:: So, MyFirstFunction will get both TableName and DBName variable

2. Environment variables get overwritten: MyFirstFunction gets only DBName because you have overridden the Environment property entirely.

Option 1 is weird because it literally merges two different dictionaries which can cause complications. It will be even weird for Events section which can have a multi-level dictionary and even arrays.

Option 2 is easier to understand, easy to reason about and gives most of the benefits.

What do you guys prefer? What do you want to use in your templates?

[sanathkr]

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