Best Practice to Make HTTP Request in FastAPI Application

In this video, you'll learn how to make highly available FastAPI endpoints using asynchronous HTTP requests.
We'll cover:
Why standard requests library blocks the event loop
Introducing httpx for asynchronous requests in FastAPI
3 Best Practices:
Creating an AsyncClient with context manager (basic approach)
Using a dependency for cleaner code
Application-wide AsyncClient for efficiency (with trade-offs)
Optimize your FastAPI application for maximum responsiveness!
Hit that subscribe button for more FastAPI tips and tricks!
Search Queries:
fastapi asynchronous http requests
improve fastapi performance
fastapi high availability
fastapi async client
fastapi requests library blocking event loop
httpx in fastapi
fastapi async client best practices
fastapi dependency for async client
fastapi application state async client
#fastapi
#python
#webdev
#backend
#api
#programming
#fastapi
#python
#webdev
#backend
#api
#programming

[@nitishvirtual4745]

Great video. Short and to the point. Subscribed.

[@opium3156]

thx bro! so useful material, keep going

[@MathClubfor6789]

Great knowledgable video

[@cyyan1139]

thank you!

[@amodsahabandu]

Thanks. ❤

[@oktay9784]

this is not about FastApi, its about sync functions and async functions so just dont use sync functions in async functions if sync one is takes a lot of time.

[@godgive994]

Hello! Thank you for the video! Could you tell me how to measure the request (in your video it’s about 300ms)? Using a decorator? If so, I tried it, but it didn’t help, because time information is simply not displayed in the logs. I would like this information to be absorbed and for me to see a clear difference in the use of reguess and nttpx. I can’t leave a comment with a link to pastebin because youtube deletes such comments

[@codecollider]

I mentioned 300 milliseconds (ms) for external API calls, but that's a general idea based on what I've seen. The actual time can vary. No matter if you use requests or httpx, the external API itself will take some time (usually hundreds of milliseconds) to respond. We can't control that wait time. Focus on not blocking your app: The key difference is how httpx.AsyncClient handles waiting. With requests, your application grinds to a halt while it waits for the API response. This can be bad if your app needs to do other things. httpx.AsyncClient lets your application keep working even while waiting for the API. This is because it uses an asynchronous approach, which means it can juggle multiple tasks at once.

[@godgive994]

@@codecollider Thank you for answer!

[@muhammadhassankiyani8953]

@@codecollider How is it different from multi-threading then?

[@dixon1e]

Look at using a middleware to measure the elapsed time of a request. It always frightened me to even think about using middleware, probably due to CORS headaches, but when I finally did this exact use case, it turned out to be dirt simple.

[@Sam-rb1id]

@@dixon1e Did it make any difference to your run time though. With this simple example I don't think it would make any difference because it doesnt have any other task to execute while waiting for the response?

[@pritamsarkar3371]

dont we have to enable the 68 no line? "app = Fastapi(lifespan=lifespan)" ?

[@codecollider]

Yes you have to uncomment that line if you are using lifespan, forget to tell in the video.

[@thampasaurusrex3716]

thank you!