Hacker News Reader

Comment by yen223 | Hacker News Reader

In my experience, Django is less suitable for large projects than Flask.

The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer.

This is manageable in the small, but when you hit scale, this tight coupling adds a whole bunch of unnecessary complexity to your system. Good luck trying to tune your database when any template can trigger hundreds of db calls!

View on HN

Django is great for building Django apps. That is, if you're starting a greenfield project and don't have to integration with an existing database schema, and you like the Django ORM, and you like Django templates, and your data model maps cleanly onto a relational DB, and you can use the admin site more or less as-is without having to customize much, then it's lovely! I'm not being sarcastic: it really is. We've successfully rolled out several CRUD apps so that our internal employees can tweak settings and update stuff without waiting for engineering to get around to it.

That said, I'd rather gnaw off my own ankle than develop a production, customer-facing website that breaks any of the preconditions I listed above. Every time I've needed to deviate from the Django Way of doing things, it's felt like I'm swimming upstream against a rapids. For those kinds of projects, I love Flask very, very much.

You don't need Django's ORM, templates, and admin section to build a Django app. Check out this example of a single-file Django project:

https://www.safaribooksonline.com/library/view/lightweight-d...

It's from a good book called Lightweight Django.

But if you’re not using those things, why Django?

You can use what you need and replace the rest. Or use Flask or something else. I'm not arguing for one or the other, but just mentioning that you don't need all of those mentioned conditions for Django.

> Every time I've needed to deviate from the Django Way of doing things, it's felt like I'm swimming upstream against a rapids.

I agree -- if you use Django, you have to do it the Django way. Flask is more flexible.

This is a false statement that Django is unsuitable for large projects. I have been working on a fairly large Django Project for 5 years now and it has been a pleasure using Django to build good and stable features that actually scale.

> The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer.

It totally depends how your architect your application and how you write code.

Any framework you choose, you need to write good code, keep an eye on db operations, enable caching where it is required and you will survive the scale just fine. All the arguments are exactly same in the favor of slack.

Do not spread the FUD that using a framework can magically make your application scale. I have seen very bad and very good code in both Django and flask. If you want your application to scale, you need to carefully work on it there is no silver bullet.

If you want something similar to Flask component wise that scales well and allows for nice structuring patterns try Pyramid (https://trypyramid.com/). It it is really well thought out framework, you can use it to build single file applications if you want but it really shines when you use Pyramids mechanisms that allow for extending applications and their composition.

That being said when you are careful you can probably end up with reasonably structured applications in either Django, Pyramid or Flask.

Newly released version of PyPi is built in Pyramid.

I was about to post something similar, but this nicely summarizes my feelings. Even with DRF (for REST APIs) the extreme coupling at all layers makes things painful, though it's possible to reduce that pain a little with some carefully enforced rules.

(I would like to see a way of disabling QuerySet traversing, so that if you try to access something that you didn't already prefetch_related/select_related then you just hit an error (and therefore fix it before you go live). The behaviour of just happily issuing hundreds of DB queries in a single request really hides a bunch of architectural and performance issues.)

That said, as the sibling comment says, if you need a simple- to moderate-complexity, mostly CRUD API, and particularly if you need it fast, then Django is a great tool.

Your should look into the django-seal package which enforces this sort of constraint that you're asking for

Yes, yes I should. Many thanks!

Might want to tell instagram

https://m.youtube.com/watch?v=lx5WQjXLlq8

Instagram is using jinja for templates (also used by Flask) and does not use the Django ORM.

I mean Facebook uses PHP and that doesn't mean it's any more scalable.

I suppose they call it hack now though.

>template can trigger hundreds of db calls

I'll take what is caching for 500, Alex

Reply on news.ycombinator.com