You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+4-3Lines changed: 4 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@
12
12
13
13
**The Serverless Framework** – Build applications comprised of microservices that run in response to events, auto-scale for you, and only charge you when they run. This lowers the total cost of maintaining your apps, enabling you to build more logic, faster.
14
14
15
-
The Framework uses new event-driven compute services, like AWS Lambda, Google CloudFunctions, and more. It's a command-line tool, providing scaffolding, workflow automation and best practices for developing and deploying your serverless architecture. It's also completely extensible via plugins.
15
+
The Framework uses new event-driven compute services, like AWS Lambda, Google Cloud Functions, and more. It's a command-line tool, providing scaffolding, workflow automation and best practices for developing and deploying your serverless architecture. It's also completely extensible via plugins.
16
16
17
17
Serverless is an MIT open-source project, actively maintained by a full-time, venture-backed team.
18
18
@@ -132,7 +132,7 @@ The following are services you can instantly install and use by running `serverl
* Manages the lifecycle of your serverless architecture (build, deploy, update, delete).
137
137
* Safely deploy functions, events and their required resources together via provider resource managers (e.g., AWS CloudFormation).
138
138
* Functions can be grouped ("serverless services") for easy management of code, resources & processes, across large projects & teams.
@@ -158,7 +158,7 @@ This table is generated from https://github.com/serverless/plugins/blob/master/p
158
158
|**[Raml Serverless](https://github.com/andrewcurioso/raml-serverless)** <br/> Serverless plugin to work with RAML API spec documents |[andrewcurioso](http://github.com/andrewcurioso)|
159
159
|**[Serverless Alexa Plugin](https://github.com/rajington/serverless-alexa-plugin)** <br/> Serverless plugin to support Alexa Lambda events |[rajington](http://github.com/rajington)|
160
160
|**[Serverless Api Stage](https://github.com/leftclickben/serverless-api-stage)** <br/> Serverless API Stage plugin, enables stage variables and logging for AWS API Gateway. |[leftclickben](http://github.com/leftclickben)|
161
-
|**[Serverless Apig S3](https://github.com/sdd/serverless-apig-s3)** <br/> Serve static front-end content from S3 via the API Gatewy and deploy client bundle to S3. |[sdd](http://github.com/sdd)|
161
+
|**[Serverless Apig S3](https://github.com/sdd/serverless-apig-s3)** <br/> Serve static front-end content from S3 via the API Gateway and deploy client bundle to S3. |[sdd](http://github.com/sdd)|
162
162
|**[Serverless Apigateway Plugin](https://github.com/GFG/serverless-apigateway-plugin)** <br/> Configure the AWS api gateway: Binary support, Headers and Body template mappings |[GFG](http://github.com/GFG)|
163
163
|**[Serverless Apigw Binary](https://github.com/maciejtreder/serverless-apigw-binary)** <br/> Plugin to enable binary support in AWS API Gateway. |[maciejtreder](http://github.com/maciejtreder)|
164
164
|**[Serverless Apigwy Binary](https://github.com/ryanmurakami/serverless-apigwy-binary)** <br/> Serverless plugin for configuring API Gateway to return binary responses |[ryanmurakami](http://github.com/ryanmurakami)|
@@ -263,6 +263,7 @@ This table is generated from https://github.com/serverless/examples/blob/master/
263
263
-->
264
264
| Project Name | Author |
265
265
|:-------------|:------:|
266
+
|**[Serverless Architecture Boilerplate](https://github.com/msfidelis/serverless-architecture-boilerplate)** <br/> Boilerplate to organize and deploy big projects using Serverless and CloudFormation on AWS |[msfidelis](http://github.com/msfidelis)|
266
267
|**[Jwtauthorizr](https://github.com/serverlessbuch/jwtAuthorizr)** <br/> Custom JWT Authorizer Lambda function for Amazon API Gateway with Bearer JWT |[serverlessbuch](http://github.com/serverlessbuch)|
267
268
|**[Serverless Graphql Api](https://github.com/boazdejong/serverless-graphql-api)** <br/> Serverless GraphQL API using Lambda and DynamoDB |[boazdejong](http://github.com/boazdejong)|
268
269
|**[Serverless Screenshot](https://github.com/svdgraaf/serverless-screenshot)** <br/> Serverless Screenshot Service using PhantomJS |[svdgraaf](http://github.com/svdgraaf)|
Copy file name to clipboardExpand all lines: docs/providers/aws/events/alexa-skill.md
+29-2Lines changed: 29 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -14,14 +14,41 @@ layout: Doc
14
14
15
15
## Event definition
16
16
17
-
This will enable your Lambda function to be called by an Alexa skill kit.
17
+
This will enable your Lambda function to be called by an Alexa Skill kit.
18
+
`amzn1.ask.skill.xx-xx-xx-xx-xx` is a skill ID for Alexa Skills kit. You receive a skill ID once you register and create a skill in [Amazon Developer Console](https://developer.amazon.com/).
19
+
After deploying, add your deployed Lambda function ARN to which this event is attached to the Service Endpoint under Configuration on Amazon Developer Console.
18
20
19
21
```yml
20
22
functions:
21
23
mySkill:
22
24
handler: mySkill.handler
23
25
events:
24
-
- alexaSkill
26
+
- alexaSkill: amzn1.ask.skill.xx-xx-xx-xx-xx
25
27
```
26
28
27
29
You can find detailed guides on how to create an Alexa Skill with Serverless using NodeJS [here](https://github.com/serverless/examples/tree/master/aws-node-alexa-skill) as well as in combination with Python [here](https://github.com/serverless/examples/tree/master/aws-python-alexa-skill).
30
+
31
+
## Enabling / Disabling
32
+
33
+
**Note:** `alexaSkill` events are enabled by default.
34
+
35
+
This will create and attach a alexaSkill event for the `mySkill` function which is disabled. If enabled it will call
36
+
the `mySkill` function by an Alexa Skill.
37
+
38
+
```yaml
39
+
functions:
40
+
mySkill:
41
+
handler: mySkill.handler
42
+
events:
43
+
- alexaSkill:
44
+
appId: amzn1.ask.skill.xx-xx-xx-xx
45
+
enabled: false
46
+
```
47
+
48
+
## Backwards compatibility
49
+
50
+
Previous syntax of this event didn't require a skill ID as parameter, but according to [Amazon's documentation](https://developer.amazon.com/docs/custom-skills/host-a-custom-skill-as-an-aws-lambda-function.html#configuring-the-alexa-skills-kit-trigger) you should restrict your lambda function to be executed only by your skill.
51
+
52
+
Omitting the skill id will make your Lambda function available for the public, allowing any other skill developer to invoke it.
53
+
54
+
(This is important, as [opposing to custom HTTPS endpoints](https://developer.amazon.com/docs/custom-skills/handle-requests-sent-by-alexa.html#request-verify), there's no way to validate the request was sent by your skill.)
-[Available Status Codes](#available-status-codes)
36
+
-[Using Status Codes](#using-status-codes)
37
+
-[Custom Status Codes](#custom-status-codes)
38
+
-[Setting an HTTP Proxy on API Gateway](#setting-an-http-proxy-on-api-gateway)
39
+
-[Share API Gateway and API Resources](#share-api-gateway-and-api-resources)
40
+
15
41
_Are you looking for tutorials on using API Gateway? Check out the following resources:_
16
42
17
43
> -[Add a custom domain for your API Gateway](https://serverless.com/blog/serverless-api-gateway-domain/)
@@ -321,7 +347,7 @@ functions:
321
347
identityValidationExpression: someRegex
322
348
```
323
349
324
-
You can also use the Request Type Authorizer by setting the `type` property. In this case, your `identitySource` could contain multiple entries for you policy cache. The default `type` is 'token'.
350
+
You can also use the Request Type Authorizer by setting the `type` property. In this case, your `identitySource` could contain multiple entries for your policy cache. The default `type` is 'token'.
325
351
326
352
```yml
327
353
functions:
@@ -497,6 +523,7 @@ This method is more complicated and involves a lot more configuration of the `ht
- [Available Status Codes](#available-status-codes)
659
-
- [Using Status Codes](#using-status-codes)
660
-
- [Custom Status Codes](#custom-status-codes)
661
-
- [Setting an HTTP Proxy on API Gateway](#setting-an-http-proxy-on-api-gateway)
662
-
- [Share API Gateway and API Resources](#share-api-gateway-and-api-resources)
663
+
- API Gateway docs refer to "WHEN_NO_TEMPLATE" (singular), but this will fail during creation as the actual value should be "WHEN_NO_TEMPLATES" (plural)
663
664
664
665
### Responses
665
666
@@ -857,11 +858,11 @@ Now that you have these two CloudFormation templates defined in your `serverless
857
858
858
859
## Share API Gateway and API Resources
859
860
860
-
As you application grows, you will have idea to break it out into multipleservices. However, each serverless project generates new API Gateway by default. If you want to share same API Gateway for muliple projects, you 'll need to reference REST API ID and Root Resource ID into serverless.yml files
861
+
As your application grows, you will likely need to break it out into multiple, smaller services. By default, each Serverless project generates a new API Gateway. However, you can share the same API Gateway between multiple projects by referencing its REST API ID and Root Resource ID in `serverless.yml` as follows:
861
862
862
863
```yml
863
864
service: service-name
864
-
provider:
865
+
provider:
865
866
name: aws
866
867
apiGateway:
867
868
restApiId: xxxxxxxxxx # REST API resource ID. Default is generated by the framework
@@ -872,13 +873,14 @@ functions:
872
873
873
874
```
874
875
875
-
In case the application has many chilren and grandchildren paths, you also want to break them out into smaller services.
876
+
877
+
If your application has many nested paths, you might also want to break them out into smaller services.
876
878
877
879
```yml
878
880
service: service-a
879
-
provider:
881
+
provider:
880
882
apiGateway:
881
-
restApiId: xxxxxxxxxx
883
+
restApiId: xxxxxxxxxx
882
884
restApiRootResourceId: xxxxxxxxxx
883
885
884
886
functions:
@@ -892,10 +894,10 @@ functions:
892
894
893
895
```yml
894
896
service: service-b
895
-
provider:
897
+
provider:
896
898
apiGateway:
897
-
restApiId: xxxxxxxxxx
898
-
restApiRootResourceId: xxxxxxxxxx
899
+
restApiId: xxxxxxxxxx
900
+
restApiRootResourceId: xxxxxxxxxx
899
901
900
902
functions:
901
903
create:
@@ -906,28 +908,28 @@ functions:
906
908
path: /posts/{id}/comments
907
909
```
908
910
909
-
They reference the same parent path `/posts`. Cloudformation will throw error if we try to generate existed one. To avoid that, we must reference source ID of `/posts`.
911
+
The above example services both reference the same parent path `/posts`. However, Cloudformation will throw an error if we try to generate an existing path resource. To avoid that, we reference the resource ID of `/posts`:
910
912
911
913
```yml
912
914
service: service-a
913
-
provider:
915
+
provider:
914
916
apiGateway:
915
-
restApiId: xxxxxxxxxx
917
+
restApiId: xxxxxxxxxx
916
918
restApiRootResourceId: xxxxxxxxxx
917
919
restApiResources:
918
920
/posts: xxxxxxxxxx
919
-
921
+
920
922
functions:
921
923
...
922
924
923
925
```
924
926
925
927
```yml
926
928
service: service-b
927
-
provider:
929
+
provider:
928
930
apiGateway:
929
-
restApiId: xxxxxxxxxx
930
-
restApiRootResourceId: xxxxxxxxxx
931
+
restApiId: xxxxxxxxxx
932
+
restApiRootResourceId: xxxxxxxxxx
931
933
restApiResources:
932
934
/posts: xxxxxxxxxx
933
935
@@ -936,18 +938,19 @@ functions:
936
938
937
939
```
938
940
939
-
You can define more than one path resource. Otherwise, serverless will generate paths from root resource. `restApiRootResourceId` can be optional if there isn't path that need to be generated from the root
941
+
You can define more than one path resource, but by default, Serverless will generate them from the root resource.
942
+
`restApiRootResourceId`is optional if a path resource isn't required for the root (`/`).
940
943
941
944
```yml
942
945
service: service-a
943
-
provider:
946
+
provider:
944
947
apiGateway:
945
-
restApiId: xxxxxxxxxx
948
+
restApiId: xxxxxxxxxx
946
949
# restApiRootResourceId: xxxxxxxxxx # Optional
947
950
restApiResources:
948
951
/posts: xxxxxxxxxx
949
952
/categories: xxxxxxxxx
950
-
953
+
951
954
952
955
functions:
953
956
listPosts:
@@ -966,4 +969,4 @@ functions:
966
969
967
970
```
968
971
969
-
For best practice and CI, CD friendly, we should define Cloudformation resources from early service, then use Cross-Stack References for another ones.
972
+
To be more in line with best practices and to be CI/CD friendly, we should define CloudFormation resources from an earlier service, then use Cross-Stack References from it in future projects.
Copy file name to clipboardExpand all lines: docs/providers/aws/events/cloudwatch-event.md
+21Lines changed: 21 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -111,3 +111,24 @@ functions:
111
111
state:
112
112
- pending
113
113
```
114
+
115
+
## Specifying a Name
116
+
117
+
You can also specify a CloudWatch Event name. Keep in mind that the name must begin with a letter; contain only ASCII letters, digits, and hyphens; and not end with a hyphen or contain two consecutive hyphens. More infomation [here](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-name.html).
0 commit comments