5 ms·

Super useful tool, thanks to Tom and everybody who contributes. When we began moving some of our APIs from Django to Flask at my company, djangorestframework wa

Super useful tool, thanks to Tom and everybody who contributes. When we began moving some of our APIs from Django to Flask at my company, djangorestframework was the single tool/package that I missed most. It's lovely. What are the plans (if any) for continued development on Flask-API?

tomchristie 12y ago
At the moment it's on hold - I certainly won't be doing anything with Flask until the Kickstarter work is all complete. I'm undecided after that. 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.
- aidos 12y ago
  EDIT this conversation came up while I was writing this comment on another thread. Some of my questions have already been answered so I've reworded it. 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.
  - tomchristie 12y ago
    Well actually no, it'd be very feasible to re-write Django REST framework as a framework agnostic core. I've done a bit of exploratory work with this and there's nothing there that I think would be particularly fiddly. 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.
    - aidos 12y ago
      Interesting. Thanks for the info. Definitely understand not wanting to muddy the waters. Especially at this stage, the new Django version obviously has to be the focus. 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.
- chucksmash 12y ago
  I'm personally working with a lot of hand-rolled SQL/stored procedures but I know there are people within the organization using SQLAlchemy's schema reflection to work with the legacy tables. Being able to use something like Django Rest Framework to build an API on top of that would be nice indeed.
vosper 12y ago
I'm curious why you decided to move APIs from Django to Flask? We've built our APIs on Flask, and, though I like Flask a lot, the major complaint is that there's no real story around user authentication and authorization, endpoint versioning, and a handful of other things that aren't directly serving the purpose of the API, but are important nonetheless. 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.
- mcescalante 12y ago
  I am writing an API right now in Flask, and I chose it over Django never having used Django for a REST service before. 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.
  - tallerholler 12y ago
    strict in what way? I've built many api's using django-rest-framework and it is truly awesome to work with, completely extensible and flexible and never seems to get in my way
    - mcescalante 12y ago
      I just meant that they offer more of a base + guidelines for you to work with when compared to Flask's "roll it yourself" approach to REST.
- chucksmash 12y ago
  We're not building from scratch. The constraints imposed by the pre-existing stuff mean we can't really take full advantage of the upsides of Django.
brento 12y ago
I'm curious why the choice was made to switch to Flask?
- chucksmash 12y ago
  We use both. I came in with a preference for Django but the applications we build are generally talking to legacy data stores so we more or less lose the Django ORM right off the bat. That cancels out a lot of the advantages Django has, unfortunately.
  - jsmeaton 12y ago
    We use Django for legacy databases, both as a readonly way to access data in a managed data warehouse and to replace an application that had not the nicest schema to begin with. Routers to the rescue. Of course if the database you're working with is a shambles, then you're going to have a bad time.
  - johnthedebs 12y ago
    In case you didn't know, you can have Django auto-generate models from existing databases. I've used it a couple times and it worked very well. Relevant docs: https://docs.djangoproject.com/en/1.7/howto/legacy-databases/#auto-generate-the-models https://docs.djangoproject.com/en/1.7/howto/legacy-databases...

tomchristie 12y ago

At the moment it's on hold - I certainly won't be doing anything with Flask until the Kickstarter work is all complete. I'm undecided after that. 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.

aidos 12y ago
EDIT this conversation came up while I was writing this comment on another thread. Some of my questions have already been answered so I've reworded it. 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.
- tomchristie 12y ago
  Well actually no, it'd be very feasible to re-write Django REST framework as a framework agnostic core. I've done a bit of exploratory work with this and there's nothing there that I think would be particularly fiddly. 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.
  - aidos 12y ago
    Interesting. Thanks for the info. Definitely understand not wanting to muddy the waters. Especially at this stage, the new Django version obviously has to be the focus. 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.
chucksmash 12y ago
I'm personally working with a lot of hand-rolled SQL/stored procedures but I know there are people within the organization using SQLAlchemy's schema reflection to work with the legacy tables. Being able to use something like Django Rest Framework to build an API on top of that would be nice indeed.

vosper 12y ago

I'm curious why you decided to move APIs from Django to Flask? We've built our APIs on Flask, and, though I like Flask a lot, the major complaint is that there's no real story around user authentication and authorization, endpoint versioning, and a handful of other things that aren't directly serving the purpose of the API, but are important nonetheless. 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.

mcescalante 12y ago
I am writing an API right now in Flask, and I chose it over Django never having used Django for a REST service before. 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.
- tallerholler 12y ago
  strict in what way? I've built many api's using django-rest-framework and it is truly awesome to work with, completely extensible and flexible and never seems to get in my way
  - mcescalante 12y ago
    I just meant that they offer more of a base + guidelines for you to work with when compared to Flask's "roll it yourself" approach to REST.
chucksmash 12y ago
We're not building from scratch. The constraints imposed by the pre-existing stuff mean we can't really take full advantage of the upsides of Django.

brento 12y ago

I'm curious why the choice was made to switch to Flask?

chucksmash 12y ago
We use both. I came in with a preference for Django but the applications we build are generally talking to legacy data stores so we more or less lose the Django ORM right off the bat. That cancels out a lot of the advantages Django has, unfortunately.
- jsmeaton 12y ago
  We use Django for legacy databases, both as a readonly way to access data in a managed data warehouse and to replace an application that had not the nicest schema to begin with. Routers to the rescue. Of course if the database you're working with is a shambles, then you're going to have a bad time.
- johnthedebs 12y ago
  In case you didn't know, you can have Django auto-generate models from existing databases. I've used it a couple times and it worked very well. Relevant docs: https://docs.djangoproject.com/en/1.7/howto/legacy-databases/#auto-generate-the-models https://docs.djangoproject.com/en/1.7/howto/legacy-databases...