What constitutes ‘native’ serverless is probably up for debate and constitutes a bit of a spectrum. There are ways to take advantage of managed services such that lambda function usage is minimized, but there are plenty of use-cases that require custom logic e.g. integrating with third-party services.
I’d start by asking yourself what your existing application does, and how large your time investment is going to be in order to refactor to be as ‘serverless’ as possible. If this is a project that you are using for purely learning purposes, you may want to do a full conversion to maximize your learning. If this is a revenue generating application for a business, this may be an inappropriate use of resources for the payoff.
That said, the main differences between current best-practice serverless and usage of serverless-express will be:
- Presence of additional dependencies. This will take some additional time to resolve at runtime [1], will need to be managed correctly at deployment time (packaging), and will require additional effort to update/patch/audit (security).
- Permission granularity - as all route management is delegated to express, you will not be able to set permissions granularly for each route at the infrastructure level.
- You will not be able to set resource limits on a per route basis
On the other hand:
- You will avoid large cloud formation templates
- Take advantage of your existing tooling and knowledge of express
Although it does depend on what the application is/does, it is unlikely that you will notice much of a cold-start penalty over single-purpose lambda functions, and would probably be a case of premature optimization. Part of the serverless mindset is about focusing on value - so if it were me doing this, I'd do as little as possible to get the application running in lambda - start instrumenting routes with X-Ray and CloudWatch [2], and then optimize the routes that require it.
From a learning perspective, if you do choose to use serverless-express, you will likely miss out on the opportunity to learn more about service-integrations, VTL transformations, request/response mapping etc that you would be exposed to if you took the more segmented approach. You can build some pretty cool things with just API Gateway and DynamoDB - without even having to touch a lambda function.
That’s not to say that using express in this way is a bad thing - AWS themselves note that this is a valid way to build a serverless application and new features like the HTTP API feature for API Gateway [3] help with this. In fact, the [real world serverless application [4] example that was published by AWS follows the single function principle, albeit for Java rather than an express application.
[1] https://www.freecodecamp.org/news/just-how-expensive-is-the-full-aws-sdk-3713fed4fe70/
[2] https://theburningmonk.com/2019/11/check-list-for-going-live-with-api-gateway-and-lambda/
[3] https://aws.amazon.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/
[4] https://github.com/awslabs/realworld-serverless-application
