I like using the “serverless monolith” architecture. You use a catch-all API gateway hooked up to a single lambda. You write it the same as any standard HTTP se

I like using the “serverless monolith” architecture. You use a catch-all API gateway hooked up to a single lambda. You write it the same as any standard HTTP server and let an adapter handle the lambda bits[1]. During development you run it as a regular HTTP server and connect directly to localhost. To deploy it all you need is a shell script that zips and uploads your binary to lambda. All state is stored in DynamoDB. One log stream for everything. The downside is dealing with AWS events. There’s a few ways to handle it. You can write it into your monolith, toggling behavior with say an environment variable. You can sometimes work around it, for example avoiding the S3 file uploaded event by having clients ping your HTTP API on upload completion. Of course, there are trade offs for all the techniques. You can easily reconfigure a lambda to retry on failure but you’d have to manually implement that client-side. You can also always just add another lambda if you’re ready. To put it another way: you probably don’t need to write that record to a queue which gets written to DynamoDB, whose stream calls another lambda etc etc. Just do that stuff within a regular old HTTP handler until the fanciness is absolutely necessary. For personal projects, I appreciate how serverless scales to zero. I don’t have to worry about axing projects with minimal usage. [1] for example https://github.com/akrylysov/algnhsa https://github.com/akrylysov/algnhsa or https://github.com/awslabs/aws-lambda-go-api-proxy https://github.com/awslabs/aws-lambda-go-api-proxy