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

101–110 of 141 posts

Re: Django Styleguide

#101

Post by roflyear »

giancarlostoro wrote: post #51
roflyear wrote: post #44

Earlier quoted context omitted.

Serverless functions are good for some stuff: clear this cache on this schedule, run this task when XYZ happens, etc.. But that is not the popular usecase for celery. Often you want "some code" (that you likely already have written) to be executed async. Sure, you can create a public interface for "some code" then write a record, that the serverless function is looking for, that then calls back to that interface (but…

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?

Re: Django Styleguide

#102

Post by roflyear »

nickjj wrote: post #76
roflyear wrote: post #42

Earlier quoted context omitted.

Agreed. I have had more luck writing my own "jobs" engine that does stuff that I need that celery doesn't have anyway (retries, some record of execution, rate limiting). I'm sure if I really tried, I can get celery to be very reliable... but I never really got there. Also for whatever reason I have NEVER been able to get celery to be reliable for its scheduling/cron stuff. It just starts to fail. I use this library f…

What type of situations did you run into while using it? I've been using Celery for a long time in production now. Nothing crazy and it's a fairly basic set up of "execute job, thanks!" along with a beat server. Over the last 6-7 years an off the top of my head guess would be that there's been at least 5 million jobs processed. It's not huge volume when measured over years but it's been stable. One server was running…

Celery has a lot of gotchas, but primarily the issue I have had is with resource consumption. Maybe it is a problem with my config, but I haven't had this issue with other solutions.

Re: Django Styleguide

#103

Post by matsemann »

traverseda wrote: post #93
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.

You want to add an ORM to the ORM? Why?

How is that adding an ORM to the ORM? I want all django orm access to happen at defined places, instead of the spaghetti mess it is when people do SomeOtherModulesModel.objects.filter(..) and expose themselves to the internal workings of that module. Access it through a selector instead.

Re: Django Styleguide

#104

Post by rglullis »

matsemann wrote: post #103
traverseda wrote: post #93

Earlier quoted context omitted.

You want to add an ORM to the ORM? Why?

How is that adding an ORM to the ORM? I want all django orm access to happen at defined places, instead of the spaghetti mess it is when people do SomeOtherModulesModel.objects.filter(..) and expose themselves to the internal workings of that module. Access it through a selector instead.

If for some strange reason your application has data that it was not created with Django, sure.

But aside from that you are just adding another layer of abstraction that does not give any benefit when all your models are managed by Django already.

Re: Django Styleguide

#106

Post by [deleted] »

drcongo wrote: post #18
YPCrumble wrote: post #3

Earlier quoted context omitted.

What’s wrong with that?

It's a pet peeve more than anything - I just hate it when I have to scroll around to find if a class is abstract or not, our team puts it at the top so that's never an issue. Having it anywhere else means it can be any arbitrary number of lines below the class definition making it harder to find.

[deleted]

Re: Django Styleguide

#107

Post by KyeRussell »

drcongo wrote: post #18
YPCrumble wrote: post #3

Earlier quoted context omitted.

What’s wrong with that?

It's a pet peeve more than anything - I just hate it when I have to scroll around to find if a class is abstract or not, our team puts it at the top so that's never an issue. Having it anywhere else means it can be any arbitrary number of lines below the class definition making it harder to find.

I’ve never worked on a Django codebase that puts Meta at the top of a model definition. Not saying that it’s the wrong hint to do, but this just feels like feigned surprise because you surely also know that it’s far from common.

Re: Django Styleguide

#108

Post by asalahli »

dec0dedab0de wrote: post #90
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…

Always keep your models slim. Don't stuff template ...course_has_finished(course) is not much longer than course.has_finished() I disagree with this. When trouble shooting or expanding code it is super convenient to import a model and have all of your methods on auto complete. Especially when you need the same functionality in a view, a cron job, a celery task, and an DRF end point. If you want to keep it clean you c…

In my view (hehe), Django's class based views is a good idea implemented poorly. In theory you should be able to use any of the built-in class based generic views with minimal customizations to suit your needs, except when you want to do such customizations you're left dealing with a huge inheritance tree of mixins. It's all magic unless you know or wanna read the documentation on what each mixin brings to the view, that is _if_ you know what mixins are involved exactly, of course.

Re: Django Styleguide

#109

Post by cjohnson318 »

hbrn wrote: post #99
cjohnson318 wrote: post #87

Earlier quoted context omitted.

> ...all the orchestration of jobs should happen through mediator (same for load) So, in a smaller app, when a request comes into job/views.py or load/views.py then we immediately start working with JobLoadMediator to handle business logic between the two? I was just going to focus on specific tasks between job and load. I'll probably look into signals; I haven't used those in several years and as I recall, it felt h…

> when a request comes into job/views.py or load/views.py then we immediately start working with JobLoadMediator to handle business logic between the two? In my world, mediator.views and job.views would likely have different audiences. mediator.views is for business domain (e.g. your API). Though name would not be mediator, it would be something domain-specific. job.views could be for more low-level internal tooling…

> 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 relations.

Do you know of some blog posts or books that go into the way you normally organize things?

> if you can't reason about load without job, and can't reason about job without load

There is a lot of interaction between all of the parts of the app, but particularly between Jobs, Loads, Inventory, Stages, and Drivers. In the future I might start with one app, and then add another if I absolutely have to.

Re: Django Styleguide

#110

Post by asalahli »

aequitas wrote: post #97
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.

A lot of people use Django with uWSGI, which also comes with queues, cron, workers, cache and lots more. I've been stuck with Celery on previous projects for reasons. But I've been dying to try out uWSGI's built in features for this. Hearing great things about it. https://uwsgi-docs.readthedocs.io/en/latest/Spooler.html https://uwsgi-docs.readthedocs.io/en/latest/Cron.html https://uwsgi-docs.readthedocs.io/en/latest/…

Fellow uWSGI fan here. Unfortunately uWSGI is now in maintenance mode, not because is complete which would've been fine, but because the maintainers are not able to dedicate time to it[0]
Post reply on HN