Class-based views, in their most basic form, are a lot easier to read. E.g. look at the DRF CBVs I have here:
https://github.com/Alex3917/django_for_startups/blob/main/dj...
If you can avoid Generic CBVs (things like ListView) and inheritance, then the only difference between FBVs and CBVs is that CBVs make it easier to see what's a GET / PUT / POST / DELETE by adding some syntax highlighting that makes it easier to visually differentiate which code goes to which method. You don't need to know anything about classes in Python in order to use them.
It's not at all difficult to switch from FBVs to CBVs later, and most people (myself included) use FBVs when getting started. But I'd also say that if you're willing to push through the initial discomfort and spend the extra half hour or whatever on YouTube in order to understand them, then you do get a little bit of a nicer overall development experience.
That way my actual view logic doesn't have to deal with anything http, and it makes testing them way simpler.
I had not heard the term "fat models" before so I googled it. It did not go in the direction I expected.
:-/
(These days, the library does rank first for "python fabric").
Combined with the Repository pattern from DDD, you can have all your model fetches go through a separate class that does the necessary select-/prefetch-related calls, then seals. (Or just override your model's Manager to do this).
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…
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.
Problem is when you start abusing stuff. Just hook into some signal to do something, nbd, but suddenly it's an interconnected mess. Just add some custom stuff to the admin page, and suddenly what should have been a custom made page is now a weird mess it's hard to extend. Need to do stuff async in the background, and what could have been adding a task on some queue and having a thread poll it is instead this behemoth of complexity.
A large django app can also be good, I think, but then one at some part have to realize when to stop tweaking built in django features and write custom stuff, to avoid adding hacks on top of hacks. And also early stop doing the easy communication between apps, instead take the annoying detour around services and hard boundaries.
And hard to do the organization propably in django, doing it breaks much of the benefits of the orm for instance. People will do what's convenient, and in Django that's writing unmaintainable code.
I'm not saying that you need micro services, but you should find a way to split this up into a few applications with well defined interfaces between the applications.
This is what I always found in Django projects with the notable exception of the one that had only one giant app.
I started to believe that one project doesn't get along with multiple apps (kind of microservices) in the mind of the average developer. Only one app Rails style is probably easier to grasp and manage.
What managed databases do you recommend that adequately meet price/performance needs of indie developers?
- WAF rules
- EC2 instance
- RDS
- Cloudfront
I use fargate when deploying now to get out of box management
Here is a fresh example: they deprecated CELERY_ prefixes in Django settings for some reason, which makes zero sense [1]. But because it's Celery, they only warn on a few properties but not others, and the tool they ship inexplicably renamed completely unrelated settings for me [2]. And yes, apparently the new way doesn't work either [3].
It's very characteristic of what I've seen from Celery over the last few years of working with it. If you are doing anything greenfield, it's best to avoid it altogether.
[1] https://stackoverflow.com/questions/65554242/celery-imports-...
[2] https://twitter.com/lambdadmitry/status/1468337594358546435?...
Covid screening application (sold)
Inventory management (initial clients in alcohol beverage bottling/distribution)
As far as inventory management - I looked at several opensource projects and tried to understand their schema and use cases. Not just Django ones but other languages like PHP - PartKeepr for example.
Inventory management is surprisingly complicated to do in a generic way.
Also, and it's hard to believe, but Spring has substantially more magic than Django.
My advice - keep it simple
- function based views
- centralize access to the ORM (avoid fat models, use a service layer)
- responsive bootstrap template with crispy forms
- minimal js
- 12 factor type setup - django-environ or similar
- be aware of n+1 select problem (I use django debug toolbar but looking into django-zen-queries)
- plop it on heroku, AWS lightsail, Digital Ocean or if containerizing use AWS Fargate
- avoid celery unless you are at a scale you need it - use django-cron, django-db-queue or similar
- use a managed database and managed email service
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)