What are the plans (if any) for continued development on Flask-API?
There are a hodge-podge of plugins to do various things, but they don't necessarily share the same design principles or work well together. Some are so abstracted that by the time you've got a concrete implementation you could have just rolled your own.
EDIT: Grammar, added a sentence.
When you say "there's no story" around auth, endpoint versioning, and other things does that just mean that you're not forced to follow those conventions with Flask / that Django offers utilities to help? I am a bit confused/curious what you meant by that since I've seen some wonderful Flask auth work, and endpoint versioning is pretty standard on most APIs, but seems like Django is a bit more strict with what they want you to do.
It'd be interesting to get your opinion on what your take would be on using Django/Django REST framework if it had decent built-in support for use with SQLAlchemy.
Said it before, and I'll say it again - DRF is one of the few things that makes me wish I was on Django.
Is the newer DRF code abstracted nicely to make a port to Flask easier?
It's something I actually looked at doing myself a year ago but there looked to be a lot of effort involved.
I often look at projects that are Django-this or Flask-that and think to myself - this could be a nice clean agnostic library with layers for which ever framework. Often by that stage it's too late, everything is too embedded.
In this case, I guess that DRF intrinsically deals with the framework specific layers a lot so it's probably necessarily tightly bound.
The main questions would be how we'd manage support, packaging, documentation etc. Also is the benefit worth it if it means an extra level of indirection for our existing user-base? Right now focusing on Django REST framework in it's current form feels like the best effort-reward, but there's no fundamental architectural reasons stopping us from moving to a more decoupled core, with a Django specific integration layer on top of that.
That said, if the core was sufficiently decoupled that you could split it out, that would be a major win for the Flask guys. pip install djangorestframework could work just as it does (by installing drf_core). The Flask community could then create flaskrestframework which also installs the core and uses that. I guess the djangorestframework project could even contain everything, so long as the core module didn't depend on django.
Then the Flask guys could maintain a wrapper and some lightweight Flask specific documentation with references back to the main docs.
As I say, it would be silly to do it now, but if it turned out to be easy to do in the long run, it wouldn't have to impact on the work you're doing too much.
As ever, even though I'm not even using the project, thanks for the work. I spent a long time reading through your code a couple of years back. It was really enlightening and I learnt a lot. Thanks again.
Of course if the database you're working with is a shambles, then you're going to have a bad time.
Relevant docs: https://docs.djangoproject.com/en/1.7/howto/legacy-databases...