The frontend is hosted on cloudfront, the backend is a lambda and you basically just pay for the database and certificate.
I don't want to manage a server or even a docker image. I just want my code to exist there so I like the idea
The frontend is hosted on cloudfront, the backend is a lambda and you basically just pay for the database and certificate.
I don't want to manage a server or even a docker image. I just want my code to exist there so I like the idea
I ended up moving a bunch of the logic into an ECS-hosted monolith. Probably cost a bit more (warm-up plugins meant that no customers still cost us money) but it vastly simplified things and made scaling up easier (can't set scaling thresholds with Lambda).
I treat Lambda purely as compute and ignore everything else related to "serverless". My Lambda's are monolith webapps using Axum Rust framework. Using cargo lambda I generate a static binary, upload to s3 and point the lambda at it. Sometimes I'll package as a docker image so can run in Lambda or locally by passing a `--aws-lambda` flag.
If serving HTML i'll use Function URLS with IAM auth and put a Cloudflare worker in front acting as the gateway. I also serve the static assets from cloudfront bucket i.e. static.example.com. Advantage is I use Cloudflare free tier so get denial-of-wallet prevention when my free credits run out. Using IAM auth also means the lambda doesn't execute if for what ever reason someone discovers the url and tries to DoS it so only get charged for the requests not run time.
Just a lambda, a switch in the handler that calls my routes and that's it. I could make it smarter but I don't really need to
agree, unfortunately in practice it's more common to throw the api behind k8s with containers
The 3 lambda instances aren't going to break your db