6 ms·

Genuinely curious how you happened to choose FastAPI over something more in the middle, like Flask? I tried a few tools in FastAPI, and it's fantastic for thos

Genuinely curious how you happened to choose FastAPI over something more in the middle, like Flask? I tried a few tools in FastAPI, and it's fantastic for those, but I think I'd still stick with Flask for something more well rounded (not just as an API server).

clepto 5y ago
At least for my team we went with FastAPI because we have other tools for everything else, and FastAPI is incredibly simple for new members to pick up. We tend to say that we made a “FastAPI application” but in reality FastAPI is only powering the REST interface for interacting with the platform. We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together.
- Nextgrid 5y ago
  > We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together. Just wondering, why have you not gone with Django directly if you’ve essentially ended up reimplementing your own version of it?
  - fernandotakai 5y ago
    that's how i feel about all these python "micro frameworks". you start simple, but then you realize you need some kind of db access, some kind of caching, some kind of authentication, maybe some admin interfaces.... aaand you re-implemented django yet again.
    - Nextgrid 5y ago
      Exactly the reason why I don’t care about either FastAPI or Flask. In my experience you’ll always need more than what it comes with out of the box and you’ll end up building your own (crappy) Django.
  - clepto 5y ago
    There wasn’t really an aversion to or direct decision to not use Django, it just kind of naturally evolved. We were experimenting with FastAPI in some mock APIs used for test suites and some different projects and decided to incorporate it into a larger project. The pulling in of other tools happened naturally over time. Perhaps we reinvented the wheel and Django may have saved some time or effort, but ultimately in the end we gained a very deep knowledge of the system we have and the things that make it work, and how those individual pieces might be usable in other projects/scenarios. A large driver was honestly just that we had no organizational experience in Django, and so there was no one that even would have looked at it and said “Hey we’re just recreating what Django already does”.
aniforprez 5y ago
I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial, it's a mess of wires and plugs that resembles something like Django anyways but all maintained by you or your team. FastAPI seemed like something that's in a solid middle ground between something beefy like Django but something light like Flask and it's much easier to start with since it gives you REST and form/JSON validation out of the box That said, FastAPI seems to have a lot of issues and the maintainer doesn't seem to be responding to the numerous PRs that are piling up. I'd much rather just stick with Django at this point
- nickjj 5y ago
  > I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial Do you have specific examples? I've built a number of decently large Flask apps over the years (dozens of blueprints, 100+ models, etc.) and it was never an issue. I've used similar code organizational patterns in both small and large apps and it worked great. It was a combination of solo projects and working with small teams.
  - WD-42 5y ago
    I share OP's general statement. I've been using Flask and Django on and off for near a decade. When deciding between Flask and Django, I look at the following requirements: User accounts Object Relational Manager Database Migrations User registration/social authentication Admin Site As a general rule of thumb if my project is going to need 3 or more of these things I just go with Django. You CAN do all of that with Flask, but you end up wiring together a bunch of third party dependencies just to end up with what Django would have provided you out of the box.
    - zippergz 5y ago
      FastAPI doesn't (directly) help with most of these either, so that's really a Flask vs. Django comparison rather than Flask vs. FastAPI.
  - 5y ago
fastball 5y ago
I used to really like Flask but after trying FastAPI I doubt I'd ever go back. I even rewrote the entire backend for our product in FastAPI and unlike some rewrites I've done in the past am 100% happy with this one. Major benefits for us: - Faster in general than Flask (thanks to starlette / uvicorn) - asyncio libs in Python are generally beating out others in terms of perf (e.g. asyncpg vs psycopg2). This isn't to start a whole "asyncio is faster" flamewar, not saying that's necessarily true. Just that it seems the people who are building in asyncio are also people who care about perf, which I do as well. The (non-asyncio) Python community has neglected perf for a bit too long imo. - asynchronous style works much better with things like WebSockets, which we use - Auto-generating an OpenAPI schema[1] is nice to have. - Using type hints for things simultaneously encourages mildly "safer" code while also giving better auto-complete suggestions [1] https://api.supernotes.app/docs/swagger https://api.supernotes.app/docs/swagger

clepto 5y ago

At least for my team we went with FastAPI because we have other tools for everything else, and FastAPI is incredibly simple for new members to pick up. We tend to say that we made a “FastAPI application” but in reality FastAPI is only powering the REST interface for interacting with the platform. We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together.

Nextgrid 5y ago
> We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together. Just wondering, why have you not gone with Django directly if you’ve essentially ended up reimplementing your own version of it?
- fernandotakai 5y ago
  that's how i feel about all these python "micro frameworks". you start simple, but then you realize you need some kind of db access, some kind of caching, some kind of authentication, maybe some admin interfaces.... aaand you re-implemented django yet again.
  - Nextgrid 5y ago
    Exactly the reason why I don’t care about either FastAPI or Flask. In my experience you’ll always need more than what it comes with out of the box and you’ll end up building your own (crappy) Django.
- clepto 5y ago
  There wasn’t really an aversion to or direct decision to not use Django, it just kind of naturally evolved. We were experimenting with FastAPI in some mock APIs used for test suites and some different projects and decided to incorporate it into a larger project. The pulling in of other tools happened naturally over time. Perhaps we reinvented the wheel and Django may have saved some time or effort, but ultimately in the end we gained a very deep knowledge of the system we have and the things that make it work, and how those individual pieces might be usable in other projects/scenarios. A large driver was honestly just that we had no organizational experience in Django, and so there was no one that even would have looked at it and said “Hey we’re just recreating what Django already does”.

aniforprez 5y ago

I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial, it's a mess of wires and plugs that resembles something like Django anyways but all maintained by you or your team. FastAPI seemed like something that's in a solid middle ground between something beefy like Django but something light like Flask and it's much easier to start with since it gives you REST and form/JSON validation out of the box That said, FastAPI seems to have a lot of issues and the maintainer doesn't seem to be responding to the numerous PRs that are piling up. I'd much rather just stick with Django at this point

nickjj 5y ago
> I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial Do you have specific examples? I've built a number of decently large Flask apps over the years (dozens of blueprints, 100+ models, etc.) and it was never an issue. I've used similar code organizational patterns in both small and large apps and it worked great. It was a combination of solo projects and working with small teams.
- WD-42 5y ago
  I share OP's general statement. I've been using Flask and Django on and off for near a decade. When deciding between Flask and Django, I look at the following requirements: User accounts Object Relational Manager Database Migrations User registration/social authentication Admin Site As a general rule of thumb if my project is going to need 3 or more of these things I just go with Django. You CAN do all of that with Flask, but you end up wiring together a bunch of third party dependencies just to end up with what Django would have provided you out of the box.
  - zippergz 5y ago
    FastAPI doesn't (directly) help with most of these either, so that's really a Flask vs. Django comparison rather than Flask vs. FastAPI.
- 5y ago

fastball 5y ago

I used to really like Flask but after trying FastAPI I doubt I'd ever go back. I even rewrote the entire backend for our product in FastAPI and unlike some rewrites I've done in the past am 100% happy with this one. Major benefits for us: - Faster in general than Flask (thanks to starlette / uvicorn) - asyncio libs in Python are generally beating out others in terms of perf (e.g. asyncpg vs psycopg2). This isn't to start a whole "asyncio is faster" flamewar, not saying that's necessarily true. Just that it seems the people who are building in asyncio are also people who care about perf, which I do as well. The (non-asyncio) Python community has neglected perf for a bit too long imo. - asynchronous style works much better with things like WebSockets, which we use - Auto-generating an OpenAPI schema[1] is nice to have. - Using type hints for things simultaneously encourages mildly "safer" code while also giving better auto-complete suggestions [1] https://api.supernotes.app/docs/swagger https://api.supernotes.app/docs/swagger