Since I was unfortunate to work with AWS, I'd put some info about request handling in such env. Note, that AWS Lambda supports uploading ZIP file with our code and deployments using Docker. This post is about Docker deployments.
AWS Lambda is a way of writing serverless apps. Meaning you don't have any control of the hardware/VM your app starts on. AWS spins up some hardware, downloads your code there, runs it and stops the app after that. It can spin up as many instances as needed and then shut them down quickly.
Since we're not starting an app server ourselves, we need to tell AWS some info about how to do this for us. To complicate things more, Lambdas could handle different types of events. Not just an HTTP request, but also a trigger from a scheduler, a file uploaded to some storage, etc. This means that AWS can't just pass an HTTP request to our App Server (e.g. uvicorn). There may not be any HTTP requests in the first place.
So the responsibility for communication is actually passed on us. Instead of AWS invoking our endpoints (there may be no endpoints in our app), our app has to invoke AWS API and ask it for the event information. If we look into base Docker images (that we need to extend in our Dockerfiles) like public.ecr.aws/lambda/python:3.8, they have ENTRYPOINT which is a script that eventually talks to AWS API and fetches the information about the event. Then in case of Python that script imports a .py file that we specified using CMD and passes the event information into the function that we exposed.
But what if we did write an app that hands HTTP requests? How can we marry "handling event from AWS" and "handling HTTP requests"? This is where frameworks like Mangum come into play:
It exposes a function that accepts the event information from Lambda entrypoint script
Converts it into ASGI-compatible objects
Passes those objects to our ASGI-compatible middleware (Django, Starlette, FastAPI). And they think it's an HTTP
request.
Before reading this, make sure you understand what ASGI and middleware are.
Since I was unfortunate to work with AWS, I'd put some info about request handling in such env. Note, that AWS Lambda supports uploading ZIP file with our code and deployments using Docker. This post is about Docker deployments.
AWS Lambda is a way of writing serverless apps. Meaning you don't have any control of the hardware/VM your app starts on. AWS spins up some hardware, downloads your code there, runs it and stops the app after that. It can spin up as many instances as needed and then shut them down quickly.
Since we're not starting an app server ourselves, we need to tell AWS some info about how to do this for us. To complicate things more, Lambdas could handle different types of events. Not just an HTTP request, but also a trigger from a scheduler, a file uploaded to some storage, etc. This means that AWS can't just pass an HTTP request to our App Server (e.g. uvicorn). There may not be any HTTP requests in the first place.
So the responsibility for communication is actually passed on us. Instead of AWS invoking our endpoints (there may be no endpoints in our app), our app has to invoke AWS API and ask it for the event information. If we look into base Docker images (that we need to extend in our Dockerfiles) like
public.ecr.aws/lambda/python:3.8, they haveENTRYPOINTwhich is a script that eventually talks to AWS API and fetches the information about the event. Then in case of Python that script imports a.pyfile that we specified usingCMDand passes the event information into the function that we exposed.But what if we did write an app that hands HTTP requests? How can we marry "handling event from AWS" and "handling HTTP requests"? This is where frameworks like Mangum come into play:
The power of abstraction 💪