@@ -72,7 +72,8 @@ A valid use is to forward the alias name as environment variable to the lambdas
72
72
and use it there for tagging of log messages. Then you see immediately which
73
73
aliased lambda is the origin.
74
74
75
- Any other use is strongly discouraged.
75
+ Any other use with the further exception of lambda event subscriptions (see below)
76
+ is strongly discouraged.
76
77
77
78
## Log groups (not yet finished)
78
79
@@ -104,6 +105,85 @@ that they have to update their configuration too - most likely, they updated it
104
105
already, because normally you rebase or merge your upstream and get the changes
105
106
automatically.
106
107
108
+ ## Event subscriptions
109
+
110
+ Event subscriptions that are defined for a lambda function will be deployed per
111
+ alias, i.e. the event will trigger the correct deployed aliased function.
112
+
113
+ ### Use with global resources
114
+
115
+ Event subscriptions can reference resources that are available throughout all
116
+ aliases if they reference the same resource id. That means that an event will
117
+ trigger all aliases that are deployed with the subscription defined.
118
+
119
+ Example:
120
+
121
+ ```
122
+ functions:
123
+ testfct1:
124
+ description: 'My test function'
125
+ handler: handlers/testfct1/handler.handle
126
+ events:
127
+ - stream:
128
+ type: kinesis
129
+ arn: "arn:aws:kinesis:${self:provider.region}:XXXXXX:stream/my-kinesis"
130
+ - http:
131
+ method: GET
132
+ path: /func1
133
+ resources:
134
+ Resources:
135
+ myKinesis:
136
+ Type: AWS::Kinesis::Stream
137
+ Properties:
138
+ Name: my-kinesis
139
+ ShardCount: 1
140
+ ```
141
+
142
+ When a function is deployed to an alias it will now also listen to the * my-kinesis*
143
+ stream events. This is useful, if you want to test new implementations with an
144
+ existing resource.
145
+
146
+ ### Use with per alias resources
147
+
148
+ There might be cases where you want to test with your private resources first,
149
+ before you deploy changes to the master alias. Or you just want to create separate
150
+ resources and event subscriptions per alias.
151
+
152
+ The solution here is to make the resource id dependent on the alias name, so that
153
+ the alias effectively owns the resource and the event subscription is bound to it.
154
+
155
+ Example:
156
+
157
+ ```
158
+ functions:
159
+ testfct1:
160
+ description: 'My test function'
161
+ handler: handlers/testfct1/handler.handle
162
+ events:
163
+ - stream:
164
+ type: kinesis
165
+ arn: "arn:aws:kinesis:${self:provider.region}:XXXXXX:stream/my-kinesis-${self.provider.alias}"
166
+ - http:
167
+ method: GET
168
+ path: /func1
169
+ resources:
170
+ Resources:
171
+ myKinesis${self:provider.alias}:
172
+ Type: AWS::Kinesis::Stream
173
+ Properties:
174
+ Name: my-kinesis-${self.provider.alias}
175
+ ShardCount: 1
176
+ ```
177
+
178
+ ### Named streams
179
+
180
+ The examples above use named streams. I know that this is not perfect as changes
181
+ that require replacement are not possible. The reason for the named resources is,
182
+ that Serverless currently only supports event arns that are strings.
183
+ The change is already in the pipeline there. Afterwards you just can reference
184
+ the event arns with CF functions like "Fn::GetAtt" or "Ref". I will update
185
+ the examples as soon as it is fixed there and publicly available.
186
+
107
187
## Serverless info integration
108
188
109
189
The plugin integrates with the Serverless info command. It will extend the information
0 commit comments