4 ms·

What problems do you run into with Flask (presumably + SQLAlchemy)? IME, this stack has been pretty simple both at-scale and at-home. At scale, my experience i

by gen220 5y ago

What problems do you run into with Flask (presumably + SQLAlchemy)? IME, this stack has been pretty simple both at-scale and at-home. At scale, my experience is mostly using it in REST APIs serving a react frontend. At-home, I've used it to setup numerous graphql services (with the graphene plugin). Admittedly, there's probably 100 different ways to configure anything wrong, especially for any framework written in Python. But once you witness a "golden path", and stick to it, it's pretty straightforward. (The Flask docs have improved a lot in this regard, in the last few years)

saila 5y ago
I’m working on multiple Flask apps currently and I have a lot to say about it, but regarding docs, the main Flask docs might be fine, but the docs for some of the extensions we use are quite bad. Also, there’s nothing about these apps that requires the alleged flexibility of Flask, so there’s a lot of issues with dependencies and integrating extensions. That’s a lot of extra work and probably weakens security for no benefit at all. Upgrading a big Django app is much simpler IME.
- gen220 5y ago
  I think part of the reason the Flask extension ecosystem is so weak, is that most problems solved by an extension have solutions that are relatively small / cheap to build in-house. These things are difficult both to depend upon externally and to maintain, due to the dependency/upgrade issue you mentioned. For an example in a similar ecosystem: at a previous company, at one time we used SQLalchemy-continuum for audit tables. We found some bugs and were not able to upstream them. When we wanted to upgrade SLQLAlchemy to X.Y, we were stuck with this dependency that required SQLAlchemy X.Y-1. After a few years, we realized it was cheaper to cook up a SQLAlchemy-Continuum subset that met our needs, so it'd be easier to keep in line with SQLAlchemy. It's a very different mindset from Django; I think there's an appropriate context for each.
digisign 5y ago
May have changed, but when I tried it, the first day with Flask was incredible. The second day, when you're ready to implement log-in and password pages, maybe email reset... you are on your own. There's six and a half third-party extension options with different overlapping scopes to research, the author of the best one has taken off for the Bahamas for two years…
- gen220 5y ago
  Ah yeah, fair enough. The places I worked at-scale had their own o-auth setups (built mostly with FOSS) wired up to flask with some relatively small libraries [1]. I personally wouldn't want my web framework to implement login/password/email-reset for me, although I understand Django offers it to varying degrees. It's a space where "best practice" has evolved dramatically in the past decade. [1]: https://flask-oidc.readthedocs.io/en/latest/ https://flask-oidc.readthedocs.io/en/latest/ they looked a lot like this, fwiw. Although to your point, this too, hasn't been updated in 5 years. :)
  - digisign 5y ago
    As practice evolves, Django gives you a migration guide. That's great because the alternative could take a potentially unbounded amount of time. And you still could go it alone if sufficiently motivated. Although it could get annoying, as mentioned. The main point though is that I'm not interested in being on the forefront of login, it is not a differentiator (unless project is a laggard). In fact being five years behind bleeding-edge sounds a bit perfect.

by gen220 5y ago

saila 5y ago

I’m working on multiple Flask apps currently and I have a lot to say about it, but regarding docs, the main Flask docs might be fine, but the docs for some of the extensions we use are quite bad. Also, there’s nothing about these apps that requires the alleged flexibility of Flask, so there’s a lot of issues with dependencies and integrating extensions. That’s a lot of extra work and probably weakens security for no benefit at all. Upgrading a big Django app is much simpler IME.

gen220 5y ago
I think part of the reason the Flask extension ecosystem is so weak, is that most problems solved by an extension have solutions that are relatively small / cheap to build in-house. These things are difficult both to depend upon externally and to maintain, due to the dependency/upgrade issue you mentioned. For an example in a similar ecosystem: at a previous company, at one time we used SQLalchemy-continuum for audit tables. We found some bugs and were not able to upstream them. When we wanted to upgrade SLQLAlchemy to X.Y, we were stuck with this dependency that required SQLAlchemy X.Y-1. After a few years, we realized it was cheaper to cook up a SQLAlchemy-Continuum subset that met our needs, so it'd be easier to keep in line with SQLAlchemy. It's a very different mindset from Django; I think there's an appropriate context for each.

digisign 5y ago

May have changed, but when I tried it, the first day with Flask was incredible. The second day, when you're ready to implement log-in and password pages, maybe email reset... you are on your own. There's six and a half third-party extension options with different overlapping scopes to research, the author of the best one has taken off for the Bahamas for two years…

gen220 5y ago
Ah yeah, fair enough. The places I worked at-scale had their own o-auth setups (built mostly with FOSS) wired up to flask with some relatively small libraries [1]. I personally wouldn't want my web framework to implement login/password/email-reset for me, although I understand Django offers it to varying degrees. It's a space where "best practice" has evolved dramatically in the past decade. [1]: https://flask-oidc.readthedocs.io/en/latest/ https://flask-oidc.readthedocs.io/en/latest/ they looked a lot like this, fwiw. Although to your point, this too, hasn't been updated in 5 years. :)
- digisign 5y ago
  As practice evolves, Django gives you a migration guide. That's great because the alternative could take a potentially unbounded amount of time. And you still could go it alone if sufficiently motivated. Although it could get annoying, as mentioned. The main point though is that I'm not interested in being on the forefront of login, it is not a differentiator (unless project is a laggard). In fact being five years behind bleeding-edge sounds a bit perfect.