You mentioned having a strong designer early in the project; did you have a specific name in mind? I'd love to see what they're up to and study some of their other projects.
How does anybody keep up with this stuff, let alone create it all? :p
I am trying to avoid the nextjs/react/ etc stuff where I spend half my time on tooling issues. JS itself is nightmarish (people complain about python dependencies but I haven’t yet seen a big issue yet) but node JS weird module errors and myriad places things are configured and that you usually have build steps etc. Makes me want to get away from that.
You don’t need to “keep up”. You don’t need to know all 100 ways to make a sausage. Just make sausages. Occasionally tweak the machine.
every time i start a project with something other than django, i end up with django, but "homebrewed".
example: you start with flask. you need auth, so you add flask-login.
you need some database access, so you add SQLAlchemy (and its flask plugin). you also need some kind of admin page, so you add flask-admin.
when you are finished, you have a flask-django framework, but not as well integrated -- with django, you get ALL of those all of those out-of-the-box, everything is well oiled and well integrated.
so, yeah, imho django is an amazing backend framework that does its job perfectly, specially when you add some really good libraries (like django-rest-framework).
Make 1 app called core or common of whatever and replace models.py with models/<namespace_or_domain>.py and import those into models/__init__.py
Everyone jumps into apps with foreign keys across app boundaries and it makes a mess of things from the start that doesnt buy you anything.
1 app. 1 set of migrations. Turn models, views, etc into a package instead of the single file module.
Its the one thing I wish the docs would prescribe and demonstrate for new project advice. .
Another similar suggestion I’d add is make a settings module with a base collection of configuration (i.e. myproject/settings/common.py) that other deployment-specific dev.py & prod.py import from.
Basically, don’t forget that Django projects are always Python modules too, so go ahead and use those language features too.
There's also a long, uh, spirited discussion about it here with some decent arguments going both directions: https://forum.djangoproject.com/t/why-do-we-need-apps/827/19
In 15 years I haven't seen a single case when splitting a project into multiple apps brought anything but pain.
Also, splitting files like models into packages is also a great approach. 6 months ago I found myself with models.py, API.py (my alternative for API views vs regular views) and serializes.py each over 3k lines of code. Spent 3 days splitting them into small files by topic. Way easier to work.
I also wish docs suggested that it is an option and better to split them earlier. Because it is so easy to just "add one more model to the end of the file, what can go wrong?"
You understand what goes wrong after 2-3k LoC
Do not call it core. There's an existing app or module or something with that name and this will introduce hard-to-diagnose bugs. Common is preferable.
so far nothing bit me other than an awkward 'app' in my installed_apps, fingers crossed