Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django Styleguide

github.com

Post reply on HN
Print view View original

21–30 of 141 posts

Re: Django Styleguide

#21

Post by andybak »

VWWHFSfQ wrote: post #15
andybak wrote: post #12

Earlier quoted context omitted.

Yeah. Or a simple cron wrapper like django-cron to get the best of both worlds. For background tasks - you can just spawn a background process and keep a simple status table in the db so the main app can check if it's completed (assuming you even need that) And for task queues that can handle the traffic most sites will need there's things like django-huey.

> For background tasks - you can just spawn a background process and keep a simple status table in the db so the main app can check if it's completed (assuming you even need that) I don't know if making my own bespoke queue system is a great idea. It seems simple enough, but it gets so much more complicated once you start seeing issues with it. Orphaned task processes sticking around on the server forever, concurrenc…

I'd never argue for building your own - just for using something simpler than Celery

It's not so bad now as CI/CD, Docker etc have made complex deployments easier to handle. But back when I was wrestling with Django simply deploying Celery on a new host could easily waste an afternoon and all those dependencies made me very nervous about the overall complexity.

I still weigh carefully anything that adds another long-running process or non-Python dependency to my sites.

Re: Django Styleguide

#24

Post by VWWHFSfQ »

olau wrote: post #17

I think there are too many concepts in this, but rather than being negative, here are some tips: Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in…

Agree with migrations. I've spent a lot of time doing migration surgery to get things back into a consistent state. But mostly I've found that if you just let Django manage the database how it wants to then things will be fine. But get very familiar with merge migrations and fake migrations if things start to go awry.

I disagree with the perspective on CBVs though. I've been programming Django since 0.96 and CBVs have made nearly everything easier and better for me.

Re: Django Styleguide

#25

Post by j4mie »

notdarkyet wrote: post #7
andybak wrote: post #5

> We use Celery for the following general cases: > > Communicating with 3rd party services (sending emails, notifications, etc.) > Offloading heavier computational tasks outside the HTTP cycle. > Periodic tasks (using Celery beat) Sigh. No mention of the trade-offs. There's simpler ways to do all these things. Celery is a big complex beast and it always pains me to see it as the default suggestion for simple tasks.

Do you have additional examples of those simpler ways? I totally understand how Celery can be a hammer and everything is a nail type situation.

https://github.com/dabapps/django-db-queue

(I am the author)

EDIT: oh hi, Andy :)

Re: Django Styleguide

#26

Post by true_religion »

VWWHFSfQ wrote: post #13
true_religion wrote: post #8

Earlier quoted context omitted.

My choice for periodic jobs is cronjobs.

Do you mean a cronjob that calls a Django manager command to do the work? Or invokes an API method? From my experience cronjobs have a lot of downsides as well. They're great for doing tasks local to the server the job is running on. Not so great for the kinds of tasks (periodic or transactional) that Celery/a real queue is designed for.

I use them for invoking django commands on the same server. I do use celery for transactional jobs though. It’s only periodic jobs that get called with cron. For the context, I do this on small web apps with less than 20 dedicated servers (real servers not VPS), so there is a “manager” server that does nothing but run periodic tasks, management interventions, and cleanup operations.

Re: Django Styleguide

#27

Post by rlawson »

olau wrote: post #17

I think there are too many concepts in this, but rather than being negative, here are some tips: Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in…

Good points. Agree with slim models and I personally like a service layer. FBVs are great, CBVs are ok, GCBVs are of the devil

Re: Django Styleguide

#28

Post by j4mie »

I've been heavily inspired by this styleguide over the years, but I still think it's a bit too complex. A few random thoughts:

  - I think "services" is too much of a loaded term. I prefer "actions", and I always use the function-based style.
  - I hate the naming of "APIs" in this document. They use the term "API" when they mean "endpoint" or "view".
  - "Reuse serializers as little as possible" is the single best piece of advice when using DRF. The inline InputSerializer thing is brilliant.
  - Having each each endpoint only handle a single HTTP verb is brilliant.
  - URLs and views should be separate from all other business logic (models, actions etc).
  - For read endpoints and associated business logic, I'd encourage https://www.django-readers.org/ (disclaimer: I'm the author).

Re: Django Styleguide

#29

Post by roland35 »

olau wrote: post #17

I think there are too many concepts in this, but rather than being negative, here are some tips: Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in…

Is there a better alternative to South (built-in now) for migrations? I always had issues but figured it was the de facto for a reason.

Re: Django Styleguide

#30

Post by andybak »

Spivak wrote: post #16
andybak wrote: post #5

> We use Celery for the following general cases: > > Communicating with 3rd party services (sending emails, notifications, etc.) > Offloading heavier computational tasks outside the HTTP cycle. > Periodic tasks (using Celery beat) Sigh. No mention of the trade-offs. There's simpler ways to do all these things. Celery is a big complex beast and it always pains me to see it as the default suggestion for simple tasks.

Because it’s mature, well integrated with Django and is a path so well-trodden there’s a McDonald’s on the way. Any possible use-case you can imagine for a job queue has been done in Celery and documented. Celery being complicated is also entirely on the operational side, once you actually have Celery using it from within your app is simple enough. Cron is awful for this use-case. You end up just inventing Celery but…

> Celery being complicated is also entirely on the operational side, once you actually have Celery using it from within your app is simple enough.

Yeah and to some degree improvements in devops quality of life in the last few years has softened my view. (I used to mainly use Webfaction without access to apt-get and my own hand-rolled scripted deployment. Ugh...)

But I'd still usually prefer a pure-Python solution without additional persistent processes - assuming there is one and it's fairly well-documented. Huey is pretty good from recollection.

> Cron is awful for this use-case. You end up just inventing Celery but worse when you decide how your app and the cron scripts communicate. If you wanted just scheduled tasks but simpler use something like APScheduler.

I was advocating for something like this. There's django-cron etc which solves issues around communicating with scripts.

I do see both sides of the debate between "complexity" and "solves problems out of the box". I'm generally on the Django side when the flask vs Django discussion happens. There's always trade-offs.

Post reply on HN