Serverless Framework v1.46.0 - Extended ALB configurability, Support for external Websocket APIs, Local plugins via relative paths & More

The Serverless Framework v1.46.0 release adds new ways to configure conditions for ALB events, support for externally managed Websocket APIs and local plugins which can be referenced via relative file paths. We’ve also addressed a number of enhancements and bug fixes. In total 5 bugs were fixed and 5 enhancements were merged and are now available through our v1.46.0 release.

Please ensure that you’re using an up to date Node version when working with the Serverless Framework.

Support for new ALB conditions

In our last Serverless Framework v1.45.0 release we introduced support for the ALB event source which is a compelling replacement for the sophisticated, but costly AWS API Gateway service. While API Gateway is still superior for complex API setups one can achieve quite a lot with the much cheaper ALB service offering.

This release extends the ALB event source capabilities by adding support for different conditions which need to be met in order for the ALB to route incoming requests to the connected Lambda function. ALB event sources can now be configured to accept different headers, IP addresses, methods, query strings and multiple paths.

The following shows a complex ALB setup in which we leverage the new config options:

functions:
  test:
    handler: handler.hello
    events:
      - alb:
          listenerArn: { Ref: HTTPListener }
          priority: 1
          conditions:
            path:
              - /first-path
              - /second-path
            method:
              - POST
              - PATCH
            query:
              bar: true
            ip:
              - 192.168.0.1/0
            header:
              name: alb-event-source
            host:
              - example.com

Do you want to learn more about ALB and how it can save you money if you use it as an API Gateway replacement? You can read more about the ALB event source and its capabilities in our v1.45.0 release blog post.

External Websocket APIs

Most Serverless Framework applications start with one serverless.yml file in which the whole application with all its infrastructure components is described. While this is sufficient in the beginning it’s recommended to split the whole application up into different services and use a separate serverless.yml file for every service.

Splitting up an application into different services makes it a requirement for certain resources to be shared between such services. One very common resource type which needs to be shared across services are APIs.

The Serverless Framework already supports an easy way to introduce an external REST API to a service, making it possible to re-use and extend that API within the service.

In our v1.46.0 release we’re extending the support for external APIs to include Websocket APIs.

Introducing an existing Websocket API into an existing service is as easy as using the websocketApiId config parameter under the provider.apiGateway property.

provider:
  name: aws
  apiGateway:
    websocketApiId: xxxxxxxxxx # Websocket API resource id

Do you want to learn more about best practices on how to split up your API-driven application into different services? Our API Gateway documentation provides some more insights into this.

Local plugins via relative paths

Our Serverless Framework plugin architecture provides an easy way to extend Serverless in various different ways to meet specific business needs.

The community has been working hard on hundreds of plugins to help other Serverless developers achieve certain goals and make Serverless development easier than ever.

While one can easily distribute and consume plugins via npm it’s sometimes necessary to work with plugins which are project specific or maybe not yet distributed via npm. Perhaps you wish to maintain your own plugins itnernally?

Up until now there was a clear distinction between npm hosted plugins and local plugins. The only way to work with local plugins was to leverage the plugin.localPath configuration. Using that meant that only local plugins were supported for the whole service and npm hosted plugins were no longer an option..

Our v1.46.0 release finally makes it possible to mix npm hosted and local plugins in an easy way.

Here’s an example where we use the infamous serverless-offline plugin alongside a plugin which is project specific and stored in a separate directory of our service.

plugins:
  - serverless-offline
  - ./plugins/acme/auditing

Bug Fixes

#4427 Split IAM Policy from IAM Role & Improve DependsOn for Streams +120/-51 alexcasalboni
#6244 Fix duplicate packaging issue +52/-17 alexdebrie
#6255 Fix lambda integration timeout response template +27/-2 medikoo
#6268 Fix #6267 +1/-1 JonathanWilbur
#6281 Do not set tty on stdin if no tty available +2/-2 jpetitcolas

Enhancements

#6200 Remove default stage value in provider object +109/-111 mydiemho
#6258 Fix: Update azure template +6/-138 tbarlow12
#6280 Remove package-lock.json and shrinkwrap scripts +3/-9384 medikoo
#6285 Use naming to get stackName +2/-2 joetravis
#6293 Add ip, method, header and query conditions to ALB events +270/-11 cbm-egoubely

Documentation

#6225 Update docs | dont use provider.tags with shared API Gateway +2/-0 OskarKaminski
#6228 Fix formatting issue with Markdown link +2/-2 awayken
#6275 fixed a typo 🖊 +1/-1 floydnoel
#6279 Update variables.md +1/-1 ElinksFr
#6286 Added correction based on community feedback +1/-1 garethmcc
#6288 Remove README redundant link +0/-1 Hazlank
#6292 Fix typo in link to ALB docs +1/-1 schellack