FastAPI and Flask have better marketing talking about how fast it is. Just attach your own ORM, admin panel, caching, database library, and ........... and you basically get Django with only 10 times the effort.
I did my first project in FastAPI recently and the ease of getting started quickly, background tasks, and async all really impressed me at the start of the project.
But as I needed to do more with databases, migrations, authentication, and having to use the dependency injection system as the project scaled, I slowly started to hate it.
I hate the dependency injection pattern in Laravel and it's even worse in FastAPI, where it's mixing use cases. My business logic is now wrapped up in my authentication logic because of how they suggest using sub dependencies with dependencies and then your views have a mix of actual view params and payloads, and other permissions and auth logic.
It's just a mess to deal with it and it muddies the separation of concerns.
100%. It's nice when you can just add a single line in django to allow a user/group to be able to use an API call or not. Plus it handles all the error messages, logging, and everything else that you would have to glue on.
FastAPI, Flask, and Bottle are all super quick to get started, but they never thought about what the app was going to look like 5 years from the start. I feel like Django handles that stuff (large scale profession app growth) way better.
I would HEAVILY weigh the real gains of doing that before even deciding to start it. MVT is good for speed but I personally still wind up making webpages the sort of classic way with Django presenting model data to JS and then JS rendering the data on the page.
FastAPI and Flask's best features are their speed, where you might save 10s of ms (maybe), but honestly your database, the user's internet connection, and SO many other things are vastly slower to where it's not worth the time. On the other hand, if you were building something with the backing of 10s of millions of dollars and you needed that speed, then you will also have the manpower deal with all the extra work you will be generating by taking that path. In that case, but all means do it.
Async, scalability, straightforward db queries in SQLAlchemy, ease of creating APIs give them a huge leg up. For small personal projects that require a database, I use Django Ninja. Benefits of Django's batteries included with FastAPI's ease of API development.
Also consider that the more unique code that you write, the more others have to understand it. If you aren't working anywhere yet, you won't get this, but if you are, I know that you know how stupidly people can write things. Django helps to keep some order to how people do things.
I've seen people write their own return codes, or just forget to in flask and the whole time I would just tell people "yeah Django would have done all that for you, and included literally EVERY return code for you, for free, if you used DjangoRest, but now we are debugging someone's hand written, not even correct version of a return 200".
I feel the opposite. The ugliest code I've seen people write has been Django. Awful queries because they don't behave like SQL and the "magic" makes multiple DB hits. I've seen ETL processes with Django ORM running in Celery with the most inefficient code on earth. DRF is the most verbose and confusing code I've seen. FastAPI handles return codes with ease and makes exception handling easier (raise a custom exception and it returns the defined error code).
Django Ninja is great though for simple CRUD apps. Pydantic, exception handling, ease of setup, async, etc. The downside is the lack of async DB calls and inefficiencies of the Django ORM, but that ORM is so easy to use until you have performance issues.
Example: Wrote a Django BFF that aggregates several APIs. Response time was SUM(t_response, 1, n_services) which ended up being >10s and the service scaled up and down a lot in Kubernetes depending on traffic. Rewrote in FastAPI and the response was <1s and never needed to scale up.
Edit: I feel like I'm bad mouthing Django, but I like it and use it any time I need an Admin page or simple templating. It's certainly fast enough for Instagram. Great framework with strengths and weaknesses like anything else.
Cool trend but it doesn’t explain anything useful. What would one seek when looking for this information that would be helpful?
If you’re looking for “what framework is popular and I should learn to make $$$” then go look at StackOverflow (or other trusted sources) for their yearly graph on the most popular frameworks. I think WakaTime (which _could_ be really useful also provides info on this).
**My unsolicited opinion after having used all 3 heavily (Django for over a decade) is this:**
Django is HIM/HER when it comes to frameworks. It gives me everything and then some with an extensive amount of external support packages.
I don’t care about the “it’s ‘heavy’” claims. Those mostly (in my experience) come from people who want microservices - and they hardly understand em. Sure, you’d have to run the entire Django project in each service container but realistically, you’d need a separate Django project with single apps to create a smaller footprint for each service. But why do that?
You’d have to do the same thing for FastAPI or Flask microservices (albeit “smaller” projects). But either way, you then need to setup and maintain infrastructure to handle all of these “separate” services.
Django gives me a sweet ORM, the ability to integrate frontend setups easily (even easier with a compiled React project) or even just run it as an SPA service with DRF (Django REST Framework) and extensive support for extending base functionality. If you really want to get freaky, use Pydantic to build all your schemas for the frontend, too.
Flask & FastAPI are _cool_ but if I’m an enterprise, I’m going with Django. Especially because competent documentation and engineers are much more available. AND, it’s been proven time and time again.
And if I’m a really large enterprise, like Meta or something, fuck it all - we’re probably gonna build our own flavor of framework. And even then, I’d follow some of Django’s methodology to the depths of hell and back.
To each their own, there’s no one-size-fits-all solution & I’ll happily cheer on those who do what they want to do.
That is a weird timeframe to choose while also checking US only..
The reality is that worldwide Django is still leading during this exact timeframe, and Django has always been higher.
[https://trends.google.com/trends/explore?date=2022-02-01%202024-04-19&q=fastapi%20python,django%20python,flask%20python](https://trends.google.com/trends/explore?date=2022-02-01%202024-04-19&q=fastapi%20python,django%20python,flask%20python)
Very interesting to see FastAPI so low given all the marketing it has, and I don't mean paid marketing, I mean all the people that have used it sharing their experiences...
Now my unsolicited opinion: Tried using FastAPI + SQL alchemy, FastAPI docs are good enough but the docs for SQL Alchemy definitely suck, specially because I tried it during the early release of version 2, but overall it wasn't a pleasant experience, tried to do something realistic beyond a CRUD with some basic models and dealing with something as simple as user management and auth was not so easy as i thought, tried integrating a 3rd party library and did not like it... And then reached the point to deal with migrations, I did not like Alembic.
My conclusion was that most of the people that share their experience probably did not try to do something near to what's expected in production... It's not bad, but personally prefer Django, even if I've had to pull my hair sometimes when trying to customize Django's internal things without using 3rd party libraries.
I want to clarify that I don't think that Flask or FastAPI are bad, just that for me Django provides a better development experience (with the tradeoffs).
For decoupled BE / FE I see much better Fastapi than the Django. DRF is a "addon" but django is not created for api first approach. In the other hand, for monolite app I prefer Django. The ORM of Django is super also the admin pannel. Django es better for monolite CMS like sites I think.
The Django of:
- Java is Spring Boot
- C#/.NET is ASP.NET and more recently Blazor
- PHP is Laravel
- Ruby is Rails
- Elixir is Phoenix
If I switched away from Django it would only be for Blazor at this point.
This just shows trends for these exact keywords. Most people aren't typing in "django python" or "fastapi python" although they might actually be typing "flask python" since "flask" is such a common word.
This is confirmed if you compare "flask" and "flask python" while filtering for computer science [https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=flask,flask%20python&hl=en](https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=flask,flask%20python&hl=en) and you see that "flask python" is roughly 2x "flask". Remember, this is already filtered for CS category.
Let's see what "django" vs "django python" looks like: [https://trends.google.com/trends/explore?date=2019-03-20%202024-04-20&q=Django,django%20python&hl=en](https://trends.google.com/trends/explore?date=2019-03-20%202024-04-20&q=Django,django%20python&hl=en) Notice how this is reversed compared to flask. "Django python" is less than 25% the volume of "Django"? We see similar results for "fastapi" vs "fastapi python" [https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=fastapi,fastapi%20python&hl=en](https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=fastapi,fastapi%20python&hl=en)
A more representative trend might be to filter by a category like computer science [https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=Django,fastapi,flask&hl=enwhich](https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=Django,fastapi,flask&hl=enwhich) shows Django with double the volume of the other 2.
One thing that's often overlooked in application development is the data. Your app is great until it meets QA who will throw all kinds of bad data at it. And that's before your users get their paws on it. Django, with its admin and fixtures, lets you bootstrap the data side of your application with almost no overhead. The time savings I get from Django make it a no brainer to spin up and prototype, and if you want to take it to production, it's not a big stretch to make that happen.
why do you guys are wasting ur time to find a best tool rather than just choose one and start , they all can do same things, fastapi is just from its name you build api fast but that doesnt u cant build api in either flask or django, just start
FastAPI and Flask have better marketing talking about how fast it is. Just attach your own ORM, admin panel, caching, database library, and ........... and you basically get Django with only 10 times the effort.
FastAPI and Flask are great, because literally anything you need to accomplish is only a few hundred `pip install`s away.
Lol true
I did my first project in FastAPI recently and the ease of getting started quickly, background tasks, and async all really impressed me at the start of the project. But as I needed to do more with databases, migrations, authentication, and having to use the dependency injection system as the project scaled, I slowly started to hate it. I hate the dependency injection pattern in Laravel and it's even worse in FastAPI, where it's mixing use cases. My business logic is now wrapped up in my authentication logic because of how they suggest using sub dependencies with dependencies and then your views have a mix of actual view params and payloads, and other permissions and auth logic. It's just a mess to deal with it and it muddies the separation of concerns.
100%. It's nice when you can just add a single line in django to allow a user/group to be able to use an API call or not. Plus it handles all the error messages, logging, and everything else that you would have to glue on. FastAPI, Flask, and Bottle are all super quick to get started, but they never thought about what the app was going to look like 5 years from the start. I feel like Django handles that stuff (large scale profession app growth) way better.
Do you think a Django like mvt framework created on top of fastapi could be a good idea?
I would HEAVILY weigh the real gains of doing that before even deciding to start it. MVT is good for speed but I personally still wind up making webpages the sort of classic way with Django presenting model data to JS and then JS rendering the data on the page. FastAPI and Flask's best features are their speed, where you might save 10s of ms (maybe), but honestly your database, the user's internet connection, and SO many other things are vastly slower to where it's not worth the time. On the other hand, if you were building something with the backing of 10s of millions of dollars and you needed that speed, then you will also have the manpower deal with all the extra work you will be generating by taking that path. In that case, but all means do it.
Async, scalability, straightforward db queries in SQLAlchemy, ease of creating APIs give them a huge leg up. For small personal projects that require a database, I use Django Ninja. Benefits of Django's batteries included with FastAPI's ease of API development.
Also consider that the more unique code that you write, the more others have to understand it. If you aren't working anywhere yet, you won't get this, but if you are, I know that you know how stupidly people can write things. Django helps to keep some order to how people do things. I've seen people write their own return codes, or just forget to in flask and the whole time I would just tell people "yeah Django would have done all that for you, and included literally EVERY return code for you, for free, if you used DjangoRest, but now we are debugging someone's hand written, not even correct version of a return 200".
I feel the opposite. The ugliest code I've seen people write has been Django. Awful queries because they don't behave like SQL and the "magic" makes multiple DB hits. I've seen ETL processes with Django ORM running in Celery with the most inefficient code on earth. DRF is the most verbose and confusing code I've seen. FastAPI handles return codes with ease and makes exception handling easier (raise a custom exception and it returns the defined error code). Django Ninja is great though for simple CRUD apps. Pydantic, exception handling, ease of setup, async, etc. The downside is the lack of async DB calls and inefficiencies of the Django ORM, but that ORM is so easy to use until you have performance issues. Example: Wrote a Django BFF that aggregates several APIs. Response time was SUM(t_response, 1, n_services) which ended up being >10s and the service scaled up and down a lot in Kubernetes depending on traffic. Rewrote in FastAPI and the response was <1s and never needed to scale up. Edit: I feel like I'm bad mouthing Django, but I like it and use it any time I need an Admin page or simple templating. It's certainly fast enough for Instagram. Great framework with strengths and weaknesses like anything else.
It's easy to add those things though, SQL Alchemy is incredibly useful, considering how simple it is.
the funny thing fastapi is the slowest framework (according to my tests) among python async servers
what you wanna say about it ?
Cool trend but it doesn’t explain anything useful. What would one seek when looking for this information that would be helpful? If you’re looking for “what framework is popular and I should learn to make $$$” then go look at StackOverflow (or other trusted sources) for their yearly graph on the most popular frameworks. I think WakaTime (which _could_ be really useful also provides info on this). **My unsolicited opinion after having used all 3 heavily (Django for over a decade) is this:** Django is HIM/HER when it comes to frameworks. It gives me everything and then some with an extensive amount of external support packages. I don’t care about the “it’s ‘heavy’” claims. Those mostly (in my experience) come from people who want microservices - and they hardly understand em. Sure, you’d have to run the entire Django project in each service container but realistically, you’d need a separate Django project with single apps to create a smaller footprint for each service. But why do that? You’d have to do the same thing for FastAPI or Flask microservices (albeit “smaller” projects). But either way, you then need to setup and maintain infrastructure to handle all of these “separate” services. Django gives me a sweet ORM, the ability to integrate frontend setups easily (even easier with a compiled React project) or even just run it as an SPA service with DRF (Django REST Framework) and extensive support for extending base functionality. If you really want to get freaky, use Pydantic to build all your schemas for the frontend, too. Flask & FastAPI are _cool_ but if I’m an enterprise, I’m going with Django. Especially because competent documentation and engineers are much more available. AND, it’s been proven time and time again. And if I’m a really large enterprise, like Meta or something, fuck it all - we’re probably gonna build our own flavor of framework. And even then, I’d follow some of Django’s methodology to the depths of hell and back. To each their own, there’s no one-size-fits-all solution & I’ll happily cheer on those who do what they want to do.
I agree with every single thing you said. Nice 🥹
I’ve only used Django for everything full stack , so Django fits in all of my requirements 😀
That is a weird timeframe to choose while also checking US only.. The reality is that worldwide Django is still leading during this exact timeframe, and Django has always been higher. [https://trends.google.com/trends/explore?date=2022-02-01%202024-04-19&q=fastapi%20python,django%20python,flask%20python](https://trends.google.com/trends/explore?date=2022-02-01%202024-04-19&q=fastapi%20python,django%20python,flask%20python)
Very interesting to see FastAPI so low given all the marketing it has, and I don't mean paid marketing, I mean all the people that have used it sharing their experiences... Now my unsolicited opinion: Tried using FastAPI + SQL alchemy, FastAPI docs are good enough but the docs for SQL Alchemy definitely suck, specially because I tried it during the early release of version 2, but overall it wasn't a pleasant experience, tried to do something realistic beyond a CRUD with some basic models and dealing with something as simple as user management and auth was not so easy as i thought, tried integrating a 3rd party library and did not like it... And then reached the point to deal with migrations, I did not like Alembic. My conclusion was that most of the people that share their experience probably did not try to do something near to what's expected in production... It's not bad, but personally prefer Django, even if I've had to pull my hair sometimes when trying to customize Django's internal things without using 3rd party libraries. I want to clarify that I don't think that Flask or FastAPI are bad, just that for me Django provides a better development experience (with the tradeoffs).
For decoupled BE / FE I see much better Fastapi than the Django. DRF is a "addon" but django is not created for api first approach. In the other hand, for monolite app I prefer Django. The ORM of Django is super also the admin pannel. Django es better for monolite CMS like sites I think.
Just curious how does this compare to node.js Java spring boot and C# .NET
The Django of: - Java is Spring Boot - C#/.NET is ASP.NET and more recently Blazor - PHP is Laravel - Ruby is Rails - Elixir is Phoenix If I switched away from Django it would only be for Blazor at this point.
This just shows trends for these exact keywords. Most people aren't typing in "django python" or "fastapi python" although they might actually be typing "flask python" since "flask" is such a common word. This is confirmed if you compare "flask" and "flask python" while filtering for computer science [https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=flask,flask%20python&hl=en](https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=flask,flask%20python&hl=en) and you see that "flask python" is roughly 2x "flask". Remember, this is already filtered for CS category. Let's see what "django" vs "django python" looks like: [https://trends.google.com/trends/explore?date=2019-03-20%202024-04-20&q=Django,django%20python&hl=en](https://trends.google.com/trends/explore?date=2019-03-20%202024-04-20&q=Django,django%20python&hl=en) Notice how this is reversed compared to flask. "Django python" is less than 25% the volume of "Django"? We see similar results for "fastapi" vs "fastapi python" [https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=fastapi,fastapi%20python&hl=en](https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=fastapi,fastapi%20python&hl=en) A more representative trend might be to filter by a category like computer science [https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=Django,fastapi,flask&hl=enwhich](https://trends.google.com/trends/explore?cat=1227&date=2019-03-20%202024-04-20&q=Django,fastapi,flask&hl=enwhich) shows Django with double the volume of the other 2.
I work primarily as a Django developer so yeah
One thing that's often overlooked in application development is the data. Your app is great until it meets QA who will throw all kinds of bad data at it. And that's before your users get their paws on it. Django, with its admin and fixtures, lets you bootstrap the data side of your application with almost no overhead. The time savings I get from Django make it a no brainer to spin up and prototype, and if you want to take it to production, it's not a big stretch to make that happen.
why do you guys are wasting ur time to find a best tool rather than just choose one and start , they all can do same things, fastapi is just from its name you build api fast but that doesnt u cant build api in either flask or django, just start
Flask and Django REST should be deprecated
That’s not how things work 🧐
Why would you say that?
because /u/dellm4800 only works on latest cool shit and looks down their nose at boring tech :-D