![Cover image for 🔥 Serverless boilerplate with TypeScript and Express [Open Source] 🚀](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Frepository-images.githubusercontent.com%2F341987132%2F6a6a5100-777a-11eb-8b21-8c8c71881eb2)
A Serverless boilerplate to build a backend in Express JS with TypeScript. Built with developer-experience in mind with ESLint, Prettier, Husky and...
For further actions, you may consider blocking this person and/or reporting abuse
why do you use express for serverless?
I am also curious to know. Is this type of setup going to route all requests to a single lambda?
Yes, I've raised the same question. Should I use Express or not? Definitively depend on the scenarios, use cases and context.
With Express JS, you can have all of your routes defined in Expressjs with only one single lambda. So one cold start instead of multiple one. But the cold start is longer...
So it means if one of your endpoints is more greedy, heavier, longer to process, you need to set your single lambda with the same configuration for all existant endpoints ?
Imagine you have some export or import functions in your app, which requires 1go ram and 10minutes to live, it will be also applied for a simple get customer by id for example ?
So you can’t optimize. Moreover, the coldstart, but you mentionned it.
What are your limits to choose express over serverless framework then ? When won’t you use expressjs ?
As I said it's totally based on your use cases and context.
I don't have a use case like you mention it which requires 1 go ram and 10 minutes to live. But, you can still have a catch all routes endpoint and another endpoint for the greedy, heavier, longer endpoint.
You can have one endpoint for all your routes, you can also have one endpoint for one route... Or, you can one endpoint for multiple routes...
You don't need to oppose the two models, you can mix them together.
For example, one endpoint for 3 routes, another endpoint for 2 routes and the last endpoint for 5 routes. You can mix it based on your context.
I didn't choose Express JS over Serverless framework. I add Express in Serverless Framework: I'm just getting the best of the two worlds!
In my opinion you should not use Express for cases where you're using an API Gateway and/or for cases where latency is a real factor for user experience.
For Lambda functions (AWS) or other Function engines, It's additional overhead of code that is simply not needed. Hence, there are serverless specific solutions that reduce code overhead and only provide utility functions.
A very well known library that is used for serverless functions is Middy
middy.js.org/
For route switching, for instance when you're using an API Gateway, the context data already provides sufficient information to do simple If or Case switching on the path and method without the need for a software router like Express.
nice