3 ms·
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 inter
by 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 agoEDIT 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 agoWell 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 agoInteresting. 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 agoI'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.