orangejellyfish / serverless-starter Goto Github PK

I recently got this working with webpack-bundle-analyzer for a demo. Unsure if it's worth including the plugin by default because for Lambda functions it doesn't add as much benefit as it does for e.g. a front-end app. However, it can be useful to validate bundling/tree-shaking is working as expected.

The AWS JS SDK supports TCP connection reuse via the AWS_NODEJS_CONNECTION_REUSE_ENABLED environment variable. We could include this env var in the example Lambda function, or at the provider level so it applies to all functions.

It would be good to understand any possible downsides to this approach.

Currently, Dependabot opens PRs, we ignore them and then do periodic sweeping dependency upgrades which covers all (or most) of Dependabot's suggestions and the PRs get automatically closed. If we had some form of automated testing to verify the PRs that Dependabot raises, we could keep on top of them with more confidence.

We should also ensure that the serverless package is excluded from the Dependabot process because an upgrade to it requires additional changes (e.g. updating the pinned version in serverless.yml).

Lambda architecture can either be x86_64 (default) or arm64. The Arm architecture can be more cost effective. We should investigate this and determine whether it makes sense to switch to Arm by default.

In Serverless v3.0.0 the naming convention of API Gateway will switch from ${stage}-${service} to ${service}-${stage}. We should investigate this to determine if it will have any impact. If not, we can update the starter kit to opt-in to the new naming convention ahead of time as follows:

provider:
  name: aws
  # ...

  apiGateway:
    shouldStartNameWithService: true

The Serverless Framework has native support for CloudFormation stack policies which allow you to prevent the accidental removal or replacement of stack resources. We should consider adding a default policy that covers typically critical resources such as database tables or Cognito user pools.

Currently Webpack fails to compile the code if you use e.g. a static class property (which is an ECMAScript feature supported natively by Node 14). The @babel/preset-env transform also supports the parsing of static class properties if we opt-in with the shippedProposals option.

However, adding shippedProposals doesn't fix the Webpack compilation error. This may be because Webpack is using a different Babel config (inside the Webpack config) but I haven't had a chance to look into it any further yet.

AWS have released a Lambda runtime for Node.js 16. We should default to this because 16 is LTS.