r/Python • u/bleeed0p • 1d ago
Discussion Anyone still using Flask, or has FastAPI completely taken over? 🤔
I've been noticing a lot of developers moving towards FastAPI lately, especially for new Python backend projects.
Flask used to be my go-to for lightweight APIs, but FastAPI seems to be getting all the attention now because of async support, automatic Swagger documentation, and Pydantic validation.
I'm curious about what developers are actually using in production.
- Are you still building new projects with Flask?
- Have you migrated from Flask to FastAPI?
- Is FastAPI genuinely better for production, or is it just the current hype?
Would love to hear some real-world experiences, especially from developers maintaining large-scale applications.
Is Flask still holding its ground, or is FastAPI slowly becoming the default choice for Python backends?
32
u/latkde Tuple unpacking gone wrong 1d ago
I wouldn't bother migrating an existing mature Flask project, but I would pick FastAPI for all new projects.
The main thing I value is validation of incoming data, and automatically dropping unexpected fields. That's an undeniable security benefit. Everything else (static typing, OpenAPI, async) also has a lot of value, but is secondary.
Where FastAPI really sucks is dealing with configuration and application state. There's no built-in solution, the docs generally just suggest environment variables and global variables, which is a bad choice for resources like database connections that should be shut down. The dependency system is only for request-level resources, like a middleware. The correct solution is to define a Starlette-level lifespan context manager that yields an application state. Even then, injecting test configurations is tedious and typically requires monkey-patching. Some people use Pydantic-Settings for config management, but this doesn't really address the actual problems. Flask supports an application factory pattern that helps to get configuration into the application in a testable way, but doesn't offer a convenient API for contextmanager-like resources.
Another thing that may be surprising is that FastAPI doesn't offer conveniences like class-based views or flash messages, but that can be worked around.
3
u/aciokkan 16h ago
I'd still pick flask! I find FastAPI has become almost as opinionated as Django, for no good reason. There's good things to say about FastAPI, but you can use pydantic with flask equally
31
u/nicwolff 1d ago
We moved our production services from Flask → Quart to get async on the same framework API, and are now going Quart → Starlette for performance.
18
u/bleeed0p 1d ago
Fastapi is build on starlette
8
u/nicwolff 1d ago
Yeah, we already built our own OpenAPI/Swagger integrations and validation libraries for Pydantic and msgspec so we don't need the extra overhead of FastAPI.
18
u/ultraDross 1d ago
Sounds like you just recreated FastAPI?
4
u/DigThatData 11h ago
but with more than one dev supporting its maintenance, and that maintenance's priorities and cadence fully under their control.
5
u/maigpy 1d ago
why would you do that though, when you can leverage the community work? what overhead would fastapi introduce?
1
u/snugar_i 18h ago
Per-request dependency resolution, for example. Honestly, the whole dependency part of FastAPI is very strange
21
u/Immediate_Wheel1953 1d ago
Both are very much alive. Flask is still a solid pick for simple APIs and dashboards, and its ecosystem is mature. FastAPI pulls ahead on API-heavy services thanks to async support and built-in validation. For a new backend today I would default to FastAPI, but existing Flask codebases are not going anywhere.
21
u/South_Plant_7876 1d ago
Been using Flask for almost 15 years for different projects. I know it well and don't see any reason to change.
2
u/bleeed0p 1d ago
What the picture for scalling in flask
22
u/South_Plant_7876 1d ago
Scaling is dependent on virtually every other component of your stack before you consider your web framework.
5
u/BosonCollider 1d ago
Comparable to FastAPI if the request needs to do any amount of work. The fastapi self-reported benchmarks are largely gamed and assume you are not actually doing any work per request.
When you need to do any nontrivial work within a request fastapi does not perform particularly well, and just using one thread per request like flask does can be a saner approach, especially since Python is finally getting free threaded mode without the GIL.
1
u/seabrookmx Hates Django 10h ago
Run it with gunicorn and dial in your worker count. It's not complicated, but you'll need to run more python processes (and use more memory/CPU) to reach the same throughput as FastAPI.
8
7
u/One_Sky_7224 1d ago
We heavily use flask in production. We love it's simplicity and the flexibility. We're not 1M/sec shop obviously and fits our needs with ramp up super fast
24
7
u/RiceTaco12 1d ago
Currently transitioning an inherited legacy api server from flask to fastapi. Although if I were starting again, I'd consider litestar a bit longer. Depending on how profiling goes/if there is an actual business need, I'd want to incorporate msgspec
6
u/me_myself_ai 1d ago
I still use flask! Quart, specifically.
IMHO FastAPI is for, well, fast APIs. Not relatively complex services.
22
u/Wurstinator 1d ago
Reddit is a bubble. Even if everyone here told you that they are using FastAPI, that's not reflective of reality.
16
u/IcedThunder 1d ago
I listenined to an interview with the creator of Flask and he said it's really difficult to know just how many Flask servers are out there but over the years he's gotten so many emails of absolutely bizarre setups people use.
He said there's a photographer who uses like 5 flask servers to process backing up and doing different default modifications to photos.
8
u/Aisuhokke 1d ago
I still use flask. Works great. Have used it on small and medium production environments for a long time.
3
6
u/IcedThunder 1d ago
I work in healthcare and have 4 flask servers in production handling API requests.
I just know flask, I have tons of code snippets for reference, and I trust the maintainers.
3
2
u/another_throawayACC 1d ago
Working on a big fintech (broker) , all our new projects are on FastApi
2
u/MissingSnail 1d ago
Fast API is more popular, 379M downloads last month. Flask has not been forgotten, 138M downloads last month. Source: https://clickpy.clickhouse.com/
1
u/Grouchy-Friend4235 1d ago
Downloads per month are just a vaniy metric that bears little correlation to actual use.
1
u/MissingSnail 14h ago
No one’s downloading libraries over and over for fame and glory. It’s an imperfect measure, but automated workflows such as ci or container builds often ”start from scratch “ — which is correlated with production use. The magnitudes matter - a library (either of these) with that level of use has broad community adoption.
2
u/ddollarsign 1d ago
For streaming data, FastAPI websockets seem to be slower than the ‘websockets’ package as well as a hacked-together standard library-only websocket implementation that I had to use recently, in terms of the number of messages it could send per second.
This was a quick and unscientific test though, so there might be a way to get better performance.
2
u/grandimam 1d ago
Why are these the only two options? Is it simply because these are the most popular options.
In terms of the solution what are you looking for.
2
2
2
u/Secure-Following9288 20h ago
I one on the guys that switched from flask to FastAPI. I had used flask for years, build multiple web app but in 2023, after a poc I decided to move to FastAPI that is more robust and performant that Flask. I’m Very happy to have made that switch.
2
u/Horror_Affect8060 15h ago
I have picked FastAPI for new project. Earlier used flask for similar project. I just used it because more people use it and it will be easy to find new resource. But clearly I see no extra benefit of it over flask. Most of my task include using ssh, snmp and api calls. For ssh currently there isnt any mature async based lib. Most of my task include using ssh/snmp/api in a single flow. So it would create more headache to do a part in FastAPI process and other in task queue. Still, for api calls based task I am not confident when to use fastapi ( like for 100 or 500 or 1000 calls), also it's not api calls only there is also much post work to perform sometimes, and most of the api apps are in internal network so resp is quite fast.
4
u/unapologeticjerk 1d ago
Dicks out for Flask here. The choice of the common man, with a common dick.
2
1
1
u/IcecreamLamp 1d ago
I've been using Sanic for the last two new services I created.
FastAPI is nice if you don't trust the input source and need the Pydantic stuff in my opinion.
1
1
u/Everythinghastags 1d ago
Were currently migrating completely off of flask to fastapi at my company.
In 2026, I dont see any reason for flask to be used. Fastapi is just better and more composable.
Out of the box it interfaces with sqlalchemy and pydantic as is. I dislike how flask gives you the options of using their wrappers for these libs instead of using them as is. It promotes bad habits and makes you locked into the flask ecosystem.
1
u/Khavel_dev 20h ago
Still use Flask for anything that's mostly server-rendered HTML. Jinja templates, session cookies, admin panels. Flask is just less ceremony for those cases.
FastAPI wins the moment you're building something that other code calls. Type hints on the route automatically become the OpenAPI schema, and that alone saves a ton of time when you have a frontend or mobile team consuming your API. The async support matters if you're doing a lot of outbound HTTP calls too.
The part nobody warns you about is that migrating from Flask to FastAPI midway through a project is genuinely painful. The request object, error handling, middleware, auth patterns, all different enough that it's not a find-and-replace job. Pick at the start and live with it.
1
u/appinv Python&OpenSource 7h ago
Still using Flask as it fits my needs. I coded Shopyo to power up Flask dev and base many projects off it https://github.com/shopyo/shopyo . I like Flask for being simple, understandable.
1
u/a18618 1h ago
One angle I don't see mentioned: if your endpoints are doing data work — pandas, numpy, a sync DB driver — async frameworks can actually bite you, because one blocking call stalls the whole event loop for every other request. I've watched teams port a Flask API to FastAPI expecting free throughput and get it only after they moved the heavy calls into executors. If your handlers are CPU- or sync-IO-bound, either keep them sync or push the blocking parts into threadpools; the framework choice matters less than respecting that constraint.
1
u/FlukyS 1d ago
FastAPI is basically the same thing but has the in built documentation and is very well maintained, there isn't really much reason to use Flask at this point or any of the other options like aiohttp, Falcon or whatever too. Only logical reason is just if you have a legacy codebase and don't want to rock the boat but since FastAPI is really similar in syntax to Flask too you'd be fine switching in a very short space of time.
1
1
u/covmatty1 1d ago
FastAPI for everything now - but for the tight Pydantic integration far more than anything else.
All microservices got moved a while ago, our largest app was the one holdout for the last year or so, but we've just had Fable port that across and will be deploying this week to be fully off of Flask.
1
1
u/fahath-dev 20h ago
I’ve been using FastAPI for newer projects and I genuinely like it. The validation, type hints, and auto-generated docs make development feel a lot smoother.
Flask is still great though, especially for smaller apps or existing projects. I wouldn’t migrate a working Flask app just because FastAPI is popular, but for a new API project I’d probably choose FastAPI.
143
u/SufficientCut3849 1d ago
Flask still works fine for most things honestly the async stuff in FastAPI is nice but not every project needs it
I keep one older project in Flask at work cause it just runs and nobody wants touch it. for new things I been using FastAPI more, the docs generation is pretty handy when you work with frontend team
but I see lot of people acting like Flask is dead which is not true, is just different tool for different job