This is a Feature Proposal

Description

The best practice of architecting a Serverless application is to separate functionality on a per-service basis ("Microservices).

This means that one service (e.g. users) translates to one serverless.yml file.

Until now there's no native way to interconnect two or more services and share values between them (e.g. Network interfaces).

This proposal describes a native, multi-provider way to exports and imports values from different Serverless services to make it easier to build large scale Serverless architectures and applications.

Refs #3441
Refs #3411
Refs #2995
Refs #2387

Note: This is a WIP which will be refined based on the feedback in this issue. Feedback is (as usual) highly welcomed! 💪

/cc @brianneisler @eahefnawy

Syntax

The proposed syntax for exports is:

exports:
  <key>: <value>

The proposed syntax for imports is:

imports:
  <service-name>:
    - <key>

An example

The following is an example how the usage of imports and exports could look like. In this case two different services share values between them.

# serverless.yml of users service

service: users

exports:
  writeKey: QWERTY1234
  subnetId:
    Ref: PublicSubnet
  securityGroup:
    Fn::GetAtt:
      - WebServerSecurityGroup
      - GroupId

# serverless.yml of posts service

name: posts

exports:
  someKey: someValue

imports:
  users:
    - subnetId
    - securityGroup
    - writeKey

resources:
  Resources:
    Type: "AWS::S3::Bucket"
    Properties:
      BucketName: ${imports:users.writeKey}

Implementation

The imports and exports statements are key / value based configuration parameters. This kind of abstraction enables a good way to implement this feature in a multi provider way.

The imported values will be available as a part of the variable system so that those values can be placed wherever needed (e.g. in the Resources section).

In AWS case the values will be translated to corresponding Outputs and Fn::ImportValue statements (click here for an example how this looks like in CloudFormation syntax).

Problems / Issues we need to solve

• How do we deal with services in different regions (AWS currently has no support for cross region stack references)
• Happens if they are in different accounts?
• How do we deal with custom stack name
• How do we deal with the dependency on the stack name?
• How do we deal with stack removals if they depend on each other via Import and Export?