The Serverless Framework v1.45.0 release adds the new ALB event source, support for API Gateway Websocket Logs, deployment packages hosted on S3 and custom configuration files. In addition to those features we’ve addressed a number of bug fixes and other enhancements. 3 bug fixes and 2 enhancements were merged and are now available through our v1.45.0 release.
Important: Due to the Node.js release cycle we’ve dropped support for Node.js version 4 which is no longer in LTS. Going forward we’ll slowly phase out non LTS Node.js version in the future to ensure that we keep on innovating while keeping our users secure.
Please ensure that you’re using an up to date Node version when working with the Serverless Framework.
ALB event source
API backends are one of the top use cases for serverless architectures. In fact, serverless computing really took off once AWS introduced the integration between AWS Lambda and API Gateway, making it possible to create whole web applications which auto-scale, are easy to maintain and only generate expense when actually used.
Nowadays, API Gateway usually plays an integral part in such API backends. However, due to API Gateway being such a configurable and feature-rich service it can be costly if it’s only used to dispatch incoming data to Lambda functions.
At the last re:Invent Amazon announced the integration between Application Load Balancers and Lambda functions. Rather than using ALBs to dispatch traffic between different compute instances (usually EC2) it’s now possible to use an ALB as a gateway for incoming HTTP traffic which can then be forwarded to Lambda functions. The great news is that it’s usually an order of magnitude cheaper to use ALBs as API Gateways compared to the AWS API Gateway service.
The Serverless Framework v1.45.0 introduces the new alb event source which makes it easy to hook up a Lambda function with an ALB listener.
The following example shows how the alb event source is used to create a GET event at an ALB listener:
functions:
test:
handler: handler.hello
events:
- alb:
listenerArn: <listener-arn>
priority: 1
conditions:
path: /helloNote that you have to update your Lambda handler code slightly to adhere to the format the ALB expects:
module.exports.hello = async () => ({
isBase64Encoded: false,
statusCode: 200,
statusDescription: "200 OK",
headers: { "Set-cookie": "cookies", "Content-Type": "application/json" },
body: "Hello from a Lambda triggered via an ALB event"
});If you want to learn more about ALBs and their usage in a serverless architecture feel free to read through the excellent writeups by Jeremy Thomerson.
API Gateway Websocket logs
Back in v1.42.0 we’ve introduced support for API Gateway REST API logs. Setting them up was as easy as adding the following lines of code to the provider property:
provider:
logs:
restApi: trueWith Serverless Framework v1.45.0 we complement this feature with support for API Gateway Websocket logs. Enabling logging for Websockets follows the same pattern as the REST API logs:
provider:
logs:
websocket: trueNote that it’s also possible to combine a REST API with a Websocket API in one service and enable logging for both:
provider:
logs:
restApi: true
websocket: trueDo you have any wishes for further configurability or extra features? We’d love to hear your thoughts about Websocket logs in our feedback issue.
S3 hosted deployment packages
The Serverless Framework makes it possible to separate the package and deployment process with the help of the serverless package and serverless deploy --package commands.
This feature is often used in CI / CD setups where one service creates the deployment artifact which is then consumed by another service and carried out via a deployment.
When using this kind of configuration, the inevitable question of where to store the deployment artifact comes up. With Serverless Framework v1.45.0 we introduce the possibility to pull down deployment artifacts which are stored in an S3 bucket.
Using this feature only requires you to set the package path to the corresponding .zip object in a S3 bucket:
package:
artifact: <s3-object-url>Note that the packaging itself wasn’t changed. This means that it’s still possible to package functions individually when using S3 hosted deployment artifacts:
functions:
test:
handler: handler.hello
package:
artifact: <s3-object-url>
events:
- http: GET hello
package:
individually: trueWe kept the implementation agnostic, meaning that we can extend it to pull zip files from any remote location. Let us know if that’s something you’re interested in.
Custom configuration files
It has been frequently requested to make possible to configure multiple services within the scope of a single project.
With a single serverless configuration (aimed to cover single service) it couldn’t be done easily, therefore we’ve enriched Serveless CLI with a --config option, that allows you yp pass a custom configuration filename to be used for given deploy or package command.
This results in the ability to pass individually crafted and specialised configuration files under different circumstances for the same service:
# Deploy API
serverless deploy --config serverless.api.yml
# Deploy Workflow A
serverless deploy --config serverless.workflow-a.ymlBug Fixes
- #6192 Adding a validation to validation.js script +20/-0
camilosampedro
- #6212 Use common prefix for log groups permissions at Lambdas' execution roles +30/-114
rdsedmundo
- #6222 Update Scala version to 2.13.0 for aws-scala-sbt template +5/-5
NomadBlacky
Enhancements
- #6196 Add support for S3 hosted package artifacts +171/-7
pmuens
- #6216
--configoption +158/-86dschep
Documentation
Features
- #6073 Add Application Load Balancer event source +815/-6
- #6088 Add support for Websocket Logs +319/-30
Contributor thanks
We had some community contributions included in this release and want to say thanks once again to those of you that help make the framework better. Its truly appreciated.
