Serverless Framework v1.40

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.

Improved `invoke local` support

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 invoke.

While that works great for Node.js, Python and Java, AWS Lambda now supports any runtime, and AWS Lambda Layers makes it possible to further customize the Lambda experience.

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.

Authorizers Support for Websockets

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 $connect route.

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 identitySource property:

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

For more information on websocket support please check the docs, and for a simple yet complete example using websockets authorizers, check our websockets-authorizers example in the examples repo.

AWS X-Ray Tracing for Lambda

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 level:

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

Setting tracing to 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 provider- and 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.

Bug Fixes

#5880 Fix bug when using websocket events with functions with custom roles +32/-14 eahefnawy
#5883 Print customized function names correctly in sls info output +4/-5 dschep
#5899 [SLS-6891] fix regression with golang check on windows +27/-2 dschep
#5937 Align error logging +1/-1 dnicolson

Enhancements

#5351 Allow Fn::Join in SQS arn builder +77/-8 alexdebrie
#5509 Support API Gateway stage deployment description +46/-0 vkkis93
#5743 Allow individual packaging with TypeScript source maps +17/-29 therockstorm
#5840 Packaging exclude only config file being used +165/-72 danielcondemarin
#5860 Add AWS x-ray support for Lambda +335/-1 pmuens
#5862 Put Custom Response Headers into [Responses] +18/-18 etc-tiago
#5863 Invoke local docker +295/-32 dschep
#5865 Websockets: Support more route characters +18/-1 eahefnawy
#5867 Added websockets authorizer support +688/-28 eahefnawy
#5872 Enchancement/kotlin jvm maven updates +64/-14 paul-nelson-baker
#5885 Fix CloudFormation template normalization +63/-2 bokan
#5898 Support for asynchronous lambda invocation with integration type AWS +89/-3 snurmine
#5912 Support for Cloudwatch Event InputTransformer +258/-7 fivepapertigers
#5926 Add Serverless instanceId concept +151/-81 pmuens