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

131–140 of 141 posts

Re: Django Styleguide

#131

Post by rglullis »

matsemann wrote: post #130
rglullis wrote: post #128

Earlier quoted context omitted.

> not doing it is why most django code is incomprehensible and slow. > No longer should anyone in their module > they should always go through a service Weasel words and opinions-as-fact. Come back when you have a way to show that your approach gives any actual benefit.

I did give an example. What you call opinions-as-fact was me trying to explain the approach, not commanding anything. That you disagree (or can't comprehend it?) doesn't make it weasel words. Please don't behave like this towards me, read the guidelines. You can find a link at the bottom of this page. I'll leave this "discussion" here as it's unfruitful when you act so hostile.

If your idea of "explaining the approach" does not address the "why?" and depends on "should always X" and "should never Y", then you are resorting to weasel words.

"incomprehensible and slow". To whom? How slow? What about your approach makes it faster?

A sibling comment pointed one important aspect: Django Querysets are lazily evaluated, I find it really hard to believe that having a layer that constant marshalls and unmarshalls the data through pydantic can make anything faster than not having to fetch any data until you really need it.

Re: Django Styleguide

#132

Post by rajasimon »

cjohnson318 wrote: post #57
rajasimon wrote: post #35

Earlier quoted context omitted.

> Don't make separate apps in the same project, unless the project actually consists of several different, completely independent projects. You can make subdirectories without making apps, and thus avoid dependency hell. I wrote an article on this. My goto strategy is to create a project/core/views.py,models.py,apps.py,tests.py

Are you talking about this: https://rajasimon.io/blog/django-project-structure/

yup that's that. Thanks for finding it for me :)

Re: Django Styleguide

#133

Post by rajasimon »

cjohnson318 wrote: post #54
rajasimon wrote: post #35

Earlier quoted context omitted.

> Don't make separate apps in the same project, unless the project actually consists of several different, completely independent projects. You can make subdirectories without making apps, and thus avoid dependency hell. I wrote an article on this. My goto strategy is to create a project/core/views.py,models.py,apps.py,tests.py

> I wrote an article on this. Link or it didn't happen :)

lol forgot to include

Re: Django Styleguide

#134

Post by matsemann »

Nextgrid wrote: post #118
matsemann wrote: post #89

Earlier quoted context omitted.

> If `course.has_finished` is a property of the course, why would you want to have a separate function outside of the class? Because one should avoid passing Django models around. It leads to bad design. Have a selector or something that uses the ORM, but exposes some dataclass or pydantic model instead, and put the logic there.

Keep in mind that passing around querysets has performance advantages you wouldn't get by passing around dataclasses or similar. For example, if you do a query like Model.objects.filter(related_model__in=RelatedModel.objects.filter(...)) the ORM will only run a single query, silently converting the second one into a JOIN. If you pass lists of "RelatedModel" however you would've had to first one one query to get that…

That gain is often lost by people doing unoptimized queries all over the place, though, instead of a single place where the queries are optimized. And passing the fat django objects around often lead to accidental n+1 queries, since you can't really trust that looking up a property on your object doesn't do a new query. Often nicer to avoid it all, by having a gated access to the DB.

While I propose most often sending in a list of related IDs (premature optimization and all that), the function could just accept any iterable, and you from the outside could send in the lazy relatedmodel query.

Re: Django Styleguide

#135

Post by giancarlostoro »

roflyear wrote: post #101
giancarlostoro wrote: post #51

Earlier quoted context omitted.

Ive used serverless in this way as well when it was a long running process, basically the end-user needed to upload a Shapefile, and some of them can be quite large, so I kicked off an Azure Function once the file was uploaded to parse the file in the background. If it's something that will halt the browser when it needs to run in the background instead, that's where I'll use Serverless if it makes sense. I'm not fon…

> I'm not fond of having my web server running things in the background it ruins my mental model of the web. Well yes, and you run into other problems as well (now if your process dies or you deploy or something you have to be careful to not kill running jobs). How much of your logic is in the azure function?

Only things that needed to be done behind the scenes that could take a long time, like we would take JTIFFs that could be gigs of data, and analyze them and create variations of the same image. You don't want someone who just uploaded a 1GB file waiting for you to also analyze it as well.

Re: Django Styleguide

#136

Post by roflyear »

giancarlostoro wrote: post #135
roflyear wrote: post #101

Earlier quoted context omitted.

> I'm not fond of having my web server running things in the background it ruins my mental model of the web. Well yes, and you run into other problems as well (now if your process dies or you deploy or something you have to be careful to not kill running jobs). How much of your logic is in the azure function?

Only things that needed to be done behind the scenes that could take a long time, like we would take JTIFFs that could be gigs of data, and analyze them and create variations of the same image. You don't want someone who just uploaded a 1GB file waiting for you to also analyze it as well.

Eh, yeah, I just don't like any real logic being in those types of systems. Just too hard to test and chase down issues.

I guess "convert this image" is ok, since it is kind of a "pure function" sorta.

Re: Django Styleguide

#137

Post by ccanassa »

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…

I spent 3 years building a high scale crawler on top of Celery.

I can't recommend it. We found many bugs in the more advanced features of Celery (like Canvas) we also ran into some really weird issues like tasks getting duplicated for no reason [1].

The most concerning problem is that the project was abandoned. The original creator is not working on it anymore and all issues that we raised were ignored. We had to fork the project and apply our own fixes to it. This was 4 years ago so maybe things improved since them.

Celery is also extremely complex.

I would recommend https://dramatiq.io/ instead.

[1]: https://github.com/celery/celery/issues/4426

Re: Django Styleguide

#138

Post by cjohnson318 »

funkydata wrote: post #125
cjohnson318 wrote: post #109

Earlier quoted context omitted.

> mediator.views is for business domain (e.g. your API) > job.views could be for more low-level internal tooling That's very interesting. I'm mostly following the architecture from: https://phalt.github.io/django-api-domains/styleguide/ I knew this was going to be a large project, about 19 apps, supporting a trucking and inventory web/mobile app, and I wanted a sane/organized way to deal with all of the models and re…

If you try to keep everything in one app, you'll have gigantic views.py, models.py, etc. Nobody wants to work with those. Also, a simple typo in those files can bring your whole system down and can make it hard to debug. Apps, are a cheap (EXCEPT when you HAVE TO [but really, do you? Really?] move models between apps) way to keep YOU sane.

Right, no one wants to work on a 10k line view.py file. However, if you put everything into its own app, like I did, then you run into circular dependencies as your project gets closer to feature complete. So, the answer is somewhere in the middle. At the moment, I have about 20 apps, with 1 to 4 models per app, and 20% of all that is highly interdependent. I should have put the big, highly interdependent pieces in one app, and have the less connected pieces in separate, bare-bones crud-apps.

Re: Django Styleguide

#139

Post by giancarlostoro »

roflyear wrote: post #136
giancarlostoro wrote: post #135

Earlier quoted context omitted.

Only things that needed to be done behind the scenes that could take a long time, like we would take JTIFFs that could be gigs of data, and analyze them and create variations of the same image. You don't want someone who just uploaded a 1GB file waiting for you to also analyze it as well.

Eh, yeah, I just don't like any real logic being in those types of systems. Just too hard to test and chase down issues. I guess "convert this image" is ok, since it is kind of a "pure function" sorta.

Correct, I only use them for very specific needs where it would slow down my website, or be weird to spin off a new thread in the background. I do know Azure supports WebJobs which is probably the closest you can get to something like Celery, which funnily enough, is what Azure Functions (at least originally) are built on top of.

Re: Django Styleguide

#140

Post by radoslav_ »

Hello everyone,

Radoslav here (one of the authors of the mentioned Django Styleguide).

First of all - I want to thank everyone to the comments The fact that someone took the time to read the styleguide & then write a comment / propose a different POV - is humbling.

I've read everything once & I'll do so at least couple more times. There are interesting ideas & comments that we can apply!

And finally, I want to add some more context:

1. That particular styleguide has served us, and it's still serving us well. It's basically a list of ideas that we found useful, thanks to the various Django projects that we've been exposed to at HackSoft.

2. One core philosophy of the style guide is the ability to cherry-pick whatever makes sense to you. Even at our company, it's very rare to have 2 Django projects following the exact same structure. The styleguide is rather a framework / direction for things that's been proven to work, from our experience.

3. And of course, the styleguide can use some more love from us. We are sitting on a lot of unshared knowledge that needs to be structured and applied back to the Django Styleguide & the corresponding Django Styleguide example project.

4. We try to keep it pragmatic, so you can actually build something. For example, DDD sounds great, but lacks pragmatism and slows you down by a lot (at least, for us).

5. And finally - this is not the "only right way" to do Django. As there is no "right way" to build software. Luckily, there are always options. We'll update the list of other suggested approaches, so people can have a choice / navigate the space better.

As an example of one of the big topics that we want to touch upon is nesting apps. Alongside the "services / selectors" layer (btw - you can call this whatever suits you best ), the ability to nest apps within apps is really powerful, when it comes to the structure and longevity of a Django project. Having 50+ flat apps is not the best experience.

Our current focus is around building the company (HackSoft). The Django Styleguide will be soon to follow. We are slowly gaining more speed & we'll eventually get there

All discussion around "How to do Django" are in fact really interesting. If we happen to meet at some future EuroPython / DjangoCon Europe - I'm always open to discuss in person. Otherwise, if you have specific comments / suggestions - you can submit it either as an issue / discussion, or just send an email to radorado@hacksoft.io

Cheers!

Post reply on HN