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
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.
As a first impression, I crashed the project setup tool simply by pressing the Enter key.
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 is already a variable that be set to custom volumes, would you care to guess what the
customName is? Better names would have been
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 have a pending pull request which fixes setup on case-sensitive filesystems
- Version 0.2.0 add support for an API Gateway deploy command, but it isn’t documented yet
- It defaults to the Node.js 0.10 environment instead of Node.js 4.3
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.