Are you building an API and a website? If yes, use Flask for the API and consume it from a Django site.
I wouldn't advocate using Django but ditching the ORM for SQLAlchemy, nor replacing the Auth, as noted (above or below my comment) it gets messy and becomes a lonely road fast.
I would advocate moving a lot (all?) of the model into a REST API, implemented in Flask, using SQLAlchemy. But perhaps my experience isn't as wide or deep as others.
I disagree on one point there... if you're building both an API and a website, there's no reason at all to use both Flask and Django. I can't imagine that the benefits would outweigh the disadvantages of having to deal with two frameworks instead of one.
I'd also argue in favour of ditching Django's auth. It's fine if your project has very simple auth requirements, but these days very few interesting projects have simple auth requirements - plus it's much easier to extend the functionality of your own Account models than to try and hook extra stuff on to Django's.
> I can't imagine that the benefits would outweigh the disadvantages of having to deal with two frameworks instead of one.
Separation of concerns, loose coupling.
I tended to find (in the few Django projects I worked on), that models were frequently accessed outside the app that created and owned the model. The subsequent dependency diagram would be spaghetti.
We had apps for each significant feature area, and when we wanted to drop a feature it was my desire to just remove an app.
It may well have been our implementation that was the problem (poorly separated concerns across apps), but we made great strides at solving these problems by using APIs to both force the de-coupling and to increase our confidence that our mobile clients (using the API) had the same capabilities available to them as the website (because no Django dev could cheat and make a call without the API existing).
Why Flask and not just Django again? That came down to personal preference over how clean it is to handle headers correctly (Accept headers, CORS and other things were fun), layout of the code and project, simplicity of testing, etc.
Mostly it was just subjective and personal preference, once we saw that the Django projects we had tended not to follow loose coupling, we used APIs as a way to increase our own discipline. Preferring that the architecture helped ensure the way we wanted to work on (and maintain) the code.
Auth we had already externalised (into the edge of the network, implemented within Varnish, similar to Flickr's GodAuth).
That's one of the fun issues with service oriented architecture.
You either choose high-chatter and low complexity, or low-chatter and high complexity. As high-chatter is also a decrease in performance (mostly due to JSON serialisation/deserialisation and HTTP requests), we opted for low-chatter.
Resources that were a composite of other resources had their own knowledge of how they were composed, and generated their own IDs to save that knowledge. Each new composition resource got it's own Accept header identifier as a result.
Within that composition resource, there wasn't just knowledge of "I'm composed of x:17 and y:3", but also knowledge of how to search across the underlying services. This could be to call search on the underlying service if one side of the composition was dominant in applying the filter to the dataset.
Where it was trivial, a search index belonging to the composed service was used. And because this duplicates data from the underlying resources, messaging was put into the underlying service to notify the composed service of changes that affect searches.
For simplicity you can just imagine that we had some kind of table in the composed service, with ID on each row that because the ID of the composed resource, and that we could search that table, and that messaging magic kept that table in sync.
We could do all of this because we owned all of the services. If we didn't, then I imagine we would have followed a similar path to http://ql.io/
Disagree, Django Rest Framework and TastyPie make REST APIs effortless: write Django models, register them with the REST plugin, hook the plugin to your main URL structure. They're a really good example of how Django enables reuse.
Implementation-wise they both hook into the model framework and the form framework, although you can swap out those parts if your data lives elsewhere.
There's flexibility. I've gotten a lot of mileage of closely-related models inlined into a parent model to form a single resource (resource relationships annotated with full=True with TastyPie), but one isn't limited to that either; http://django-tastypie.rtfd.org/ outlines the possibilities better than a short comment could.
The parent comment was only pointing out how incredibly fast and easy it is to get started with TastyPie. The moment you decide to create an API resource that isn't a one-to-one mapping with a database table or Model, TastyPie is still able to come with you every step of the way.
Sorry, but I wouldn't give up Django-TastyPie for anything else (including Flask) for API development. Sure, I could spend a month building an API framework from scratch in Flask for a project, but why would I?
Are you building an API? If yes, use Flask.
Are you building a website? If yes, use Django.
Are you building an API and a website? If yes, use Flask for the API and consume it from a Django site.
I wouldn't advocate using Django but ditching the ORM for SQLAlchemy, nor replacing the Auth, as noted (above or below my comment) it gets messy and becomes a lonely road fast.
I would advocate moving a lot (all?) of the model into a REST API, implemented in Flask, using SQLAlchemy. But perhaps my experience isn't as wide or deep as others.