Hacker News Reader

Comment by iknownothow | Hacker News Reader

What do you think about the current state of Flask and Flask extensions? Are they being maintained and up to date? Or would it better to go with FastAPI and use its non-async features to have the same Flask like experience?

View on HN

Something that I think not everybody realizes is that Flask does not require extensions for most things. The extensions are nice because they integrate with the Flask configuration object, and with before/after request handlers when it makes sense, but none of that is required. If an extension stops being maintained, you can always find a newer general purpose Python package that does what you need and just use it in your Flask app.

Now this is my personal opinion, but you cannot say the same about FastAPI. Even though the ecosystem of asyncio compatible libraries has grown, it is still several orders of magnitude smaller than what is available for standard non-async Python. So in my view, in terms of access to 3rd party libraries Flask is a better choice.

But if you use FastAPI and completely ignore the async aspects, you get some handy tools out of the box, Swagger/Pydantic integration being the big one. Then you're in roughly the same place as Flask where you're just using general python packages. I struggle to see any advantages to Flask vs one of Django or FastAPI at this point.

This is probably quite unpopular, seeing as the FastAPI docs have been so praised in the past... but I really dislike how FastAPI is documented, which has really put me off of the project.

The FastAPI docs read like a full project, a very dense project. Sometimes you just want to learn about a specific feature, but you walk into a page that assumes you have the context of the previous chapters, that puts me off a lot.

I also dislike how some of the documentation is absolutely enormous (the SQL chapters is one example), but I suspect this might have to do with the not-so-simple approach FastAPI takes, as opposed to Flask, which is indeed very simple.

I really can't join the crowd here. I don't think FastAPI is a replacement for Flask, even when async is taken out of the equation. Flask has some weird quirks to it (like "g"), but it really is a beautiful and simple API for the web.

I like FastAPI and using it feels nice.

But it could _really_ do with some "Reference" documentation. Sometimes I just want to know exactly what a call does or what the various parameters mean.

I agree. There are generally 4 types of documentation as per the diagram in this page[0] and FastAPI’s solely focuses on the top left quadrant and falls flat on the lower right.

[0] https://documentation.divio.com/

I agree with you entirely about the issues with the docs, there is no API reference, and Tiangolo has rejected PRs with automated documentation before. I by no means think the project is perfect, but I think it is a better starting point for most small projects. I just don't see any advantage to Flask at this point unless you specifically want to use one of tiny handful of Flask-X packages that are actually worthwhile.

One major advantage Flask has over FastAPI is maturity. FastAPI has 1000+ open issues on Github vs 14 for Flask. That is quite scary.

It's interesting the see the number of open issues of popular python projects:

Pytorch, 8400

Pandas, 3400

Tensorflow, 2100

jupyter notebook, 2000

scikit-learn, 1500

pytest, 720

requests, 170

The outlier seem to be Flask.

You picked mainly data science python projects. It would make more sense to compare with other python web frameworks.

django, 1101 open, 32662 closed

cherrypy, 218 open, 1505 closed

starlette, 31 open, 570 closed

pyramid, 70 open, 966 closed

falcon, 168 open, 789 closed

flask, 14 open, 2318 closed

fastapi, 1044 open, 1855 closed

Fast api has one of the worst ratio regarding open/closed issues.

I wanted to add django but their issues aren't on github as they are using their own system. IMO an external issue tracker lead to a higher barrier to create new issues, so this isn't not necessary fair.

Also fastapi allows people to ask questions with the issues. On the 1000+ open issues, 826 are tagged as question.

It's hard to find a fair metric. Open/close ratio rewards older project with fluctuating/stable popularity. Fastapi popularity is still growing[0], so having some difficulties to work on issues is expected.

[0] -- https://trends.google.com/trends/explore?date=today%205-y&q=...

Not sure what you mean by "ignoring async". If you write your handlers as regular functions, I would imagine FastAPI is going to send them to run in an executor. So all the concurrency benefits of FastAPI go down the drain, and now your concurrency is based on threads.

As far as Swagger integration, you can use APIFairy with Flask and get similar type of auto-generated docs. Disclaimer, APIFairy is an extension that I created: https://github.com/miguelgrinberg/APIFairy

But then it would be on par with Flask, both performance wise and with regards to integration with third party libraries. That is how I'm currently using FastAPI, with regular sync SQLAlchemy for example.

The difference is that even without the benefits of async, FastAPI offers a vastly better developer experience IMHO, with its integration with Pydantic, Python type hints and the lack of reliance on global objects

I think you are oversimplifying this. If you don't know how FastAPI handles sync code, then you can't claim it is on par with Flask. I suggested it might use an executor, after looking in their code, they use a thread pool support in Starlette, which in turns imports this thread pool logic from AnyIO. I see no easy way to determine what is the size of the pool. Clearly this isn't designed as a main way to run code, it is just a quick way to run sync code w/o blocking the loop. I would not consider this up to par with the concurrency you get from Gunicorn or uWSGI using a configurable thread or process pool.

Reply on news.ycombinator.com