Various serverless services running your web app on AWS • Fargate • App Runner • Lambda <- Today's target • Used in combination with API Gateway in our project
Problems to develop code on Lambda • Vendor Lock-in • Complexity is getting higher • The code is scattered and lacks readability if there are many functions • Need to know more than web app knowledges • such as Runtime Interface Client, Serverless Framework, SAM and etc...
Just tried it! # Add the following into your Dockerfile COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.7.0 /lambda-adapter /opt/extensions/lambda-adapter
However ... • Cold start: Rails is not fast & the extension brings extra costs • Are there any servers optimized for a single process? • There are many servers that run on multiple processes/ threads, but I'm not sure about a server suitable for a single process? • Single Dockerfile (this is a minor issue) • Same Dockerfile can't be used for job processes because the extension always starts up and handles events
How Lamby works Lamby is an AWS Lambda Web Adapter for Rack applications. — Referenced from: Lamby's README.md • Rack server converts Lambda events into Rack requests, and vice versa • So your rails app code and development style are not affected
It solves the problems • Remove extra cost on cold starts with Lambda Web Adapter • No need to bother finding a suitable server for single process; instead, Lamby starts the Rails app • Can use Single Dockerfile by overriding CMD
Some problems encountered when using Lamby • Lamby passes URL queries percent-decoded • We solve this with a monkey patch in our project • Cold start times are long • Following the documentation: enable Bootsnap and create cache during Docker build phase • AWS Lambda Ruby RIC does not currently support Ruby 3.x
Summary • Approaches to Rails Web Development on Lambda • AWS Lambda Web Adapter • Lamby • Continue to use rails development skills • Code remains well-organized and keeps readability • Mitigate vendor lock-in