elasticmq VS serverless-analyze-bundle-plugin

Since a majority of services rely on the same system services, we can leverage Docker to start all the needed project services prior running services with the offline command. The template ships with a base docker-compose.yml that stands up an instance of ElasticMQ to emulate Amazon SQS's API. The Docker image can be extended to include other services like DynamoDB, Redis, or PostgresQL and can be run using yarn infrastructure:build or yarn infrastructure:start depending on if it's your first run or not.

however...we have banned use of SQS. unlike S3/Minio, there's nothing API-compatible that we can run offline. (well, there's one thing, but it's in-memory / single node only and doesn't give us the durability/reliability we want with SQS). instead we use RabbitMQ because it's identical at the API layer no matter where we are. AWS has a hosted option for this but we haven't switched to it, because our existing self-managed Rabbit clusters are stable and well-understood.

Note that there is one minor drawback, though: Kysely will add 120KB in your Lambdas bundles (props to for serverless-analyze-bundle-plugin for helping me out with this 🙌). It is not a lot, but not negligible either as NodeJS Lambdas bundles above 5MB negatively impacts their cold starts. So you might want to re-evaluate adding Kysely to your bundles if your query is not changing often.

There are plenty of tools out there to optimize the size of your bundles. For instance the Serverless Analyze Bundle Plugin integrates with the Serverless Framework and helps you diagnose which of your NodeJS dependency is not properly tree-shaked.

One of the most important aspects of serverless development is keeping an eye on your bundle sizes and to reduce cold start times on Lambda. Keeping this in mind, the template utilizes serverless-esbuild and serverless-analyze-bundle-plugin to provide function analysis out-of-the-box. I opted for serverless-esbuild over serverless-bundle for a few reasons: