Comment by danpalmer | Hacker News Reader

Comment by danpalmer | Hacker News Reader

Parent Full thread

I've always felt, and this hasn't changed recently, that if you're going to need more than, say, 3 of the cross cutting concerns that Django provides for, then it'll be much more maintainable in the long run to just use Django rather than effectively building a custom solution out of parts. The flip side: if you're building a small internal API that only needs a couple of these, Django might be overkill.

What do I mean by "cross cutting concerns"? I'm thinking about ORM/models, migrations, admin UI, caching, sessions, misc security middleware, user accounts, validation/forms, templating, RSS feeds, logging, testing infrastructure, etc. Django's pieces all fit together well, and any time I've done this with Flask/etc I've found myself spending so much time solving issues gluing these bits together and working around impedance mismatches between libraries.

We had a large Django site at my last place and would just suggest new starters worked through the Django tutorial, because our site basically still worked like that.

I half-agree with you, I've found that there are two options when choosing a framework:

1. You're making something with 100 lines, which you're absolutely sure will stay 100 lines. Go with Flask.

2. Otherwise, Django.

Django is great at getting out of your way when you don't need its functionality, so you can just ignore most of it if you don't need it.

Second this, if you need a database and users, Django is better than the headache of thinking about this yourself with all security pitfalls. I've built several production APIs around Django (like, not CMS at all) and I find it a good compromise between an SDK and rolling your own, this is partly due to Python as well of course.

And I've done smaller things with Flask where it would make no sense to go with Django as well but those were things not really built around a db or CRUD API etc.

I agree. I would even go so far as to say that if you need an ORM, go with Django. I've wasted too much time adding SQLAlchemy to Flask to get something that is still worse than the Django ORM.

Perhaps, but it depends what you're building. SQLAlchemy is much more capable, so if you need great database control and don't need all the other bits Django is bringing, then I kinda get it.

+1 to that. Maybe SQLAlchemy is a better product, but being a bolted on solution makes everything about the ORM experience feel worse than using Django. If nothing else, it is not just using Flask+SQLAlchemy, now it is Flask+SQLAlchemy+Alembic. Or maybe, you want the niceties, so it is Flask+SQLAlchemy+Alembic+FlaskMigrate.

Exactly. It's the migration support that I find the best feature of Django, but I keep forgetting about it until I have to migrate with some other ORM.

They way I'd look at it - if your app owns the database and schema, use Django. If your app is connecting into someone else's database or databases (like in enterprises with DBA priesthoods etc), the flexibility of SQLAlchemy can fit better around arbitrary schemas etc.

Reply on news.ycombinator.com