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

51–60 of 141 posts

Re: Django Styleguide

#51

Post by giancarlostoro »

roflyear wrote: post #44
giancarlostoro wrote: post #14

Earlier quoted context omitted.

I would just use serverless functions to achieve the same thing personally, if you're in the cloud already, chances are high you can trigger functions based on new records in a database or new file uploaded, or what have you. Then you don't need to import much outside of the serverless SDK which should typically be pretty minimal. That's how I did a timed function for a Django project we were hosting in Azure anyway.

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 fond of having my web server running things in the background it ruins my mental model of the web.

Re: Django Styleguide

#52

Post by nprateem »

hbrn wrote: post #39

Ah, the typical "where to put business logic in Django". M in ActiveRecord MVC web frameworks is deeply misunderstood. M is not "data model" (it would be called DVC if that was the case). M is your domain model. It's the model of your business, model of the real world. It's the core of your application. Another thing that I never understood, why are functions called services? Is it a subconscious desire to go back to…

Business logic goes in the controller. That's why it's called a controller because it controls stuff like access to your data.

Re: Django Styleguide

#53

Post by hbrn »

miketery wrote: post #48
j4mie wrote: post #28

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 o…

> "Reuse serializers as little as possible" is the single best piece of advice when using DRF. The inline InputSerializer thing is brilliant. Can you expand on this? What is the InputSerializer as opposed to custom rest serializers?

I think the idea is that instead of thinking "here's the object I'm serializing" you should think "here's the view (endpoint) I'm serializing for".

Contrary to what people usually think, the shape of the serialized object is typically defined by the API endpoint, not by the object itself. Different endpoints can (and will) serve different shapes of the same object.

Even if two endpoints serve the same shape today, they can deviate tomorrow. When this happens, most people are trying to resolve it through DRF inheritance, which is wrong.

Re: Django Styleguide

#54

Post by cjohnson318 »

rajasimon wrote: post #35
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…

> 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 :)

Re: Django Styleguide

#55

Post by cjohnson318 »

rowanseymour wrote: post #50
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…

> You can make subdirectories without making apps, and thus avoid dependency hell. It's hard to get 100% right and thus our projects always have a few lazy foreign key relationships and inline imports to avoid cyclical imports... but I think our code is easier to manage because we try to model the dependency relationships by having things in separate apps. > Also be wary of the formerly South, now built-in migrations…

I'm currently in circular import hell. My business logic has Jobs and Loads, and they both need to update each other under certain circumstances. Should these two things/monstrosities be lumped into the same app?

Re: Django Styleguide

#56

Post by hbrn »

nprateem wrote: post #52
hbrn wrote: post #39

Ah, the typical "where to put business logic in Django". M in ActiveRecord MVC web frameworks is deeply misunderstood. M is not "data model" (it would be called DVC if that was the case). M is your domain model. It's the model of your business, model of the real world. It's the core of your application. Another thing that I never understood, why are functions called services? Is it a subconscious desire to go back to…

Business logic goes in the controller. That's why it's called a controller because it controls stuff like access to your data.

Oh sweet summer child.

Please read this carefully: https://folk.universitetetioslo.no/trygver/1979/mvc-2/1979-1...

Business logic is supposed to be reused. Controllers in web frameworks (views in Django) expose no way to do it.

Re: Django Styleguide

#57

Post by cjohnson318 »

rajasimon wrote: post #35
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…

> 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/

Re: Django Styleguide

#58

Post by nprateem »

hbrn wrote: post #56
nprateem wrote: post #52

Earlier quoted context omitted.

Business logic goes in the controller. That's why it's called a controller because it controls stuff like access to your data.

Oh sweet summer child. Please read this carefully: https://folk.universitetetioslo.no/trygver/1979/mvc-2/1979-1... Business logic is supposed to be reused. Controllers in web frameworks (views in Django) expose no way to do it.

If you want to reuse logic you make another http request to the right endpoint.

Re: Django Styleguide

#59

Post by rglullis »

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.

As simple as possible, but no simpler. Django models are meant to deal not just with the data, but also with business logic. If `course.has_finished` is a property of the course, why would you want to have a separate function outside of the class?

> Do precomputation if you need the information in a template

If the precomputation is only needed in a template, you can (should, IMO) use template tags.

> Don't make separate apps in the same project (...) avoid dependency hell.

My current pattern here has been to create one "core" project where I represent all the internal models of the domain of the application, and "adapter" apps if I want to interface/integrate with anything from the external world. This makes it easier to extend or replace third-party tools.

> (Migrations) It's built around a fragile model.

I wouldn't call it fragile, quite the opposite. There are some annoying limitations for sure (I didn't find a reliable way to change the primary key of a model, except for creating a whole new model and migrating the data to it), but I think they are due to a matter of strong safety that the migration can only be done if it consistent.

Re: Django Styleguide

#60

Post by nicolaslem »

drcongo wrote: post #20
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 all of this, although I do like class based views.

Me too, I think it's important to acknowledge that no approach is perfect. Pick your poison.
Post reply on HN