The parking problem

If you are a web developer also involved in managing the servers hosting your apps, then the idea of "serverless" app hosting needs little introduction.

Using AWS Lambda in combination with AWS API Gateway is catching as a combination for deploying simple web apps. Besides the lack of a server to maintain, scaling is handled automatically, and you only pay for the requests actually made to the app.

My task was to review options suitable for serving a simple mix of static and dynamic content using Node.js. We're used to developing with the Express web server, so the new solution needed to be easy to transition to, since we would be maintaining this new service side-by-side with other Express apps.

For an excellent introduction to running an Express-style app on AWS Lambda and API Gateway, I recommend the post Server-free Express.js.

Legedemain and dpl

The tool I tried first was Legedemain. You can read an introduction to Legedmain by the author.

On the face, it sounds like a great fit: Legedemain helps you run Express apps on AWS Lambda. I soon found it wasn't a complete solution. It doesn't handle deployment to AWS Lambda and AWS Gateway currently.

Not to be immediately deterred, I tried pairing it with aws-lambda-deploy. But this only updates Lambda and not API Gateway.

Trying this approach made me realize I wanted an integrated approach that could manage API Gateway and Lambda together.


After some more looking I found serverless, which is a very popular framework for managing both AWS Lambda and API Gateway together. Although there a lot of docs, I ran into problems.

As a first impression, I crashed the project setup tool simply by pressing the Enter key.

Then I found the CLI tool can't even print out basic help information with compiling whole project.

serverless is not meant to run Express apps. Instead, you are encouraged to write more "native" logic. In theory, I like this idea. It's simpler with less abstraction and data translation. serverless has it's own Plugin and Hook system which can work like Express Middleware. API API Gateway and AWS Lambda already handle the translation of HTTP request to and from JavaScript objects, so they replace the role of Express. I was willing to adapt to this.

Serverless advocates very small Lambda functions that handle maybe just one route endpoint, or maybe a small collection handle the CRUD actions for a single type of entity. There are some good reasons for this. Small Lambda functions would start up faster. Since they spend less time executing, they cost less. Also, you can upgrade some functions without touching the others, further increasing uptime. serverless also let's you manage several Lambda functions a single project so you don't have to be concerned with how many Lambdas are stored and running on AWS.

Serverless has a name for an Express-style app with lots of routes served by a single server. They call that a "Monolithic app" and don't have many docs for monolithic apps. I opened the linked issue to suggest they improved such docs and my issue got tagged with "priority: low".

While Serverless has a lot of positives, the fact that the model is very different from Express-style apps was a downside for my team. Another downside is that much of the configuration involves editting somewhat complex JSON files. Here their otherwise verbose docs fail with some handwaving that you should be very familiar with the docs for API Gateway and Lambda configuration. So, rather than abstracting away API Gateway and Lambda behind a single interface and set of documentation, now you have three sites of documentation to reference. For something we may touch infrequently, there's too much required context to make changes that would be simple with Express.

The JSON structure includes such keys as name and customName. Since name is already a variable that be set to custom volumes, would you care to guess what the customName is? Better names would have been serverlessName and lambdaName which highlight the difference better.

While Serverless is popular and appears it will have a bright future, I found it would not be a good fit for us. For developers who work with Express 95% of the time, serverless has too many differences from traditional Express development to make it an easy addition to a workflow.

There seems to be a lot of momentum behind the serverless ecosystem and I expect to checking on it again in the future.


aglex is an acronym for Api Gateway Lambda EXpress.

While I'm afraid I may be the #2 user of this tool in the world, I can heartily suggest that perhaps you should be the #3.

By this point I had a clear sense of what I was looking for and aglex has it. Using this simple CLI tool, I was able to quickly deploy a (fairly) normal Express app. aglex than handled configuring and deploying both API Gateway and Lambda to bring the app online.

The documentation is a simple one-page README and it was beautifully sufficient.

After I set up project and it will be straightforward and familiar for co-workers to add a few more Express routes to the app when we need to and deploy the related changes to API Gateway and Lambda. No deep dive into complex JSON structures or the diving into the depths of the API Gateway and Lambda docs is required.

That said, as newer, less popular project aglex has it's own rough edges which I hope get smoothed out soon:

I also had difficulty serving a static JSON file, but was eventually able to do so. It appears primarily designed to return JSON. The configuration file explicitly mentions serving static files, so it appears this is a supported use-case that I expect to improve in the future.

Using rsnapshot with systemd

Published on August 26, 2016