Your tutorials were a huge influence on me as I began learning to code in my late 20’s and had a profound impact allowing me to start two companies and helped give me a toolset I didn’t have before. Thanks for all you do!
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?
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.
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.
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.
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.
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.
Your Flask tutorials are my webapp I Ching. Thanks a bunch. Just about to launch another Flask webapp in the next few weeks, and your tutorials are invaluable.
Oh! Before I forget - flask-migrate! Lifesaver! Thanks Miguel!
No questions, just praise: I loved this tutorial, it was hugely helpful to me when I was just getting into python and I regularly recommend it. Thanks for writing it and sharing it!
Same as most of the replies, just wanted to send my thanks for the tutorial. I used your original tutorial (before the function name change) for my dissertation platform and its been running for 6 years now.
Hi, I never finished your tut but it was a impressive to see the surface covered. I'm curious, are you still using flask ? have you tried FastAPI or Django or something else ?
This is really a matter of preference. I do not use Flask-Admin on my projects, I have always preferred to design my own admin pages than being forced to accept the choices that are imposed by these big extensions. This allows me to have a consistent UI across admin and non-admin pages.
One thing that people often complain is that it is hard and/or tedious to build tables with data, which is one of the building blocks most admin pages need. Last year I wrote a blog article where I show how I build tables in my Flask apps: https://blog.miguelgrinberg.com/post/beautiful-interactive-t....
I think that Flask has many great extensions, but in my opinion, installing flask-admin is just a tacit admission that you really wanted to use Django instead.
Hey Miguel, wanted to thank you for creating this tutorial. It started my freelancing career and I created great projects based on it. Thank you very much!
Happy to see people continue to find my tutorial useful and relevant. If you have any questions, I'll be happy to answer.