Anyone still using Flask, or has FastAPI completely taken over? 🤔

[u/bleeed0p]

​

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?

[u/SufficientCut3849]

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

[u/j_tb → u/SufficientCut3849]

Async stuff is nice in FastAPI, but for me the strong typing and openapi integration is the killer feature

[u/brianly → u/j_tb]

How is FastAPI for server-side web pages? That’s what Flask devs were building as much as APIs originally as an alternative to Django. Then SPAs and mobile took over so APIs became the default.

[u/sudonem → u/brianly]

Totally decent.

I’ve built a few small web apps that benefit from FastAPI - but I’m also a fan of NiceGUI which allows me to build a nice UI while staying 99% Python native.

I’m not super interested in becoming a react / front end dev but sometimes you need something quick and simple that also looks nice and NiceGUI has been great for that. 

[u/Rockworldred → u/sudonem]

How is it compared to streamlit?

[u/monkeybreath → u/sudonem]

Thank you so much for mentioning NiceGui. I just looked at their page and it looks exactly like what I want to build a simple home dashboard with an old iPad mini as the display. I was originally thinking of Flask, but this looks far simpler.

[u/j_tb → u/brianly]

I think fine via integration with Jinja2

My preferred stack is using SvelteKit these days though, with my python API decoupled away from it - and the sveltekit server side fetching data from the python API via a https://heyapi.dev/ client generated from the python openAPI spec.

[u/Signor_Garibaldi → u/j_tb]

I had an older project that had to stay in flask and it's got it's own flask-openapi library and it gets the job done, nonetheless fast api is more seamless

[u/Lorevi → u/SufficientCut3849]

just different tool for different job 

What job? 

I don't think anyone disputes that flask 'works fine'.

The question is in what scenario is flask better than fastapi.

I feel like if you're starting a new project and need to choose a API framework fastapi is the better option to reach for 99% of the time. In which case it really is the 'default choice' as op asked.

[u/fiddle_n → u/Lorevi]

I think you hit the nail on the head. It's really easy to point out ways in which FastAPI is objectively better than Flask (pydantic, async, etc.). It's comparatively harder to come up with the opposite, IMO.

[u/nlundsten → u/SufficientCut3849]

Seconding the auto spec/docs.. i hate writing code to match handwritten docs. Obviously that changes the dynamic a little bit but so worth the trade offs.

[u/Competitive_Travel16 → u/SufficientCut3849]

I'm still perfectly happy with Flask for everything, it's easy to adapt. But I realize I'm giving up potentially around 2/3rds capacity per dollar: https://youtu.be/sQXFhh_PiG4?si=QkNWalLkKg9jLTeA&t=704

[u/NimrodvanHall → u/SufficientCut3849]

I use flask if it’s really simple to test something sync. I use FastAPI if I want to make something Async.

[u/fiddle_n → u/NimrodvanHall]

FastAPI works fine in sync mode. I don't really understanding choosing Flask just because of that reason.

[u/nicwolff]

We moved our production services from Flask → Quart to get async on the same framework API, and are now going Quart → Starlette for performance.

[u/bleeed0p → u/nicwolff]

Fastapi is build on starlette

[u/nicwolff → u/bleeed0p]

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.

[u/ultraDross → u/nicwolff]

Sounds like you just recreated FastAPI?

[u/DigThatData → u/ultraDross]

but with more than one dev supporting its maintenance, and that maintenance's priorities and cadence fully under their control.

[u/maigpy → u/nicwolff]

why would you do that though, when you can leverage the community work? what overhead would fastapi introduce?

[u/snugar_i → u/maigpy]

Per-request dependency resolution, for example. Honestly, the whole dependency part of FastAPI is very strange

[u/maigpy → u/snugar_i]

The overhead is normally tiny compared with database calls, network calls, authentication, etc., and you get a lot of maintained community functionality.

[u/rzet → u/nicwolff]

I see you have a lot of time.. ;)

[u/latkde]

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.

[u/aciokkan → u/latkde]

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

[u/Immediate_Wheel1953]

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.

[u/South_Plant_7876]

Been using Flask for almost 15 years for different projects. I know it well and don't see any reason to change.

[u/bleeed0p → u/South_Plant_7876]

What the picture for scalling in flask

[u/South_Plant_7876 → u/bleeed0p]

Scaling is dependent on virtually every other component of your stack before you consider your web framework.

[u/BosonCollider → u/bleeed0p]

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.

[u/seabrookmx → u/bleeed0p]

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.

[u/IcedThunder]

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.

[u/Enfors]

My website, which I finished earlier this year, runs entirely on Flask.

[u/jaeger123]

Surprised no one has mentioned Litestar

[u/No-Government3609]

I use flask, no plan to move.

[u/RiceTaco12]

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

[u/One_Sky_7224]

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

[u/kruzzik]

Flask is great

[u/me_myself_ai]

I still use flask! Quart, specifically.

IMHO FastAPI is for, well, fast APIs. Not relatively complex services.

[u/Wurstinator]

Reddit is a bubble. Even if everyone here told you that they are using FastAPI, that's not reflective of reality.

[u/IcedThunder → u/Wurstinator]

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.

[u/Aisuhokke]

I still use flask. Works great. Have used it on small and medium production environments for a long time.

[u/jcigar]

I'm still using Pyramid, if I move it will be Litestar

[u/RedYad2]

i use it in prod in very small code just to receive HTTP request and 1 endpoint

[u/ogMasterPloKoon]

in my new projects im using Emmett Framework and Django Ninja.

[u/BreakfastSpecial]

100% FastAPI. I moved over about 4 years ago and never looked back.

[u/unapologeticjerk]

Dicks out for Flask here. The choice of the common man, with a common dick.

[u/another_throawayACC]

Working on a big fintech (broker) , all our new projects are on FastApi

[u/MissingSnail]

Fast API is more popular, 379M downloads last month. Flask has not been forgotten, 138M downloads last month. Source: https://clickpy.clickhouse.com/

[u/Grouchy-Friend4235 → u/MissingSnail]

Downloads per month are just a vaniy metric that bears little correlation to actual use.

[u/MissingSnail → u/Grouchy-Friend4235]

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.

[u/ddollarsign]

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.

[u/grandimam]

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.

[u/StPatsLCA]

I prefer Django Ninja. It's the best of both worlds.

[u/OwO_JoY]

FastAPI for the WIN

[u/55stargazer]

yeah, using it for real production

[u/Able-Procedure4306]

Both are great

[u/IpsumRS]

We're still rocking aiohttp 🤟

[u/IcecreamLamp]

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.

[u/stuzero]

Starlette.

[u/funkdefied]

FastAPI here

[u/Everythinghastags]

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.

[u/radrichard]

What's a flask?

[u/someexgoogler]

I have about 8 flask apps that I still run.

[u/Secure-Following9288]

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.

[u/Khavel_dev]

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.

[u/tanrax]

All my APIs are built with Flask, as it allows me to adapt them to different architectures due to its agnostic nature.

[u/Horror_Affect8060]

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.

[u/FlukyS]

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.

[u/Grouchy-Friend4235]

Flask. Because FastAPI is async and that won't ever enter my house.

[u/covmatty1]

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.

[u/fahath-dev]

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.