With the v1.39 release we added support for Docker-based local invocation, which makes it possible to support any runtime and AWS Lambda Layer combination with the
invoke local command, enhanced the Framework’s AWS websockets support to include websockets authorizers, added support for AWS X-Ray tracing, and addressed a number of additional bug fixes and enhancements. With the v1.40 release we addressed additional bug fixes and enhancements. 4 bug fixes and 14 enhancements to be exact, across both v1.39 and v1.40.
The v1.39.1 release of the Serverless Framework expanded
invoke local support to include ALL supported AWS runtimes and layers.
Previously we provided support for local invocation on a per-runtime basis. We started with Node.js and extended this further to add Python and Java. In doing so we studied and implemented the AWS Lambda specific behavior for every runtime so that
invoke local could be run from the Serverless CLI and return the exact same result as
With v1.39.1 we now support Docker-based local invocation, which makes it possible for the Serverless Framework to support any runtime and AWS Lambda Layer combination. The implementation itself leverages the
lambci/lambda Docker images.
Docker-based local invocations are enabled by default for runtimes that weren't previously supported. It can also be enabled with the
--docker flag for already supported Node.js / Python / Ruby and Java runtimes. Docker-based invoke local also includes support for Lambda Layers. Both local, as well as external Layers referenced via an ARN, are supported. You can learn more about using Docker-based local invocation with the Serverless Framework in our documentation.
In v1.39.1 we completed the websockets story by adding support for websockets authorizers. It works like http Authorizers. The only key difference is that AWS only supports websockets authorizers for the
Here's an example yaml configuration that uses authorizers to protect connection requests:
functions: connect: handler: handler.connect events: - websocket: route: $connect authorizer: auth # you can also provide an arn if your function is not part of this service auth: handler: handler.auth
With this configuration, any connection request to the websockets URL must include the
Auth header by default, otherwise connections will be rejected automatically. If it does include the header, your
auth function will be invoked first. If this invocation succeeds by returning a valid policy statement, your
connect function will be invoked, otherwise, the connection will be rejected. When using the
wscat client, you can connect with the following command:
wscat -c <wss-rul> -H Auth:secret
You can change this header to any other value, or to be a query string by specifying the
functions: connect: handler: handler.connect events: - websocket: route: $connect authorizer: name: auth identitySource: - "route.request.querystring.Auth" auth: handler: handler.auth
With this configuration, you need to specify a querystring instead of a header:
wscat -c <wss-rul>?Auth=secret
Mature serverless applications tend to utilize a large number of internal and external cloud services. The larger the application, the harder it becomes to get useful insights into an application’s overall performance. One way to get better end-to-end visibility into the performance of a serverless application, running on AWS, is to instrument it to use AWS X-Ray, which will trace requests as they flow through your serverless application and generate a Service Map.
In Serverless Framework v1.39.1 we added AWS X-Ray tracing support for AWS Lambda. X-Ray tracing can be enabled service-wide or on a per-function level. To enable X-Ray tracing for all your Service’s Lambda functions you just need to set the corresponding tracing configuration on the
provider: tracing: lambda: true
If you want to setup tracing on a per-function level you can use the
tracing config in your function definition:
functions: myFunction: handler: index.handler tracing: true
true translates to the
Active tracing configuration. You can overwrite this behavior by providing the desired configuration as a string:
functions: myFunction: handler: index.handler tracing: PassThrough
Also note that you can mix the
function-level configurations. All functions will inherit the
provider-level configuration which can then be overwritten on an individual function basis:
service: name: my-tracing-service provider: name: aws stage: dev runtime: nodejs8.10 tracing: lambda: true functions: myFunc1: # this function will inherit the provider-level tracing configuration handler: index.func1 myFunc2: handler: handler.func2 tracing: PassThrough # here we're overwriting the provider-level configuration
It's recommended to setup X-Ray tracing for Lambda with the aforementioned
tracing configuration since doing so will ensure that the X-Ray setup is managed by the Serverless Framework core via CloudFormation. You can learn more about X-Ray Tracing for AWS Lambda in our documentation.
Custom Response Headersinto
We had more than 18 contributors have their work go into this release and we can't thank each of them enough. You all make the community special.
Want to have your github avatar and name in the next release post? Check out these issues we are looking for help on!
Philipp Müns is a core developer at Serverless, Inc.