I'm working with a small Express TypeScript API that mainly handles CRUD operations and connects to AWS DocumentDB for its database. I'm looking to fully migrate this API to AWS Lambda, specifically using native Lambda handlers rather than a serverless wrapper for Express.
In my project, I've got files like mongoose models and types.ts that I use across almost all of my Lambdas. I'm curious about the best way to structure these files. Should I create a common layer for them? I'm already utilizing Lambda layers for database connections (cached for warm restarts) and some utility functions for logging.
Every time I look into migration guides, they mostly suggest serverless wrappers, which isn't what I need. Any guidance on this would be greatly appreciated!
4 Answers
It sounds like you’re using TypeScript, right? If you are, you really don’t need to rely heavily on layers for things like models. They’re usually meant for sharing large dependencies or binaries. Just use normal imports and ensure your build process handles tree-shaking. This way, you can bundle your dependencies and shared code effectively. Tools like esbuild work great for this, and both CDK and SAM support it out of the box.
You really need to consider why you're migrating in the first place. A genuine serverless approach might require a complete rewrite—potentially moving all dependencies to managed services, like MongoDB alternatives, and using API Gateway instead of Express. If all you need to do is make it serverless, maybe a wrapper could suffice. But if they’re set on pure Lambdas, understand it’s going to mean more work on your end. Also, layers are primarily for sharing code or dependencies, not for managing warm connections.
Honestly, I’d recommend avoiding layers in this case. They can complicate things more than necessary. It’s better to write a package for any shared libraries, treating them like a regular dependency. Store secrets in Secrets Manager and use SSM for configuration. And about your express confusion—just remember, wrapping your API might mean you’re still using Express in some capacity. If you want to eliminate it, make sure to refactor the routing and everything else accordingly!
Uploading everything into a single lambda could be an option if you stay within the size limits. Just be cautious with layers since versioning can be tricky. It might work for you, but managing them can be a pain.

Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically