Implementing FastAPI Services – Abstraction and Separation of Concerns

I'm no programmer, but as an amateur I've found this article enlighting.

I've always found web dev tutorials short on explanations and not providing the big picture : a system level view. It quickly come to "do this, do that and you're done". I need to know the concept before the implementation. I'm probably lacking some CS background or so.

Illustrations in the article just clicked in my head and made me understand what I was not able to understand in other resources (like in the flask mega tutorial written by Miguel Grinberg). I've found explanations before code samples crystal clear and so helpful to review the code.

I can't wait to be at home to clone the repo and mess with it.

I can't speak for others but for me, this article is what was missing to go ahead in web dev. Thank you.

I've liked so much the illustrations that I've saved them on my smartphone.

This is very good! It's the most comprehensive guide of how to organize a large FastAPI project I've seen. Which is important, because FastAPI is unopinonated, so there's onboarding cost to getting a team on the same page-- strong opinions help alleviate that!

It's more Rails-like then Django/Flask-like. Meaning, top-level organization by "M"/"V"/"C" as opposed to by "Blueprint." I mean, "models/blog.py" as opposed to "blog/models.py".

Netflix Dispatch is an example project that organizes in the more Flask-Blueprint-like way (https://github.com/Netflix/dispatch/tree/master/src/dispatch).

I'm going to pour over this a bit longer, but that will take some time! So I wanted to leave some initial thoughts to people discovering this.

Is async truly useful when using fastapi? I remember seeing metrics suggesting that's not really the case.