I usually use the debug terminal instead of watch statements. The expressions I want to watch are usually to complex to fit into the watch section so setting a breakpoint and running the statement in the debug terminal is shorter. In general having access to a complete python REPL in the debug terminal is such a powerful feature :)
Just a heads up: you should probably disable automatic title translation for both regular videos and shorts. This video, for example, shows up as “01 03 DEBUG FASTAPI” on my country (Portugal). The same has been happening to your shorts. This title is mostly gibberish and sounds like a placeholder for the actual title English speakers must be seeing.
I also find very useful to use the debug console. After I reaching a breakpoint you can try expressions or inspect/call object methods directly in the debug console.
After I have found the breakpoint() function it's been wonderful to stop the code and try different things to understand some unusual behaviour. But This video has great tips for debugger. Thanks.
Conditional breakpoints are super useful. I use them in Pycharm a lot. I didnt know about all those extra breakpoint types though, I dont think Pycharm has them. The break only on x number of hits, or "wait for other breakpoint" functionality. Seems really useful.
Happy New Year / gelukkig nieuwjaar 🎉 and thank you for the great video! I would like to suggest the VS Code extension REST Client. It’s great for sending GET/POST requests and presenting the qry and response in a clear format.
Very nice, but if app dockerized it tries to connect DB in neighbor pgadmin container and fails because cant connect. Same issue with Redis. To fix have to change db connection address in settings. And change back before git push to VPS
Solved adding .envdev with DB settings and adding envFile:.envdev to launch.json. Of course dont forget about docker ports mapping on db and redis containers.
I use debugger not often, but it's really helpfull for me to dive deeper inside the object structure for example, which I met throughout debugging process. This helps to find some interesting things related to the object structure etc. However as far as I know and heard, not many developers actully used debugger in their developing process. They argue this by saying that their code no complex and they fully understands what the code should do. I partially agree with them, but sometimes it's hard to understand where is an error is occurred in the code. Arjan, what is your thoughts on this? How often you use (used) debugging in your developing routine? 🙂
Easier to write unit test that directly call your FastAPI endpoints with a temporary db or other store under it. Also you can call endpoints directly as functions for some types of testing. I don't see why you want to debug under uvicorn if you goal is debugging your fastapi logic itself. Are you trying to debug uvicorn somehow?
Thank you for again an interesting video. Can you please review a relative new kid on the block called FastHtml, which seems a hybrid between FastApi and HTMX. I would like to hear your opinion on this.
💡 Learn how to design great software in 7 steps: arjan.codes/designguide.
Not only a great tutorial about debugging FastAPI, but about debugging in general! I learned a lot, thanks!
Glad it was helpful!
I usually use the debug terminal instead of watch statements. The expressions I want to watch are usually to complex to fit into the watch section so setting a breakpoint and running the statement in the debug terminal is shorter.
In general having access to a complete python REPL in the debug terminal is such a powerful feature :)
Just a heads up: you should probably disable automatic title translation for both regular videos and shorts. This video, for example, shows up as “01 03 DEBUG FASTAPI” on my country (Portugal). The same has been happening to your shorts. This title is mostly gibberish and sounds like a placeholder for the actual title English speakers must be seeing.
01 03 2025 DEPURACIÓN FASTAPI in Spanish
Yes, please.
Thanks for pointing that out! TH-cam has done quite a few changes lately related to languages. We’ll look into it.
Please make a playlist about what to do and not to do in production-grade API building.
I also find very useful to use the debug console. After I reaching a breakpoint you can try expressions or inspect/call object methods directly in the debug console.
Perfect timing, how did you know? Literally doing this right now.
Same!
After I have found the breakpoint() function it's been wonderful to stop the code and try different things to understand some unusual behaviour. But This video has great tips for debugger. Thanks.
Happy New Year dear Arjan, with many great videos like 2024 !!!
Happy new year!
Awesome as always 🙂
So excited for this video! THANK YOU! Watching now
Iam looking for this video all over youtube thanks for this video
Most welcome 😊
Conditional breakpoints are super useful. I use them in Pycharm a lot. I didnt know about all those extra breakpoint types though, I dont think Pycharm has them. The break only on x number of hits, or "wait for other breakpoint" functionality.
Seems really useful.
Happy New Year / gelukkig nieuwjaar 🎉 and thank you for the great video! I would like to suggest the VS Code extension REST Client. It’s great for sending GET/POST requests and presenting the qry and response in a clear format.
Very nice, but if app dockerized it tries to connect DB in neighbor pgadmin container and fails because cant connect. Same issue with Redis.
To fix have to change db connection address in settings. And change back before git push to VPS
Solved adding .envdev with DB settings and adding envFile:.envdev to launch.json.
Of course dont forget about docker ports mapping on db and redis containers.
I use debugger not often, but it's really helpfull for me to dive deeper inside the object structure for example, which I met throughout debugging process. This helps to find some interesting things related to the object structure etc. However as far as I know and heard, not many developers actully used debugger in their developing process. They argue this by saying that their code no complex and they fully understands what the code should do. I partially agree with them, but sometimes it's hard to understand where is an error is occurred in the code.
Arjan, what is your thoughts on this? How often you use (used) debugging in your developing routine? 🙂
This is a dap protocol, and you can use this monster in any editors. Vim or emacs can do the same things.
How show nvim
Easier to write unit test that directly call your FastAPI endpoints with a temporary db or other store under it. Also you can call endpoints directly as functions for some types of testing. I don't see why you want to debug under uvicorn if you goal is debugging your fastapi logic itself. Are you trying to debug uvicorn somehow?
Thank you for again an interesting video. Can you please review a relative new kid on the block called FastHtml, which seems a hybrid between FastApi and HTMX. I would like to hear your opinion on this.
thumbnail is crazy
you have old FastAPI logo in thumbnail
Total click bait! Where was the nerf gun?!?!?!
It was off-camera and pointed at me to make sure I didn’t ramble too much during recording.
Nice video title 😂
You meant thumbnail?
Thanks 😅
@@aflous Nah, he's probably seeing the automated translation, same problem with shorts
@@Daviid_5 No, I saw it originally as a placeholder title, probably the name of the file without the extension. Arjan then edited it.