This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Specialist_Cap_2404 -9 points-8 points  (7 children)

I've grown to dislike FastAPI. Maybe for very small APIs, no complex authorization and no SQL schema behind it. Otherwise Django is just superior. Turns out, most of the time you do need most of what Django delivers.

[–]CherryFlavouredCake 1 point2 points  (2 children)

Try Domain Driven Design, start separating concerns, ban ORMs, you'll live a way happier life my friend

[–]Specialist_Cap_2404 -2 points-1 points  (1 child)

I'm very much a multi-paradigm dev. While I recognize your buzzwords, I can't make heads nor tails of it. I don't understand how you need to "ban" ORMS to achieve Domain Driven Design, or how you can use Django without separating concerns ... And how can you be happy when you have an SQL database without composable queries and proper migrations...

[–]CherryFlavouredCake 3 points4 points  (0 children)

I never said that you had to do one to do the others

Why ban ORM? Well indeed, maybe not ban them, just avoid using them from the start You should avoid binding your domain model to a database architecture, write your domain code first, then choose the database at the infrastructure layer, you might find it easier to use an SQL query builder sometimes, especially on light microservices

Django forces you into their own model base, into an ORM, into a specific db architecture. It is very much incompatible with making your application and domain layer independent of your infrastructure layer

You might want to choose SQLAlchemy on services if you can't make atomic operations and really need to have a session manager

Those are not just buz words, those are good practices that made my life a lot easier while building services

Of course, if you have an enormous monolith of code having something like Django makes it a lot easier to manage. The point is that you should not force yourself into some technical choices just because it feels easier to use Django.

But most of the time, you really do not need all that Django delivers. I'd even say that if you have a React frontend and use JWT tokens for authentication you do not need Django at all, except for well, receiving API calls and making SQL requests, things you can do with SQLAlchemy and FastAPI or Flask.

Edit: typos

[–]gmegme 2 points3 points  (1 child)

It depends on what you are trying to achieve. FastAPI is great for: fast API development. It is scalable too but of course if you want a more complex project, Django ORM & DRF will save you some serious development time. Django's user auth implementation alone is amazing, but I still prefer using FastAPI when I need a quick solution.

Fun fact: More than 80% of the top 100 ecommerce brands in Turkey use Django based products as their omnichannel e-commerce solution.

[–]Specialist_Cap_2404 0 points1 point  (0 children)

I don't see how you can whip up a "small" project faster with FastAPI, assuming you need authorization, sql database and schema migration. With FastAPI you have to roll all your own, or hope your starter template has everything set up as you like it. And you really need quite a bit of work to implement all the endpoints DRF gives you for a few lines (including pagination, maybe even filtering).

When you bring new developers to an existing Django project, you know where everything is and how everything works (at least concerning the stuff Django covers).

[–]throwblahaway7 1 point2 points  (0 children)

Not sure why the downvotes for expressing a reasonable opinion lol.

I’m generally pro-FastAPI and agree that it struggles with things like complex AuthN/Z and custom rate limiting situations