I’ve now deployed 2 applications that use the AWS API Gateway, both of which utilize Lambda and DynamoDB for the ‘backend’ and are, effectively, serverless from my point of view. This post will effectively be my review of the stack.
My biggest hurdle with DynamoDB is figuring out how to organize my data. I’m used to MongoDB, but DynamoDB is even more restrictive on how I can organize and search my data, and as such requires more forethought and planning. This isn’t a bad thing, but it does mean it isn’t as great for prototyping as MongoDB is since you have to come at it with a good plan on how the data will be arranged and queried before actually using it.
That said, it is super fast, relatively stable (ignoring the recent crippling outage a couple of weeks ago), and pretty simple to use.
The only other issue I have is that once you have a lot of projects using it, it would be nice if there was a way to organize tables by tag or project rather than having to prefix the names with labels in order to keep things sane.
DynamoDB doesn’t have to be the database you use for this stack, but it is what I went with as it is super cheap for my needs, and requires no administration once it is up and running.
I really like Lambda so far. I only use the node version, not java or python. I also only have used it in production with API Gateway, so I can’t really speak to the stream/triggered events it supports.
Managing the functions is a bit clunky. You either can manage a single inline file, or you can upload a .zip file that contains your function and any libraries it uses that aren’t already present. If there were a way to simply tie a function to a repository, that would make managing and deploying the code so much easier, especially for complex projects.
Speaking of projects, I’d also like a way to tag/group lambda functions in some way. And having the ability to share libraries within a group would be awesome, and be a huge timesaver. As it is, each function needs to be manually managed.
That said, the introduction of cron-style calls, and the API Gateway integration has been fantastic and lets me implement custom backends without having to worry about a server, or even a framework.
This is the magic that makes the whole stack work well. Being able to design the resources and methods in a clean and visual way is fantastic, and makes documenting things relatively easy. Implementing some things, like CORS, is a bit of a pain and could be made simpler, but that’s not too big of a deal.
It took me some time to get used to the fact that while it is possible to slurp in all the parameters/headers/body data in a request, this isn’t the best way to do things. Like with DynamoDB, coming at the API implementation with a solid plan is not just a good idea, but a requirement in order to get things working smoothly and cleanly.
I’m going to work on putting together a tutorial to build a simple API backend with these services soon and will post when done.