Thankyou so much...i have been stuck for 2 days while trying to deploy my FastAPI project on live server.... As a beginner it was easy to understand.... thankyou so much💕🔥
Thank you for the helpful tutorial, @pixegami I encountered a specific issue when following this tutorial on my Macbook (with M1 chip) during AWS Lambda testing: { "errorMessage": "Unable to import module 'main': No module named 'pydantic_core._pydantic_core'", "errorType": "Runtime.ImportModuleError", "stackTrace": [] } To address this problem, I found that I needed to use a specific pip install command to ensure compatibility with AWS Lambda's Linux environment: pip install --platform manylinux2014_x86_64 -t lib -r requirements.txt --only-binary=:all: By specifying the manylinux2014_x86_64 platform and using the --only-binary=:all: flag, the command installed the Linux-compatible versions of the required dependencies. This allowed my Lambda function to work on the AWS Lambda platform. Hope this helps anyone that might be running into the same issue.
Great tutorial! This really helped me. Would you make a video on how to do this from AWS Cloud9, using AWS CodeBuild? I can't even access to swagger from Cloud9 IDE terminal.
I may have covered some of those topics in this video here: ua-cam.com/video/iLt00bqp6is/v-deo.html It also uses FastAPI and Lambda but actually connects multiple functions to API endpoints.
Great video, and appreciate your thoughtful answers to the questions - curious if the Swagger documentation still works when you deploy this way? If you were to go to the /docs endpoint
Great tutorial! However, this method doesn't seem to work for PUT and POST methods using json request bodies. I got my project running locally, but once in lambda I received no error for my GET functions and "Failed to fetch" for both my PUT and POST.
Lambda + FastAPI can support PUT/POST requests, but you might have to modify the code a little bit so that it allows those methods. This video goes more in-depth in building an actual API with different methods: ua-cam.com/video/iLt00bqp6is/v-deo.html
Thank you for the tutorial! It is great! ;) I have a question may be because I did not realized at all. I like so much FastAPI and Python, but I did not sure if it is better to implement the Gateway API and not use FastAPI or the FastAPI which benefits give instead of only have a Gateway API and a lambda behind. Let me know, I am very lost on this and for one hand I would like to go with FastAPI because I knew it more, but on the other hand, I think that with a backend lambda without FastAPI and only with GatewayAPI could be better rather than maintain two APIs definitions. Thank you very much to share your opinion!!!
That's a great comment, and thanks for asking. To answer your question, I suggest you don't see things as 'better' or 'worse', but instead what trade-offs you make. With FastAPI, you only have to maintain one Lambda function. Cold starts are less likely, and you can add new endpoints without having to add new infrastructure. You will also have a lot of 'common' code that you can share within that API. As a framework itself, FastAPI gives you more functionality, like HTTP code error propagation. Request/response modelling. Middle-ware. With API Gateway and separate Lambda functions, you have a different set of advantages. It's more 'separated', which makes it easier to manage with a large team. Smaller blast radius - bad code in one API will not take down the other APIs. AWS built-in- metrics and monitoring also work better when using separate resources. So with that in mind, what is *your* goal and what would you choose? For small projects, my goal is to make something quickly, and have little management overhead. In that case, FastAPI is the better option for me. What about you?
@@pixegami Thank you very much for your answer!!! I think like you, and also to use FastAPI to could grow more easily the API. In the current case is a little project only to get data from users and I thing fit better with this approach. Thank you so much for your help ;)
new sub here. This was awesome would love to see Fastapi hooked up to a dynamo table and deployed thru a lambda function. That would great! perhaps using the Serverless framework or SAM or something like that?
Thanks for the suggestion! I did take that into account, and just released a new video about FastAPI CRUD App with DynamoDB (deployed via CDK): ua-cam.com/video/iLt00bqp6is/v-deo.html
Hmm, you need to check the logs from server side. Does it go away after using it for a while? It might be that the timeout is low and doesn't have enough time for a cold start. If that's the case, you can try to increase the Lambda timeout by a few more seconds.
This is a good tutorial video, but I have not been able to successfully test this. I am using the exact same code. I am developing on Windows and I am using the command "powershell Compress-Archive" to create the zip file. The zip file is created successfully and all the libraries are at the root (just like in your video). I upload the zip file, but whenever I test, I get this error message: "Unable to import module 'main': No module named 'pydantic_core._pydantic_core'" I checked and pydantic_core is in the zip file.
I think this is probably because either the Python version or the CPU architecture is different between your computer and the Lambda function. First, check what Python version is in your Dockerfile, and check what your CPU architecture is (Intel or Arm64?). Then also make sure the Lambda function is configured with the same Python version and CPU architecture.
Thank you for the content. I would like that instead of putting my code directly into lambda, the lambda uses a container images with ECR that is build with docker+poetry. Do you recommend any approach or you have any video explaining the topic? Thank you
Yup, running Docker on AWS Lambda is a great use case. I have a video about it here: ua-cam.com/video/wbsbXfkv47A/v-deo.html I don't think I use ECR directly here, but you should be able to configure it quite easily in your CDK (or other infrastructure-as-code tool).
Hi, great content, Im following this tutorial and having this issue can someone help me? { "errorMessage": "Unable to import module 'main': No module named 'pydantic_core._pydantic_core'", "errorType": "Runtime.ImportModuleError", "stackTrace": [] } I added the pydantic in the requirements.txt but still not working
I encountered that issue too, when following this tutorial on my Macbook with an Apple Silicon chip (i.e. M1, M2, M3) during AWS Lambda testing. To address this problem, I found that I needed to modify the pip install command to ensure compatibility with AWS Lambda's Linux environment: pip install --platform manylinux2014_x86_64 -t lib -r requirements.txt --only-binary=:all: By specifying the manylinux2014_x86_64 platform and using the --only-binary=:all: flag, the command installed the Linux-compatible versions of the required dependencies. This allowed my Lambda function to work on the AWS Lambda platform. Hopefully that resolves your issue too.
One more question - you mentioned 3 ways to install dependencies (1) Docker Image (2) Building a Base Layer (3) Zipping the whole folder. Any idea which is best for reducing cold start time? (I may test it out if you haven't compared yet)
Docker *might* be a bit slower than a pure Python runtime. But generally, I don't think layers or zipping the files will make a significance difference to it. With cold starts, if it's in the order of seconds for small business or services, I think that's OK. If the code is too large in size, the start time will be slower, and it might need to be optimised or re-designed. If the service reaches a critical mass, the cold start per user on average will drop as more "warm" instances of Lambda are ready to serve. So it has a good scaling story.
hey there, i saw that when you were testing the payload for the lambda function, you used the apigateway-aws-proxy template but only change the paths in the template to a specific fastapi endpoint - list-books. However, when you hooked it up to a HTTP endpoint, it seems that the other fastapi endpoints are also working fine. So does it matter which endpoint do you map to back in your apigateway-aws-proxy template?
Great video. One quick question. I'm building a FastAPI to download a PDF File with Playwright and return the URL where is uploaded. I think the solution is to use EC2 because I have to host the PDF File, right? Hope you can help me.
Hi, We have successfully uploaded the fastapi project on AWS lambda. It has been running smoothly for 3 months. Aws lambda internally upgraded the software and suddenly my project got 500 internal errors. We solved the same configuration of application on dev phase and cloned the same code and configuration on production. It runs perfectly on dev phase but got a server error on the live build. The issue was from a bcrypt upgraded version. Now we are stuck on the issue, no log has been reported on cloud watch. How to solve the issue? Same code and configuration work on dev but not live
I see, that's hard! First of all, I'm curious about what "internal upgrades" you think AWS Lambda made to the software - AWS has a strong mantra to never deploy breaking or back-incompatible changes, so it's unlikely to be the source of your problem. I still have Lambda's deployed from 5 years ago that are running smoothly. How are you configuring your function? Second - when you run into an issue, you need to find out how to debug it. If the API is returning 500, there MUST be a log somewhere. Is your function getting invoked? If the log isn't on the function, maybe it is at the API Gateway. But all errors should leave a trace. I'd suggest trying to find that first. Finally, if you have something working in Dev - it means you have a working set of code/configuration somewhere, so there must be a difference between that and your live environment. I'd recommend comparing the configuration side-by-side to see if there's any major differences. Lambda runtime version could also cause something like this. Good luck!
I like your explanation, I was looking for Mangum kind of library to deploy multiple http end points as lambda function. I have question, i believe internally Magnum library spin up ASGI server to serve the request, if that is the case don't you think every time function triggers server bootup time add additional latency to request? Thanks in advance
I think it does, and yes it could add to Lambda's "cold-start" latency. But once Lambda cold-starts a function, it will be 'warm' for 15 minutes and Lambda won't need to boot it up again. So some customers will see a small latency spike on the cold start, but then it should faster for the subsequent calls. The more people that use it, the 'faster' each use will appear to be.
That's right - if you have Python packages that rely on something else in your system (and isn't there in your site-packages folder), then zipping it won't work. However, most shared libraries (like in numpy or PIL or even cryptography case) will exist in your site-packages folder. If you get an error, it could be because that specific version of the shared binary was NOT compiled with the same runtime as the Lambda function (e.g. Amazon Linux 2 kernel, Python 3.7). You can either build the zip file inside a Docker container to solve that, or even just use Docker runtime on Lambda.
Hmm, Is it Mangum or something else? I've deployed a lot of apps with Mangum before, and it's not that big. What else have you got in your project? Anyway, if you really do need more storage, you can look at using Docker on Lambda instead: ua-cam.com/video/wbsbXfkv47A/v-deo.html It has much higher size limit (I think 1GB).
great tutorial! just confused why wouldn't one handle routing and endpoints using api gateway vs using fastAPI? is there any benefit for using fastapi instead?
There's always a trade-off. In this case, there's less AWS resources to manage, all the code is in one function/project (which might have duplicate logic if you split them out), and having multiple routes hitting one function will keep it 'warm'. The drawback is the function is less secure, more of a monolith (harder to separate and work as a team). Higher chance that a bug in one route affects all other routes (blast radius increased).
Yeah that's a few ways to automate and deploy the app as a Lambda function. You could use CDK to build and deploy it. If you want full CI/CD, you can also use it with GitHub actions so it deploys on push: ua-cam.com/video/9uMcN66mfwE/v-deo.html
The main drawback I see is that cold start issues may occur, which can lead to slower response times for the first request after idle time. This cold start delay significant for RESTAPI applications?
The cold-start is a problem only if you really need millisecond latency for all customers. When building a small app, or an early stage start-up, I don't think a few seconds of cold start will hurt you much. Once the functions are warm, the response rate will be as good as a traditional server. So as your usage grows, the cold start will become less and less of an issue. I think it's a much better problem to have than over (or under) provisioning a traditional server fleet, and having to update, load balance, patch and secure them yourself.
Cost is probably the big one. If you don't have huge constant traffic, I think Lambda works out to be a lot cheaper than paying for an EC2 instance to be online 24/7. But I also like that you don't have to manage the server itself (like patching, OS updates, rebooting, etc). And scaling it up or down is much easier.
Thanks! I understand, but i have an issue, i have this error when run first test: { "errorMessage": "Unable to import module 'lambda_function': No module named 'lambda_function'", "errorType": "Runtime.ImportModuleError", "requestId": "dd15b838-dbc9-4e03-af15-8261099cd5db", "stackTrace": [] } any idea what could be wrong?
Using Flask would not have spared us from using Mangum either. Both modules made the right decision not to include Mangum functionality (to translate the Open API interface to Lambda's handler interface), because AWS integration is not the concern of a web service framework. The reason I'd pick FastAPI over Flask for something like this is because I prefer it's developer experience. But if I cared about reliability and track record? Maybe I'd use Flask.
In this video I used Ubuntu Linux (which is probably my favourite for pure programming since it works best with Python machine learning libraries, models, and Nvidia GPU cards). I also used Windows for a while, but now my main machine is an M1 MacBook Pro, because I want a Unix-like OS and Adobe programs on the same computer. But honestly though, I've enjoyed working on all three OS and I don't see too much different when it comes to development for Python, AWS and Typescript projects.
Hey man thats a lovely tutorial, i have a question if you want to dockerise it and now zip it out what all steps we need to follow, and i have done that by using containerising but after running it in lambda I’m getting 404 status code and the execution is succeeded
Thank you for the tutorial! I've tried replicating this process with a REST API but I've only got 504 "Endpoint request timed out" errors. The problem is that my code only takes less than a second at most to run so it's well under the 30-second time constraint for all lambda functions. My cloudwatch logs have only given me information that I already know. If you could lend some advice or support on this issue that would be great!
Are you sure that your Lambda functions have a 30 second timeout? I believe Lambdas can run up to 10 minutes, but unless you override the "Timeout" setting, the default is usually something like 1-3 seconds. I recommend taking a look at that first. If it doesn't work, then go into your API code, and add timeout loop within that too (so the API itself fails before Lambda does), so at least you have some control of the logging and error being thrown. It's possible that there's some process in there that just gets stuck when it's running in Lambda (e.g. HTTP calls).
Do you have any idea with how to deal with libraries such as numpy or sklearn. I'm able to install them in the zip file, but lambda is having trouble working with them
What errors do you get? Using some of the more advanced libraries in Lambda (like numpy and sklearn) is hard because you also need to install the exact right C libraries for them. Python does this for you, but if you install it in your machine, Python will pick the binaries built for your machine (e.g. Windows library). But Lambda runs in an Amazon Linux environment (specific kernel type and specific CPU architecture too - e.g Intel or ARM). If you have the exact right library, the package will fail. The way to solve this is to use a Docker file to simulate the environment of an AWS Lambda function, and install the Python dependencies there. That will pull the right version of the C binaries. Then you can extract the zip from the Docker file and use it in Lambda. hub.docker.com/r/amazon/aws-lambda-python
Hey, Nice Tutorial! one question, how to implement user session management(register/login) with fastapi and AWS lambda?? any resource/code for that you would suggest?
I haven't looked into session management yet (I'm sure there's many options). For my own auth use cases, I've focused mostly on JWT tokens because it's a widely supported standard and pretty easy to use: ua-cam.com/video/BQrE98bP6m4/v-deo.html It works with well Python, FastAPI, and things like Firebase so you don't have to build your own login system (trust me, it's not something you wanna manage yourself!) Unlike sessions though, you can't revoke a JWT token. So you instead just give them a short expiry (e.g. 1 - 24 hours) to limit the damage that can be done if a token were compromised.
I haven't tried that yet, but you can debug the issue if you break down the error step by step. For example, does it have network connection? Does it have sufficient permissions? You'll have to work closely with the error message you see in your logs.
I don't think I used any special extension - I thought it just came that way! Although normally I use Firefox for development debugging... I definitely don't have any specific extensions for it so it's a native feature of the browser.
At what point is a solution like this less effective than EC2? You can get the same auto scaling benefits from using an orchestration layer like kubernetes with docker and have control over machine deployment sizes? I'm looking for the cheapest and most effective solution for an analytics platform and I do like lambda, but the amount of control with EC2 seems to make more sense.
I've also used K8s and EC2 before. To answer your question, I recommend you factor in your team's set up and maintenance cost of a custom EC2 set-up vs AWS Lambda, and the run time. At large scales of consistent traffic, EC2 does very very well compute-cost wise. But usually the maintenance and operational cost (patching, debugging, security, availability, etc) are the far bigger term to manage. In most cases, I think the easy maintenance of Lambda functions beat out any potential compute cost savings. There are some cases (like massive batch processing) where EC2 might outshine Lambda-so it'll be up to you to decide.
I've taken a quick look before, but didn't seriously consider it an option. I think it solves too-specific of a problem for me to select as a tool to build upon, and I'm concerned about adoption rates or risk of it being deprecated. When I choose something as core as a framework/platform, I think to prefer things that have high-adoption (e.g. Flask, NextJS, React, AWS) because long term reliability, proven track records, and abundance of online resources is a huge factor for me. Alternatively, I would also consider something is rising fast and provides an interesting new user experience for me (e.g. TailwindCSS, FastAPI, Svelte). Even without adoption mass of the previous set, there's enough value proposition for me to be interested.
What's the benefit of having all your API code on a lambda , surely as your API grows so does the code making startups slower (cold starts) and you loose the principal of one lambda one concern ? Aren't you just putting lots of indirection and dependencies into something relatively simple , a lambda is a function invoked by and endpoint ?
Very good question to ask. The best way to get an answer that suits you is to actually try building the same thing yourself, using both approaches and see which you prefer. For small applications (e.g. fewer than 8 API routes), I tried both ways and prefer a single Lambda. All your code and updates are deployed as one unit, and often there's a lot of boilerplate and code re-use anyway between those routes. There's less resource sprawl, you have one Lambda and API Gateway resource in your AWS for all your application logic instead of 8. And if the routes need to interact with each other (or share logic), then the indirection is actually less than if you had them as separate stateless APIs. Cold starts? Well - having 8+ separate APIs will incur cold starts too. All routes can share the same instance, so you might have the first function take longer to start once, but you quickly make up for that in subsequent invocations. But aside from that - how many milliseconds are you expecting additional routes to add to a cold start? Unless there's asymmetrical, complex start-up logic in them - I don't think it will be much. Now the most compelling argument is "the principal of one lambda one concern". Also security reasons (of not sharing the runtime closure between some routes), and not bundling simple operations (e.g. CRUD ops) with heavy ones (e.g. image editing). If you start to creep into that territory, it absolutely makes sense to scale out the architecture better. You can use multiple Lambdas, managed by CDK, and maybe even use it with AWS Step Functions for flow of data. But if you don't anticipate the need to scale, and the number of routes is fixed at a small finite number, then for me, pragmatism trumps principle, and I'll go with the monolith. Optimising for scale too early, in my experience, is a very common productivity trap. What do you think?
I expect the audience for this project to be somewhat new to AWS/Lambda, so the console approach was specifically chosen *because* it’s “so 1998” - something simple, robust and widely understood over decades. The console is indeed a poor developer experience, and in my other tutorials where the projects are bigger or more advanced, we use CLI or CDK for deployment. But I think that the overhead of introducing those things here would have detracted from the actual learning objective of this video: establishing a clear mental model for how FastAPI works with Lambda.
This video is AWESOME! Very clear and concise explanations around deploying FastAPI on Lambda.
Glad you enjoyed it! Thanks for the feedback.
Thankyou so much...i have been stuck for 2 days while trying to deploy my FastAPI project on live server....
As a beginner it was easy to understand.... thankyou so much💕🔥
You’re welcome! So glad to hear that it helped.
Great tutorial! I hope your channel get a broader audience because the content it's awesome 👍
Thanks! I hope so too, but the important thing is that the videos are useful to anyone who wants to learn how to build this stuff :)
Excellent Explanation. I have been looking for these kinds of details for long time. God bless you and your family.
Glad it was helpful!
Binge watching your videos 😢. Its addictive and great job
Thank you! Glad you hear you're enjoying it :)
Probably the best video on this topic.. Really loved it! Thanks.. Keep it up..
Glad you liked it!
Holy! i can use this on my node express also! amazing with function URL
Yup, FunctionURL is awesome!
Great video man :)
Amazing tutorial man!! Thank you and keep going with a great content!
Great tutorial.! Very clear and easy to understand 👌
Thank you! I hope you go on to build something cool with it!
Bro Really helpful
Keep going.🤘
Glad to hear it was helpful! Thanks for the encouragement :)
Thank you for the helpful tutorial, @pixegami
I encountered a specific issue when following this tutorial on my Macbook (with M1 chip) during AWS Lambda testing:
{
"errorMessage": "Unable to import module 'main': No module named 'pydantic_core._pydantic_core'",
"errorType": "Runtime.ImportModuleError",
"stackTrace": []
}
To address this problem, I found that I needed to use a specific pip install command to ensure compatibility with AWS Lambda's Linux environment:
pip install --platform manylinux2014_x86_64 -t lib -r requirements.txt --only-binary=:all:
By specifying the manylinux2014_x86_64 platform and using the --only-binary=:all: flag, the command installed the Linux-compatible versions of the required dependencies. This allowed my Lambda function to work on the AWS Lambda platform.
Hope this helps anyone that might be running into the same issue.
Great work, very clearly explication. congratulations.
Many thanks!
Great video. Thank you for making this video.
My pleasure!
Great content!
its really helpful. thanks a lot!
Glad it was helpful!
Good tutorial, Thanks :)
You're welcome!
great tutorial, it was really useful for me. Thanks!
Very helpful video and Subscribed. 🙂
Welcome aboard!
3:40 - Explanation
10:35 - Zip libs
Great tutorial! This really helped me. Would you make a video on how to do this from AWS Cloud9, using AWS CodeBuild? I can't even access to swagger from Cloud9 IDE terminal.
Thanks! I haven't used Cloud9/CodeBuild much so I don't have any plans for that content yet...
Great effort!
Thank you! Cheers!
thanks this was really helpful
Glad it helped
Great video man.
thanks, very informative
Glad it was helpful!
need more advanced tutorial for using API Gateway + Routing etc..
I may have covered some of those topics in this video here: ua-cam.com/video/iLt00bqp6is/v-deo.html
It also uses FastAPI and Lambda but actually connects multiple functions to API endpoints.
awsome keep it up
Great video, and appreciate your thoughtful answers to the questions - curious if the Swagger documentation still works when you deploy this way? If you were to go to the /docs endpoint
Yes they would! You can try it out. But if you wanna go to production, you can disable them: fastapi.tiangolo.com/tutorial/metadata/
docs_url=None
Great tutorial! However, this method doesn't seem to work for PUT and POST methods using json request bodies. I got my project running locally, but once in lambda I received no error for my GET functions and "Failed to fetch" for both my PUT and POST.
Lambda + FastAPI can support PUT/POST requests, but you might have to modify the code a little bit so that it allows those methods. This video goes more in-depth in building an actual API with different methods: ua-cam.com/video/iLt00bqp6is/v-deo.html
Thank you very much!
You're welcome!
Thank you for the tutorial! It is great! ;) I have a question may be because I did not realized at all. I like so much FastAPI and Python, but I did not sure if it is better to implement the Gateway API and not use FastAPI or the FastAPI which benefits give instead of only have a Gateway API and a lambda behind.
Let me know, I am very lost on this and for one hand I would like to go with FastAPI because I knew it more, but on the other hand, I think that with a backend lambda without FastAPI and only with GatewayAPI could be better rather than maintain two APIs definitions.
Thank you very much to share your opinion!!!
That's a great comment, and thanks for asking. To answer your question, I suggest you don't see things as 'better' or 'worse', but instead what trade-offs you make.
With FastAPI, you only have to maintain one Lambda function. Cold starts are less likely, and you can add new endpoints without having to add new infrastructure. You will also have a lot of 'common' code that you can share within that API. As a framework itself, FastAPI gives you more functionality, like HTTP code error propagation. Request/response modelling. Middle-ware.
With API Gateway and separate Lambda functions, you have a different set of advantages. It's more 'separated', which makes it easier to manage with a large team. Smaller blast radius - bad code in one API will not take down the other APIs. AWS built-in- metrics and monitoring also work better when using separate resources.
So with that in mind, what is *your* goal and what would you choose? For small projects, my goal is to make something quickly, and have little management overhead.
In that case, FastAPI is the better option for me. What about you?
@@pixegami Thank you very much for your answer!!! I think like you, and also to use FastAPI to could grow more easily the API. In the current case is a little project only to get data from users and I thing fit better with this approach.
Thank you so much for your help ;)
Great tutorial - will you make one on using Docker on aws lambda
Thanks! I don't have plans for a Docker version yet, but it's a good suggestion (since I use Docker for more complex Python scripts).
new sub here. This was awesome would love to see Fastapi hooked up to a dynamo table and deployed thru a lambda function. That would great! perhaps using the Serverless framework or SAM or something like that?
Thanks for the suggestion! I did take that into account, and just released a new video about FastAPI CRUD App with DynamoDB (deployed via CDK): ua-cam.com/video/iLt00bqp6is/v-deo.html
Why am I getting "bad gateway" when I try to make a request to my api after some time?
Hmm, you need to check the logs from server side. Does it go away after using it for a while? It might be that the timeout is low and doesn't have enough time for a cold start. If that's the case, you can try to increase the Lambda timeout by a few more seconds.
This is a good tutorial video, but I have not been able to successfully test this. I am using the exact same code. I am developing on Windows and I am using the command "powershell Compress-Archive" to create the zip file. The zip file is created successfully and all the libraries are at the root (just like in your video). I upload the zip file, but whenever I test, I get this error message:
"Unable to import module 'main': No module named 'pydantic_core._pydantic_core'"
I checked and pydantic_core is in the zip file.
I think this is probably because either the Python version or the CPU architecture is different between your computer and the Lambda function.
First, check what Python version is in your Dockerfile, and check what your CPU architecture is (Intel or Arm64?). Then also make sure the Lambda function is configured with the same Python version and CPU architecture.
If i have template folder with front end assets and static folder.then how i can deploy using aws lambda
NICE
still getting module not found fastapi
Thank you for the content. I would like that instead of putting my code directly into lambda, the lambda uses a container images with ECR that is build with docker+poetry. Do you recommend any approach or you have any video explaining the topic?
Thank you
Yup, running Docker on AWS Lambda is a great use case. I have a video about it here: ua-cam.com/video/wbsbXfkv47A/v-deo.html
I don't think I use ECR directly here, but you should be able to configure it quite easily in your CDK (or other infrastructure-as-code tool).
@@pixegamithank you, I will check this out asap!
Hi, great content, Im following this tutorial and having this issue can someone help me?
{
"errorMessage": "Unable to import module 'main': No module named 'pydantic_core._pydantic_core'",
"errorType": "Runtime.ImportModuleError",
"stackTrace": []
}
I added the pydantic in the requirements.txt but still not working
I encountered that issue too, when following this tutorial on my Macbook with an Apple Silicon chip (i.e. M1, M2, M3) during AWS Lambda testing. To address this problem, I found that I needed to modify the pip install command to ensure compatibility with AWS Lambda's Linux environment:
pip install --platform manylinux2014_x86_64 -t lib -r requirements.txt --only-binary=:all:
By specifying the manylinux2014_x86_64 platform and using the --only-binary=:all: flag, the command installed the Linux-compatible versions of the required dependencies. This allowed my Lambda function to work on the AWS Lambda platform. Hopefully that resolves your issue too.
One more question - you mentioned 3 ways to install dependencies (1) Docker Image (2) Building a Base Layer (3) Zipping the whole folder. Any idea which is best for reducing cold start time? (I may test it out if you haven't compared yet)
Docker *might* be a bit slower than a pure Python runtime. But generally, I don't think layers or zipping the files will make a significance difference to it.
With cold starts, if it's in the order of seconds for small business or services, I think that's OK. If the code is too large in size, the start time will be slower, and it might need to be optimised or re-designed.
If the service reaches a critical mass, the cold start per user on average will drop as more "warm" instances of Lambda are ready to serve. So it has a good scaling story.
hey there, i saw that when you were testing the payload for the lambda function, you used the apigateway-aws-proxy template but only change the paths in the template to a specific fastapi endpoint - list-books. However, when you hooked it up to a HTTP endpoint, it seems that the other fastapi endpoints are also working fine. So does it matter which endpoint do you map to back in your apigateway-aws-proxy template?
Great video. One quick question. I'm building a FastAPI to download a PDF File with Playwright and return the URL where is uploaded. I think the solution is to use EC2 because I have to host the PDF File, right? Hope you can help me.
Good tutorial. Easy to follow and to the point. How is this done with Node.js?
Thanks! I haven't gone through the process with NodeJS yet, so I can't say for sure.
Thanks
i like the color of the text in your terminal. how do i change mine too to have the yellow color of the arrow symbol?
Hi,
We have successfully uploaded the fastapi project on AWS lambda. It has been running smoothly for 3 months. Aws lambda internally upgraded the software and suddenly my project got 500 internal errors. We solved the same configuration of application on dev phase and cloned the same code and configuration on production. It runs perfectly on dev phase but got a server error on the live build. The issue was from a bcrypt upgraded version. Now we are stuck on the issue, no log has been reported on cloud watch. How to solve the issue? Same code and configuration work on dev but not live
I see, that's hard! First of all, I'm curious about what "internal upgrades" you think AWS Lambda made to the software - AWS has a strong mantra to never deploy breaking or back-incompatible changes, so it's unlikely to be the source of your problem. I still have Lambda's deployed from 5 years ago that are running smoothly. How are you configuring your function?
Second - when you run into an issue, you need to find out how to debug it. If the API is returning 500, there MUST be a log somewhere. Is your function getting invoked? If the log isn't on the function, maybe it is at the API Gateway. But all errors should leave a trace. I'd suggest trying to find that first.
Finally, if you have something working in Dev - it means you have a working set of code/configuration somewhere, so there must be a difference between that and your live environment. I'd recommend comparing the configuration side-by-side to see if there's any major differences. Lambda runtime version could also cause something like this.
Good luck!
I like your explanation, I was looking for Mangum kind of library to deploy multiple http end points as lambda function. I have question, i believe internally Magnum library spin up ASGI server to serve the request, if that is the case don't you think every time function triggers server bootup time add additional latency to request? Thanks in advance
I think it does, and yes it could add to Lambda's "cold-start" latency. But once Lambda cold-starts a function, it will be 'warm' for 15 minutes and Lambda won't need to boot it up again. So some customers will see a small latency spike on the cold start, but then it should faster for the subsequent calls. The more people that use it, the 'faster' each use will appear to be.
I think the way you zip up all dependencies will not work if there's any shared library.
That's right - if you have Python packages that rely on something else in your system (and isn't there in your site-packages folder), then zipping it won't work.
However, most shared libraries (like in numpy or PIL or even cryptography case) will exist in your site-packages folder. If you get an error, it could be because that specific version of the shared binary was NOT compiled with the same runtime as the Lambda function (e.g. Amazon Linux 2 kernel, Python 3.7).
You can either build the zip file inside a Docker container to solve that, or even just use Docker runtime on Lambda.
the size of magnum file is too large,what to do?
Hmm, Is it Mangum or something else? I've deployed a lot of apps with Mangum before, and it's not that big. What else have you got in your project?
Anyway, if you really do need more storage, you can look at using Docker on Lambda instead: ua-cam.com/video/wbsbXfkv47A/v-deo.html
It has much higher size limit (I think 1GB).
great tutorial! just confused why wouldn't one handle routing and endpoints using api gateway vs using fastAPI? is there any benefit for using fastapi instead?
There's always a trade-off. In this case, there's less AWS resources to manage, all the code is in one function/project (which might have duplicate logic if you split them out), and having multiple routes hitting one function will keep it 'warm'.
The drawback is the function is less secure, more of a monolith (harder to separate and work as a team). Higher chance that a bug in one route affects all other routes (blast radius increased).
Hey, How to automate this so instead making zip and uploading manually we should be able to do with aws cli atleast?
Yeah that's a few ways to automate and deploy the app as a Lambda function. You could use CDK to build and deploy it. If you want full CI/CD, you can also use it with GitHub actions so it deploys on push: ua-cam.com/video/9uMcN66mfwE/v-deo.html
@@pixegami thanks
The main drawback I see is that cold start issues may occur, which can lead to slower response times for the first request after idle time. This cold start delay significant for RESTAPI applications?
The cold-start is a problem only if you really need millisecond latency for all customers. When building a small app, or an early stage start-up, I don't think a few seconds of cold start will hurt you much. Once the functions are warm, the response rate will be as good as a traditional server. So as your usage grows, the cold start will become less and less of an issue.
I think it's a much better problem to have than over (or under) provisioning a traditional server fleet, and having to update, load balance, patch and secure them yourself.
but what are the advantages ?
Cost is probably the big one. If you don't have huge constant traffic, I think Lambda works out to be a lot cheaper than paying for an EC2 instance to be online 24/7.
But I also like that you don't have to manage the server itself (like patching, OS updates, rebooting, etc). And scaling it up or down is much easier.
Thanks! I understand, but i have an issue, i have this error when run first test: {
"errorMessage": "Unable to import module 'lambda_function': No module named 'lambda_function'",
"errorType": "Runtime.ImportModuleError",
"requestId": "dd15b838-dbc9-4e03-af15-8261099cd5db",
"stackTrace": []
}
any idea what could be wrong?
Your Lambda function can't find the file/folder named 'lambda_function' in its code. Did you name it and upload it correctly?
How to use AWS SAM ?
If fastapi is not quite enough and you need Mangum to complete its job, why did you not use Flask?
Using Flask would not have spared us from using Mangum either. Both modules made the right decision not to include Mangum functionality (to translate the Open API interface to Lambda's handler interface), because AWS integration is not the concern of a web service framework.
The reason I'd pick FastAPI over Flask for something like this is because I prefer it's developer experience. But if I cared about reliability and track record? Maybe I'd use Flask.
Great tutorial! What OS do you have?
In this video I used Ubuntu Linux (which is probably my favourite for pure programming since it works best with Python machine learning libraries, models, and Nvidia GPU cards).
I also used Windows for a while, but now my main machine is an M1 MacBook Pro, because I want a Unix-like OS and Adobe programs on the same computer.
But honestly though, I've enjoyed working on all three OS and I don't see too much different when it comes to development for Python, AWS and Typescript projects.
Hey man thats a lovely tutorial, i have a question if you want to dockerise it and now zip it out what all steps we need to follow, and i have done that by using containerising but after running it in lambda I’m getting 404 status code and the execution is succeeded
Whats the best solution for zip files over the MB limit as my file seems to be too large to upload?
I think in that case you need to upload the file to Amazon S3 first. Lambda accepts an S3 file location as input to its code as well.
Thank you for the tutorial! I've tried replicating this process with a REST API but I've only got 504 "Endpoint request timed out" errors. The problem is that my code only takes less than a second at most to run so it's well under the 30-second time constraint for all lambda functions. My cloudwatch logs have only given me information that I already know. If you could lend some advice or support on this issue that would be great!
Are you sure that your Lambda functions have a 30 second timeout? I believe Lambdas can run up to 10 minutes, but unless you override the "Timeout" setting, the default is usually something like 1-3 seconds. I recommend taking a look at that first.
If it doesn't work, then go into your API code, and add timeout loop within that too (so the API itself fails before Lambda does), so at least you have some control of the logging and error being thrown.
It's possible that there's some process in there that just gets stuck when it's running in Lambda (e.g. HTTP calls).
@@pixegami I can't believe that I've been setting the timeout function to 50ms thinking it did something else 😅 problem solved
Do you have any idea with how to deal with libraries such as numpy or sklearn. I'm able to install them in the zip file, but lambda is having trouble working with them
What errors do you get? Using some of the more advanced libraries in Lambda (like numpy and sklearn) is hard because you also need to install the exact right C libraries for them. Python does this for you, but if you install it in your machine, Python will pick the binaries built for your machine (e.g. Windows library). But Lambda runs in an Amazon Linux environment (specific kernel type and specific CPU architecture too - e.g Intel or ARM). If you have the exact right library, the package will fail.
The way to solve this is to use a Docker file to simulate the environment of an AWS Lambda function, and install the Python dependencies there. That will pull the right version of the C binaries. Then you can extract the zip from the Docker file and use it in Lambda.
hub.docker.com/r/amazon/aws-lambda-python
which theme did you use in your vscode? also can you deploy both streamlit and fastapi on aws? can you do that video soon? Thanks
Hey, Nice Tutorial!
one question, how to implement user session management(register/login) with fastapi and AWS lambda?? any resource/code for that you would suggest?
I haven't looked into session management yet (I'm sure there's many options). For my own auth use cases, I've focused mostly on JWT tokens because it's a widely supported standard and pretty easy to use: ua-cam.com/video/BQrE98bP6m4/v-deo.html
It works with well Python, FastAPI, and things like Firebase so you don't have to build your own login system (trust me, it's not something you wanna manage yourself!)
Unlike sessions though, you can't revoke a JWT token. So you instead just give them a short expiry (e.g. 1 - 24 hours) to limit the damage that can be done if a token were compromised.
@@pixegami Thank you!!!
Hi, Pixegami. I'm having trouble using psycopg2 to connect to a RDS Postgres. Have you encounter some similar issue?
I haven't tried that yet, but you can debug the issue if you break down the error step by step. For example, does it have network connection? Does it have sufficient permissions? You'll have to work closely with the error message you see in your logs.
Great video, how do you get json viewed in formatted way inside your browser? Chrome extension?
I don't think I used any special extension - I thought it just came that way! Although normally I use Firefox for development debugging... I definitely don't have any specific extensions for it so it's a native feature of the browser.
At what point is a solution like this less effective than EC2? You can get the same auto scaling benefits from using an orchestration layer like kubernetes with docker and have control over machine deployment sizes? I'm looking for the cheapest and most effective solution for an analytics platform and I do like lambda, but the amount of control with EC2 seems to make more sense.
I've also used K8s and EC2 before. To answer your question, I recommend you factor in your team's set up and maintenance cost of a custom EC2 set-up vs AWS Lambda, and the run time.
At large scales of consistent traffic, EC2 does very very well compute-cost wise. But usually the maintenance and operational cost (patching, debugging, security, availability, etc) are the far bigger term to manage.
In most cases, I think the easy maintenance of Lambda functions beat out any potential compute cost savings. There are some cases (like massive batch processing) where EC2 might outshine Lambda-so it'll be up to you to decide.
getting error ,Anyone know how to solve
Unable to import module 'main': No module named 'pydantic_core._pydantic_core'
Are you getting this error when you are running it on Lambda or running it locally?
Did you solve this?
@@tobywilkins7382 I am also getting the same error
@@pixegami While running it in lambda
Thanks, very precise. Have you considered AWS chalice once?
I've taken a quick look before, but didn't seriously consider it an option. I think it solves too-specific of a problem for me to select as a tool to build upon, and I'm concerned about adoption rates or risk of it being deprecated.
When I choose something as core as a framework/platform, I think to prefer things that have high-adoption (e.g. Flask, NextJS, React, AWS) because long term reliability, proven track records, and abundance of online resources is a huge factor for me.
Alternatively, I would also consider something is rising fast and provides an interesting new user experience for me (e.g. TailwindCSS, FastAPI, Svelte). Even without adoption mass of the previous set, there's enough value proposition for me to be interested.
@@pixegami Thanks, appreciate your long answer. Indeed, good arguments. BR Tom
Any tips on the zip package size? I zipped it and i am at 56mb, i am sure i can save some extra mbs and be able to upload it.
same problem
For any reason after deploy if i use /doc, do it make request in lambda ?
Yup, it still uses Lambda to render the docs page I believe. You can turn it off in the app though if you don't want it exposed.
@@pixegami could you make any video on how to deploy with docker in lambda ?
@@user-fp7yw9zv8m Yup! I actually made one recently and you can check it out here: ua-cam.com/video/wbsbXfkv47A/v-deo.html
What's the benefit of having all your API code on a lambda , surely as your API grows so does the code making startups slower (cold starts) and you loose the principal of one lambda one concern ? Aren't you just putting lots of indirection and dependencies into something relatively simple , a lambda is a function invoked by and endpoint ?
Very good question to ask. The best way to get an answer that suits you is to actually try building the same thing yourself, using both approaches and see which you prefer.
For small applications (e.g. fewer than 8 API routes), I tried both ways and prefer a single Lambda. All your code and updates are deployed as one unit, and often there's a lot of boilerplate and code re-use anyway between those routes.
There's less resource sprawl, you have one Lambda and API Gateway resource in your AWS for all your application logic instead of 8. And if the routes need to interact with each other (or share logic), then the indirection is actually less than if you had them as separate stateless APIs.
Cold starts? Well - having 8+ separate APIs will incur cold starts too. All routes can share the same instance, so you might have the first function take longer to start once, but you quickly make up for that in subsequent invocations. But aside from that - how many milliseconds are you expecting additional routes to add to a cold start? Unless there's asymmetrical, complex start-up logic in them - I don't think it will be much.
Now the most compelling argument is "the principal of one lambda one concern". Also security reasons (of not sharing the runtime closure between some routes), and not bundling simple operations (e.g. CRUD ops) with heavy ones (e.g. image editing).
If you start to creep into that territory, it absolutely makes sense to scale out the architecture better. You can use multiple Lambdas, managed by CDK, and maybe even use it with AWS Step Functions for flow of data.
But if you don't anticipate the need to scale, and the number of routes is fixed at a small finite number, then for me, pragmatism trumps principle, and I'll go with the monolith. Optimising for scale too early, in my experience, is a very common productivity trap.
What do you think?
@@pixegami Thats a great response , thanks for taking time to respond.
"zip and upload" ... really?? that's so 1998.
Working in that console is terrible. It might be cheap, but it is torture for any developer.
I expect the audience for this project to be somewhat new to AWS/Lambda, so the console approach was specifically chosen *because* it’s “so 1998” - something simple, robust and widely understood over decades.
The console is indeed a poor developer experience, and in my other tutorials where the projects are bigger or more advanced, we use CLI or CDK for deployment.
But I think that the overhead of introducing those things here would have detracted from the actual learning objective of this video: establishing a clear mental model for how FastAPI works with Lambda.
{
"errorMessage": "Unable to import module 'main': No module named 'pydantic_core._pydantic_core'",
"errorType": "Runtime.ImportModuleError",
"requestId": "7ce220f8-3866-49e4-9ccc-78f853467d4d",
"stackTrace": []
}
getting error after code deployment
Hmm, try changing your Lambda CPU architecture to something that matches you CPU (either arm64 or Intel/AMD).
@@pixegami same issue here. I have to mention I have my fastapi app runing in Docker. The base image on my dockerfile is python3.9-slim
Also, i am using Pydantic V2