I still have a project that runs on Django 1.6. Can't imagine trying to migrate now, when it relies on so many old packages. Would probably be better of starting from scratch.
Django 4.0
71–80 of 226 posts
Re: Django 4.0
#72Earlier quoted context omitted.
As someone who's used both - Rails packaging and environment maintenance has been so much less of a headache. Gems and Gemfiles and Gemfile.lock vs having to choose a Python package maintainer (Pipenv vs Poetry?) and deal with that has been worth it to me. In terms of how they "feel" to develop with? About the same. Similar ideals - skinny models, service layers, REST-first but you can make it RPC-style if you want..…
A couple of comments here have talked about the benefits of “skinny models”, but that runs counter to the advice I’ve seen. How come skinny models? Is the idea to put most of the business logic… where?
I'm unconvinced by the "skinny models" and "service layer" arguments. Django's ORM is an active record style ORM, its at its best if you use it that way. If you want to have a service layer type architecture, use SqlAlchemy with implements the data mapper scheme.
I follow this general rule of thumb, in order:
If it's a complicated business logic touching multiple models or external apis, put in in a `utils` module (keeping this sensibly organised by model/role/activity depending on what you are building, i.e. utils.{model_name}.{methods} or utils.{e.g. order_processing/email/accounts}.{methods}). You can add a shortcut to it as a method on the model if this makes sence. (some may argue this is a service layer)
If I'm only doing something once in one place (in one view), then keep the logic there.
If it's a custom create method, stick it on the models manager class.
If it's something you want to do to a set of objects (from a query set), put it on the manager class or a QuerySet subclass (to make it chain-able).
If you haven't put it elsewhere put it on the model class, as a method or a property if it seems cleaner (don't do get_... and set_... use a property)
Re: Django 4.0
#73Earlier quoted context omitted.
As someone who's used both - Rails packaging and environment maintenance has been so much less of a headache. Gems and Gemfiles and Gemfile.lock vs having to choose a Python package maintainer (Pipenv vs Poetry?) and deal with that has been worth it to me. In terms of how they "feel" to develop with? About the same. Similar ideals - skinny models, service layers, REST-first but you can make it RPC-style if you want..…
A couple of comments here have talked about the benefits of “skinny models”, but that runs counter to the advice I’ve seen. How come skinny models? Is the idea to put most of the business logic… where?
Some recommends Service layers, but not the total extreme extent that the service layer is flexible/transferable between frameworks/databases.
https://alexkrupp.typepad.com/sensemaking/2021/06/django-for...
Re: Django 4.0
#74I've used Django for a long, long time (since 0.96). Django is great for backend stuff, but nowadays for full stack applications (if you're not doing an SPA) I find Laravel and Rails a lot better. In particular Laravel's templates (blade) and asset handling is awesome.
Re: Django 4.0
#75We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the c…
Genuinely curious how you happened to choose FastAPI over something more in the middle, like Flask? I tried a few tools in FastAPI, and it's fantastic for those, but I think I'd still stick with Flask for something more well rounded (not just as an API server).
At least for my team we went with FastAPI because we have other tools for everything else, and FastAPI is incredibly simple for new members to pick up. We tend to say that we made a “FastAPI application” but in reality FastAPI is only powering the REST interface for interacting with the platform.
We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together.
Re: Django 4.0
#76Before Django there was Zope in python-land. I don't think I overstate the relevance of what Django did by saying that Django almost single handledy advanced the state-of-the-art of web deployment in Python forward a decade.
Zope hails from the era when Python was trying to appeal to programmers by showing that it, too, could be a Serious Enterprise Language. Everything had layer after layer of abstraction and the code looked more like Java than Python. The Zope ORM was kind of nice in its own weird way, though.
Re: Django 4.0
#77Earlier quoted context omitted.
A couple of comments here have talked about the benefits of “skinny models”, but that runs counter to the advice I’ve seen. How come skinny models? Is the idea to put most of the business logic… where?
I'm unconvinced by the "skinny models" and "service layer" arguments. Django's ORM is an active record style ORM, its at its best if you use it that way. If you want to have a service layer type architecture, use SqlAlchemy with implements the data mapper scheme. I follow this general rule of thumb, in order: If it's a complicated business logic touching multiple models or external apis, put in in a `utils` module (k…
The argument is that Active Record is itself a bad pattern that you should not use. And it may be. But it might be a long way down the runway before you run into the bad effects.
Re: Django 4.0
#78While it doesn't seem like a major update at first glance on this news piece, the changelog is available here : https://docs.djangoproject.com/en/4.0/releases/4.0/ Of note, in my opinion : - The new AddConstraintNotValid operation allows creating check constraints on PostgreSQL without verifying that all existing rows satisfy the new constraint, meaning that one can now create constraints on big postgres tables witho…
Do you know if the ORM solution have the same `a` suffix for async interface? I really hope there is more elegant solution for all this.
Yes - it's kinda ugly at the moment, having all the `a` prefixed functions - but I think it's intended as a kind of long-term-intermediate step - since the whole of django isn't async at the moment, and needs to have separate versions for everything.
I (wildly) speculate that once the ORM is async too, and all the rest of the bits fall into place (maybe django 5?), maybe django 6 will drop the `a` prefixes and integrate it all back together somehow?
Re: Django 4.0
#79I've always followed Django as Python is my first language and still my 'natural' way to think about code. The more I look into it, the more I feel like the learning curve is a bit like a camel's back. Easy for some stuff. Hard to figure the middle part (usually because not understanding "how" Django really works). And easy at the ends after knowing how you can "mould" Django in certain ways. It feels like a great multitool for the professionals who need to create project after project.
I believe the middle part of the learning curve can be easier, but with the "social cruft" of all the Django tutorials out there, it's a game of luck to encounter what's good and what are the different, sensible, approaches to handling growing/big Django apps.
What can make this easier is a document/discussion of some sort that provides clear, complete, approaches. Here are some aspect that needs to be considered. I believe with the combinations defined, and describing the tradeoffs will be a very great start for any team/person looking to jump into Django, or improve their next project.
- Postgres seems to be default. SQLite + Litestream is there but still bleeding edge.
- Packaging is the hot topic, for sure. Pipenv, poetry, venv, etc?
- Traditional Serverside Templating + JS enhancement (HTMX/Hotwire/etc), or JS based SPA (React, Vue, Angular, Svelte, etc)
-- This also includes the asset compiling story (Tailwind JIT, Sass compilation, Babel/webpack/rollup/etc)
- Fat models, Fat views, or Service layer? To which extent?
- Single app (Doordash) or Multiple apps (Thread with >500 apps)?
- What's the theoritical limit to using Postgres + Disk/Memory Caching (so no external Redis/ElasticSearch/other services needed)?
-- Search, queues/async job, scheduled jobs, reports, emails, etc
EDIT: A view additional points
- Documented limits about using whitenoise to serve static assets, and when & how to move to S3. Also Cloudflare/CDN fronting
- Cloud storage story (uploading to S3 api from FileField and Rich Text fields, and also async jobs)
Re: Django 4.0
#8014 days ago https://news.ycombinator.com/item?id=29303611
76 days ago https://news.ycombinator.com/item?id=28609188
3 month ago https://news.ycombinator.com/item?id=28566044