<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>theptip</author><text>Strongly agreed on these pain points. One tool I have been using recently to help is django-seal, which locks the QuerySet so you can’t run extra queries. This should really be part of the ORM, fail-unsafe is a bad option for performance critical code.&lt;p&gt;Combined with the Repository pattern from DDD, you can have all your model fetches go through a separate class that does the necessary select-&amp;#x2F;prefetch-related calls, then seals. (Or just override your model&amp;#x27;s Manager to do this).&lt;p&gt;And we have a coding standard guideline to discourage using queryset operators in business logic, as you note it breaks encapsulation and makes your code really hard to refactor later. This is hard to enforce though…&lt;p&gt;I think Django’s ORM is if anything too convenient - it’s great for the first 100kloc but then as you say, you need to overlay some discipline to prevent things from blowing up, and the framework is all about removing friction which makes this hard.</text><parent_chain><item><author>matsemann</author><text>It&amp;#x27;s great for getting things up and running. And can last a long time. But now that we&amp;#x27;re 40 devs or so working in the same 400k LOC codebase, I&amp;#x27;d prefer Java&amp;#x2F;Spring (or really, Kotlin). So hard to maintain django in the long run, need to be really strict, or one ends up with each app spaghettied with other apps. Doing queries where you filter deep on other apps&amp;#x27; models, and since it&amp;#x27;s only done as kwargs with no typing nothing stops that from exploding runtime when someone changes a model somewhere. Too easy to send fat objects around everywhere, accidentally doing heavy db stuff when using a property. Also makes it harder to test, because everything leaks.</text></item><item><author>rlawson</author><text>Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java&amp;#x2F;Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory.&lt;p&gt;My advice - keep it simple&lt;p&gt;- function based views&lt;p&gt;- centralize access to the ORM (avoid fat models, use a service layer)&lt;p&gt;- responsive bootstrap template with crispy forms&lt;p&gt;- minimal js&lt;p&gt;- 12 factor type setup - django-environ or similar&lt;p&gt;- be aware of n+1 select problem (I use django debug toolbar but looking into django-zen-queries)&lt;p&gt;- plop it on heroku, AWS lightsail, Digital Ocean or if containerizing use AWS Fargate&lt;p&gt;- avoid celery unless you are at a scale you need it - use django-cron, django-db-queue or similar&lt;p&gt;- use a managed database and managed email service&lt;p&gt;I have had zero scalability problems. People say Django is slow but it handled 10k active users on a small EC2 instance without any issues (static stuff served via cloudfront)</text></item></parent_chain></comment><story><title>Django 4.0</title><url>https://www.djangoproject.com/weblog/2021/dec/07/django-40-released/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>stavros</author><text>Yes, but nothing is stopping you from typing and organizing everything, right? I agree that it&amp;#x27;s not the default, which isn&amp;#x27;t ideal, but you can do it fairly easily (and keep it enforced).</text><parent_chain><item><author>matsemann</author><text>It&amp;#x27;s great for getting things up and running. And can last a long time. But now that we&amp;#x27;re 40 devs or so working in the same 400k LOC codebase, I&amp;#x27;d prefer Java&amp;#x2F;Spring (or really, Kotlin). So hard to maintain django in the long run, need to be really strict, or one ends up with each app spaghettied with other apps. Doing queries where you filter deep on other apps&amp;#x27; models, and since it&amp;#x27;s only done as kwargs with no typing nothing stops that from exploding runtime when someone changes a model somewhere. Too easy to send fat objects around everywhere, accidentally doing heavy db stuff when using a property. Also makes it harder to test, because everything leaks.</text></item><item><author>rlawson</author><text>Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java&amp;#x2F;Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory.&lt;p&gt;My advice - keep it simple&lt;p&gt;- function based views&lt;p&gt;- centralize access to the ORM (avoid fat models, use a service layer)&lt;p&gt;- responsive bootstrap template with crispy forms&lt;p&gt;- minimal js&lt;p&gt;- 12 factor type setup - django-environ or similar&lt;p&gt;- be aware of n+1 select problem (I use django debug toolbar but looking into django-zen-queries)&lt;p&gt;- plop it on heroku, AWS lightsail, Digital Ocean or if containerizing use AWS Fargate&lt;p&gt;- avoid celery unless you are at a scale you need it - use django-cron, django-db-queue or similar&lt;p&gt;- use a managed database and managed email service&lt;p&gt;I have had zero scalability problems. People say Django is slow but it handled 10k active users on a small EC2 instance without any issues (static stuff served via cloudfront)</text></item></parent_chain></comment><story><title>Django 4.0</title><url>https://www.djangoproject.com/weblog/2021/dec/07/django-40-released/</url></story>