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

Jul 1, 2019

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:

    handler: handler.hello
      - alb:
          listenerArn: { Ref: HTTPListener }
          priority: 1
              - /first-path
              - /second-path
              - POST
              - PATCH
              bar: true
              name: alb-event-source

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.

  name: aws
    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.

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

Bug Fixes




Contributor thanks

With 18 different contributors, thanks again to all community members that got involved with this release to make it a success.

Subscribe to our newsletter to get the latest product updates, tips, and best practices!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.