5 ms·
Sincere question - for starting greenfield projects, what would make you choose Flask over FastAPI[0]? [0] - https://fastapi.tiangolo.com/ https://fastapi.tian
by krat0sprakhar 5y ago
Sincere question - for starting greenfield projects, what would make you choose Flask over FastAPI[0]?
[0] - https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/
- easton 5y agoFlask has built in templating via Jinja2, FastAPI makes you hook up the templating library you want yourself. Not a big deal (I think it is literally like five lines or something) but if you are building a normal web app without a bunch of AJAX or a SPA on the frontend that might be relevant.
- ddorian43 5y agoFlask supports gevent.
- minimaxir 5y agoNote that Flask is more analogous to Starlette, which FastAPI extends. https://www.starlette.io/ https://www.starlette.io/
- qbasic_forever 5y agoI'd start with the higher level question, do I want a production Python deployment and all the headaches of deploying, managing, scaling, etc. that come with it? There are some fantastic things in the Python ecosystem that might make it worth going down that route. But if you're just chucking some templates at the results of basic CRUD API operations or simple business logic, etc. you might not need those headaches. IMHO go with whatever one you know and don't depend too much on any special features or framework-specific things that aren't critical. You're likely going to throw away and rewrite whatever you produce many times throughout its lifetime if it gets some legs and grows.
- glutamate 5y ago> production Python deployment and all the headaches of deploying, managing, scaling You seem to be suggesting that there is a much simpler / better alternative. What is it?
- qbasic_forever 5y agoI'm not being baited into that argument. If you're starting a greenfield project then one of the first priorities is picking the tech stack and considering all of the trade-offs therein. In some situations you and your operations team might value deploying a static binary with zero dependencies to manage--Python is not a good choice there. Or in other situations you might depend on scientific code and models which are difficult or impossible to port away from Python. There's no simple answer to your question.
- meowface 5y agoRespectfully, I think you were the one who was perceived as baiting people with your initial post because it seemed to be hinting in an aside that any Python project in general is difficult to deploy and then not elaborating; then kind of seen as further baiting people after multiple replies inevitably constructively asked you for clarification on what you were referring to and you seemingly dodged the question by saying they were baiting you and that you won't dignify them with an answer. It seems like it was probably just a misunderstanding due to an ambiguous way someone could interpret your post. I see what you likely actually meant, now, and that you probably weren't talking about some issue with Python but about different levels of complexity in deployment in general, but I also initially misinterpreted it like the other posters did and thought it was a jab at Python. So everyone was basically misunderstanding everyone else and mutually thought they were being baited even though they weren't, I think.
- PostThisTooFast 5y agoI resent your baiting-abating, which is really thinly-veiled baiting-hating.
- goatinaboat 5y agoYou seem to be suggesting that there is a much simpler / better alternative. What is it? Bottle is the simpler Flask
- jtdev 5y ago> “do I want a production Python deployment and all the headaches of deploying, managing, scaling, etc. that come with it?” What “headaches” have you encountered with Python/Flask in relation to deploying, managing, scaling? Specifically, what headaches have you encountered that are not present in every platform/language? Are you a NodeJS dev?
- Scarbutt 5y agoEcosystem around flask is bigger.
- stevenhuang 5y agoAs others mention, Flask has more batteries included in terms of built-in templating, ORM, etc, so it positions more as a backend webserver. FastAPI is more focused on making it easy to make APIs, especially with the built-in Swagger docs generation (I don't believe Flask has this out-of-the-box). So if your greenfield project is more web-based (clients are web browsers), Flask may be more suited. If your greenfield project is service-based (command line applications, or front end), FastAPI may be more suited. In both cases, it's as easy to substitute one for the other. Personally I'll be trying out FastAPI since the dev experience seems a lot nicer (integration with `pydantic`).
- systemvoltage 5y agoIt's also worth mentioning that FastAPI/Starlette are async and a bit more annoying to debug.
- _frkl 5y agoflask also supports async now, that's one of the main new features of this release.
- systemvoltage 5y agoI believe Flask 2.0 optionally supports it whereas FastAPI is async only. I could be wrong though. Edit: Thanks for the correction, my point is moot and irrelevant.
- pletnes 5y agoFastAPI happily supports both options in a gradual manner. Just start out sync and convert to async if you want on a per-route basis.
- tedivm 5y agoThat's not exactly accurate. When working with sync views FastAPI dumps them into a threadpool. It basically converts them to async on the fly. To quote the docs- > When you declare a path operation function with normal def instead of async def, it is run in an external threadpool that is then awaited, instead of being called directly (as it would block the server).
- varispeed 5y agoI wonder why should someone use either of those, if typically you'll end up with something Django like but less pretty? I sometimes use Flask if I need to spin up a tiny API, but for something bigger DRF and Django just saves time. I get that this stack is boring, but is battle tested, has no surprises and just works. If I need performance then I go for Golang.