5 Serverless Plugins Every Developer Should Know

1. Caching — API Gateway
2. Required Parameter Validation — API Gateway
3. Documentation — API Gateway
4. Pruning Lambda versions — Lambda
5. Split Stacks — Serverless

API Gateway Caching
This improves performance and reduces the traffic sent to your back end. Cache settings allow you to control the way the cache key is built and the time-to-live (TTL) of the data stored for each method. API Gateway also exposes management APIs that help you invalidate the cache for each stage. Caching is available for REST APIs in API Gateway.

package.json

"serverless-api-gateway-caching": "^1.5.0"

serverless.yml

custom:
 apiGatewayCaching:
  enabled: true
  clusterSize: '0.5'
  ttlInSeconds: 300
  apiGatewayIsShared: true
  dataEncrypted: true
  perKeyInvalidation:
   requireAuthorization: false
plugin:
 - serverless-api-gateway-caching

clusterSize — size of the cache cluster. Default = 0.5GB.
ttlInSeconds — time to live of the data stored in the API Gateway cache. Default = 300 seconds. Maximum = 3600 seconds.
apiGatewayIsShared —
dataEncrypted — encrypt the data being stored in the cache
perKeyInvalidation — handle the cache key invalidation
requireAuthorization — whether an authorization is required to invalidate the cache per cache key
true - authorization is required
false - authorization is not required
handleUnauthorizedRequests (if above property is true) — handle the unauthorized request to invalidate the cache
Ignore - ignores the request to invalidate the cache key.
IgnoreWithWarning - ignores the request to invalidate and adds a warning header in the response.
Fail - fails the request to invalidate the cache key with a 403 response status code.

Head to the below link to understand the plugin in detail:

serverless-api-gateway-caching

Documentation & Request Validation — Parameter & Body
Request Validation is to enable the validation of the request body and parameters in the APIGW. You can avoid doing the request validations in your Lambda functions by using this feature.

Define the RequestValidators in the resources block of your serverless.yml. You have the option to validate either the request body or the request parameters. I have defined three validators here with a combination of validating either body or parameters or both.

serverless.yml

Resources:
 RequestBodyValidator:
  Type: "AWS::ApiGateway::RequestValidator"
  Properties:
    Name: '${self:custom.appname}-req-body-validator'
    RestApiId: !Ref ApiGatewayRestApi
    ValidateRequestBody: true
    ValidateRequestParameters: false
 RequestParameterValidator:
  Type: "AWS::ApiGateway::RequestValidator"
  Properties:
    Name: '${self:custom.appname}-req-parameter-validator'
    RestApiId: !Ref ApiGatewayRestApi
    ValidateRequestBody: false
    ValidateRequestParameters: true
 RequestBodyParametersValidator:
  Type: "AWS::ApiGateway::RequestValidator"
  Properties:
    Name: '${self:custom.appname}-req-body-parameter-validator'
    RestApiId: !Ref ApiGatewayRestApi
    ValidateRequestBody: true
    ValidateRequestParameters: true
plugins:
  - serverless-reqvalidator-plugin
  - serverless-aws-documentation

package.json

"serverless-reqvalidator-plugin": "^1.0.3"
"serverless-aws-documentation": "^1.1.0"

AWS Documentation plugin is also required here, as we have to define the request models to help with the request body validation.

Using the request validator:

userLogin:
  handler: api/auth.login
  name: login
  description: api to login user
  events:
    - http:
        method: post
        cors: true
        path: auth/login
        reqValidatorName:'RequestBodyValidator'
        documentation:
          summary: User Login Request
          description: User Login Request
          requestModels: "application/json": "LoginReq"

models.yml
Define your request model mentioning the properties and their types. Please note that the required properties are also defined as separate property of the schema.

models:
  -
   name: LoginReq
   contentType: "application/json"
   schema:
    "$schema": "http://json-schema.org/draft-04/schema#"
    title: "Login Request"
    type: object
    required:
      - userName
      - password
    properties:
      userName:
        type: string
      password:
        type: string

In your serverless.yml, declare the models under documentation within custom section.

custom:
  documentation:
    models: ${file(models.yml):models}

Go to the following link to learn more:

serverless-reqvalidator-plugin

Pruning Lambda Versions

AWS creates a new version of your lambda function each time that you publish the function. Each function version and layer version consumes storage. The default storage quota is 75GB. Though the quota can be increased, the storage of unnecessary function versions is not efficient. Imagine having a lambda function with 50 old versions, which is never going to be used in the future. It is better to maintain fewer function versions. So you can revert to an immediate old version in case the new function version deployed has issues. Now, if you go about deleting these 50 versions manually, you’re going to be at it for a while. Instead, you can let this prune plugin do its job.

serverless.yml

custom:
   prune:
     automatic: true
     includeLayers: true
     number: 3
plugin:
 - serverless-prune-plugin

package.json

"serverless-prune-plugin": "^1.4.3"

You can mention the number of versions you want to keep. The rest of the old versions are automatically deleted. This plugin should be listed at the end of the plugin list. The pruning process happens at last after the stack is updated and the new versions are deployed.

Learn more about the plugin:

serverless-prune-plugin

Split Stacks Plugin

AWS enforces a limit of 200 resources per CloudFormation stack. Unlike many AWS limits, this cannot be increased upon request. Fortunately, AWS is aware of the fact that many real-world applications will have CloudFormation stacks that need to contain more than 200 resources and provide a solution:

To specify more resources, separate your template into multiple templates by using, for example, nested stacks.

Since the Serverless Framework has a rich ecosystem of tools and plugins, it’s no surprise that an open-source plugin exists to do exactly that.

ENTER serverless-plugin-split-stacks. The plugin provides a number of strategies for splitting a stack.

serverless.yml

custom:  
  splitStacks:
    nestedStackCount: 50
    perGroupFunction: true
plugin:  
  - serverless-plugin-split-stacks

package.json

"serverless-plugin-split-stacks": "1.9.3"

nestedStackCount: Controls the number of created nested stacks

To know more about the migration strategies, head to the link below:

serverless-plugin-split-stacks