fastapi_cache VS mangum

We are using FastAPI in production.

Some useful links:

- Cookiecutter: https://github.com/tiangolo/full-stack-fastapi-postgresql

- Cache: https://github.com/comeuplater/fastapi_cache

Hey! I was in the same place as you are, and the best solution I found was to use Mangum (https://mangum.io/). I believe it also works with Django. Mangum is an adapter that transforms lambda events into the corresponding structure to be received by your Framework API endpoints. We are currently using it with FastAPI and it's great. We code our backend without thinking about whether it will run on Lambda, and Magum takes care of the rest.

In the real world I'm never using static cloud resources. It's all serverless, containers, or horizontal auto-scaling. I let the infrastructure handle asynchronous scaling when needed. For FastAPI specifically I've used Mangum: https://mangum.io/ to provide the asynchronous invocation below the ASGI layer. Then all my FastAPI code can just be synchronous.

I discovered https://github.com/jordaneremieff/mangum which basically transforms a fastapi app to be compatible with aws lambda.

Should I create only 1 apigtw resource with 1 lambda and use mangum + fastapi for my rest api ?

Mangum: For the integration of the Aws Lambda and the Api Gateway with the FastApi

If you go the lambda route, you can use DRF (or any ASGI app) using https://mangum.io/

Yes, it's possible to wrap any asgi app to run in a lambda. Check out Mangum https://github.com/jordaneremieff/mangum

But we do not have a handler function, do we? We have a Mangum object wrapping the FastAPI application. Luckily, the Mangum object acts as a handler function, so we can just add the following in example/src/app/__init__.py:

I've used fastapi in a lambda. The package Mangum simplifies the conversion of lambda handler to a more tradition request.