7 ms·

My personal experience with Flask has led me to believe it's many times easier to expand on vanilla Flask then it is to try and incorporate any of the flask-* l

My personal experience with Flask has led me to believe it's many times easier to expand on vanilla Flask then it is to try and incorporate any of the flask-* libraries.

dfox 9y ago
I ended up with writing my own flask extension that integrates some useful flask-* libraries and client-side JS libraries in very opinionated way. Somewhat ironically I'm currently in process of spliting that into separate flask extensions...
peller 9y ago
Having just built a boilerplate that integrates a bunch of the flask-* libraries, I think the key really is that you need to be careful about how you organize your code: it's important to be able to control the order of registering the various extensions you're using relative to when you're registering your app code. Otherwise you're going to end up in circular-dependency import hell. Buried in the documentation is a hint on how to do this correctly with application factories[0], but if you don't know that's there, it's very hard to just stumble upon how to correctly organize everything. [0] http://flask.pocoo.org/docs/0.12/patterns/appfactories/ http://flask.pocoo.org/docs/0.12/patterns/appfactories/
larrykwg 9y ago
Flask never really seemed like a very mature framework to me, it got so many strange inconsistencies and very dubious design choices I much prefer newer, significantly simpler frameworks. One example is the way the request context works in flask, I venture to say thats just terrible software design in my book (from flask import request, g). And seriously to have your framework give you a "global" variable to put random stuff in, wth? Also I rather not use Flask-SQLAlchemy since why should my database models be tied so incredibly closely to some library of my web MICRO framework, it doesn't make sense, I mean its not django why introduce this coupling? It seems if you need all the dependent libraries (like webassets and wtforms) just use django from the get go instead of going through the pain of trying to cleanly integrate dozens of flask libraries. To see how a proper simple middleware-based framework should look like consider express, koa (nodejs), or bottle, falcon. Aiohttp and tornado also have their place of course.
wruza 9y ago
My personal experience with http is that you parse url and cookies by hand and never bother to use any crap “framework”. Of course, it has to be reverse-proxied with all irrelevant headers cleared, e.g. via nginx, which can also serve /static efficiently and provide https-http conversion. If you’re familiar with Lua, then writing http to json-only or binary-only unix socket is a no brainer in OpenResty, so you can skip backend-side parsing at all. Flask/etc was useful magic only until I figured out what it really does between me and underlying socket.

My personal experience with Flask has led me to believe it's many times easier to expand on vanilla Flask then it is to try and incorporate any of the flask-* libraries.

dfox 9y ago

I ended up with writing my own flask extension that integrates some useful flask-* libraries and client-side JS libraries in very opinionated way. Somewhat ironically I'm currently in process of spliting that into separate flask extensions...

peller 9y ago

Having just built a boilerplate that integrates a bunch of the flask-* libraries, I think the key really is that you need to be careful about how you organize your code: it's important to be able to control the order of registering the various extensions you're using relative to when you're registering your app code. Otherwise you're going to end up in circular-dependency import hell. Buried in the documentation is a hint on how to do this correctly with application factories[0], but if you don't know that's there, it's very hard to just stumble upon how to correctly organize everything. [0] http://flask.pocoo.org/docs/0.12/patterns/appfactories/ http://flask.pocoo.org/docs/0.12/patterns/appfactories/

larrykwg 9y ago

Flask never really seemed like a very mature framework to me, it got so many strange inconsistencies and very dubious design choices I much prefer newer, significantly simpler frameworks. One example is the way the request context works in flask, I venture to say thats just terrible software design in my book (from flask import request, g). And seriously to have your framework give you a "global" variable to put random stuff in, wth? Also I rather not use Flask-SQLAlchemy since why should my database models be tied so incredibly closely to some library of my web MICRO framework, it doesn't make sense, I mean its not django why introduce this coupling? It seems if you need all the dependent libraries (like webassets and wtforms) just use django from the get go instead of going through the pain of trying to cleanly integrate dozens of flask libraries. To see how a proper simple middleware-based framework should look like consider express, koa (nodejs), or bottle, falcon. Aiohttp and tornado also have their place of course.

wruza 9y ago

My personal experience with http is that you parse url and cookies by hand and never bother to use any crap “framework”. Of course, it has to be reverse-proxied with all irrelevant headers cleared, e.g. via nginx, which can also serve /static efficiently and provide https-http conversion. If you’re familiar with Lua, then writing http to json-only or binary-only unix socket is a no brainer in OpenResty, so you can skip backend-side parsing at all. Flask/etc was useful magic only until I figured out what it really does between me and underlying socket.