Lambda Middleware - Enterprise-CMCS/macpro-mako GitHub Wiki
The current lambda code has a lot of duplication and at the same time uses a lot of different ways to accomplish the same thing. The code is also hard to follow and uses a lost of custom code that could be streamlined and improved by using a third-party tool.
| Middy | Lambda API | Laconia | |
|---|---|---|---|
| Link | Middy | Lambda API | Laconia |
| License | MIT | MIT | Apache-2.0 |
| Last updated | 3/3/2025 | 2/8/2025 | 3/3/2025 |
| GitHub stars | 3.8k | 1.4k | 328 |
| Dependencies | 2,155 | 0 | 2,367 |
| Dependents | 8,731 | 551 | 20 |
| NPM weekly downloads | 31,767 | 35,006 | 158 |
| Major companies using | |||
| Sponsors | fourTheorem, AWS | ||
| Documentation | Good | README only | Okay |
| Tutorials | Many | Few | Some |
| Philosophy | Flexible | Structured | Structured |
| CORS | Supports CORS | Supports CORS | Supports CORS |
| Logging | Automatically captures key fields from Lambda context, cold and starts. Optional logging Lambda invocation events Optional sampling logs for specified percent of invocations error-logger passes logs from console.error to CloudWatch logsAlso provides support for tracing http(s) clients and generating segments for each request. Tracing functions via decorators, middleware, and manual instrumentation. Tracing AWS SDK v2 and v3 via AWS X-Ray SDK for Node.js. Also provides supports for creating metrics and aggregating up to 100 metrics using a single CloudWatch EMF object. Validating metrics against common metric definitions mistakes. Also provides supports for idempotency such as preventing Lambda handler from executing more than one on the same event during a time window. Ensuring Lambda handlers returns the same results when called with the same payload. Expiring in-progress executions if the Lambda function times out halfway through. |
Native JSON support for CloudWatch Logs Can generate access logs, error logs, and request/response logs |
Can support logging, but have to write it yourself |
| Error Handling | Built in error handling, and error handling supported at the middleware level to allow for specific error handling | Supports default error handling and custom error handling | Can support error handling, but must write it yourself |
| Included middleware | Official middleware to support metrics, logging, pre-warming Lambda functions, event normalizations, json body parsing, multipart body parsing, encoding responses, CORS, security headers, WebSockets, fetching data (DynamoDB, RDS, S3, Secrets Manager, STS), and validation Third-party middleware to support more lambda functionality, additional logging, and more data fetching functionality |
None | Supports connecting to S3, SNS, SQS, Kinesis, APIGateway, and DynamoDB |
| Customizable middleware | Allows customized middleware, specified for each handler inside the handler code | Allows customized middleware like Express, you can use middleware for all endpoints, matching endpoints, or single endpoints. | Supports “adapters” which are similar to middleware but using dependency injection |
| Other Pros | You can plug in changes a little at a time Flexible |
Similar to Express which is familiar to devs. | Structured with less configuration needed |
| Other Cons | You kind of need to implement all of the changes at once. You have to define the routing inside of the module. |
Big change from what we currently have, would need to implement it all at once |