[dragonsh]

I started working with Django when it was pre 1.0 (0.96), as it was explicit in nature compared to Ruby on rails in 2003-4. Subsequently I tried flask and recently async framework. Our team still use flask just for one reason, it's a thin layer over wsgi making it easier and once application or service grows it can disappear completely.

So it has right level of abstraction making it between a library and framework and you can use it either as library or framework. The difference is "framwwork calls your code" and "your code calls library code". I like the second paradigm more.

In order to make job very easy to develop there are excellent libraries so I have used flask, sqlalchemy (direct no flasl-sqlalchemy), alembic, marshmallow, celery, machine learning libraries (sci-kit, tensorflow, keras) and few more.

For development use cherrypy to graft wsgi app and for production use gunicorn or uwsgi. Our team is extremely happy and our test coverage is 98% as we use code as libraries not asnframework, so it makes it easy to test rest API and celery task code.

Also when needed for performance (not often as most libraries are better tested and designed), did take away the library abstraction and write our own code.

[odonnellryan]

I traditionally like using the libraries not the Flask integrations (as in your sqlalchemy example) however I do find myself using Flask Admin and Flask-WTForms, since while they do have downsides and you have to commit to using them, they do a lot for you.

I haven't checked out CherryPy, I should next hobby project.

Gunicorn is awesome, uWSGI is also good and feels more "production" to me.

[dragonsh]

My problem with those additional projects are that I am dependent on one another layer of abstraction and not sure if the team is able to continue to develop it if core developers abandon it. Thats the reason I prefer using libraries, which if not supported can be supported by my team or replaced if necessary.

We use Flask mostly for REST API, so flask-admin and WTForms do not add that much value as all those are done on client side SPA (I do not like SPA, but it makes job easier as same API is leveraged for integration and mobile app).

[odonnellryan]

For my apps I'm not worried about abandonment. They are internal applications generally with no access from the web.

Also the code is solid enough where I feel I could maintain it if I needed to, but most likely it would get picked up by someone else.