Serverless Express API Boilerplate

About nine months ago, we started development on a Node.js Serverless application hosted (if that is the proper term for serverless) on AWS Lambda. I started laying the architecture by writing code directly in the Lambda console, then I progressed to uploading zip files of the code, and then, finally, I found the Serverless framework.

Before Serverless, I would manually (or via a script) create API endpoints in AWS API Gateway and then hook them up to the appropriate Lambda function. While I was able to take advantage of shared code, it seemed as though I was reinventing the wheel; solving a problem that had already been solved. I was.

Serverless provided several significant advantages and improvements over creating our own in-house framework and deployment system. It abstracted the process of deployment, CloudFormation template creation, and creation of API resources.

Once we switched over to the Serverless Framework, it was smooth sailing for months. We even converted our JS over to Typescript and implemented an end-to-end and unit test suite. It was all coming together and it felt as though it was working splendidly.

Until it didn't.

We had been adding API Endpoints but also DynamoDB resources to the serverless.yml file. While I had researched and recommended that this particular team switch over to using Dynamoose for creating the DynamoDB tables and for querying, it hadn't been implemented (priorities, priorities). In addition, we had continued to define API resources in the standard serverless.yml syntax.

All this came to a head one day when one member of the team told me that we couldn't deploy. Flabbergasted, I asked him why. It turned out that Serverless was telling us that we had a Resource limit exceeded error. Digging a bit deeper, I found out that Cloudformation templates have a maximum resource count of 200 entities.

Evidently, all of our API endpoints combined with our DynamoDB definitions amounted to more than 200 resources. This particular API wasn't even that big.

What was a developer to do?

Fortunately, I had found this article earlier on Medium and I saw a way to define innumerable API endpoints without surpassing the Cloudformation Template limit. So I put together a boilerplate repo that our team could base their work off of and it worked splendidly.

One of the benefits was the ability to easily use an actual framework in our code that allowed for the usage of middlewares and other goodies. It reduced quite a bit of code that we'd need to maintain while improving the layout of the codebase.

Along with that, it was easier to define routes and test them since they were located in one easy to use file (App.ts in this case). In addition, it allowed for an MVC like architecture which improved not only our separation of concerns but also our ability to deliver code faster.

All in all, it was a worthwile endeavor. I hope this helps you out!