Live data from Hacker News

Django Styleguide

github.com

61–70 of 141 posts

Re: Django Styleguide

#61
post #56

Earlier quoted context omitted.

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.

Are you just trolling? Or your cronjobs are really making http requests?

Re: Django Styleguide

#62
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.

Since everyone suggests alternatives to Celery, may I plug my own healthier celery?

https://github.com/NicolasLM/spinach

Re: Django Styleguide

#63

Earlier quoted context omitted.

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

The short answer is yes.

The long answer is if two entities are updating each other you might benefit from shifting all update responsibilities to one of them. Or even to a third entity that knows about both and keeps those two isolated from each other.

Re: Django Styleguide

#64
post #37

Earlier quoted context omitted.

"Also be wary of the formerly South, now built-in migrations stuff. It's built around a fragile model (perfect history representation), so has lots of foot guns." My experience has been opposite so I'd be interested in hearing your experiences if you are willing. I have been using the built in migrations since day 1 on a medium sized Django project with 350+ migrations and migration issues for our project have been e…

Same here. If I was starting a non-Python project tomorrow I'd consider using Django to manage the database schema - especially now that we can describe custom indexes and constraints in migrations. Our project has gone thru over 1000 migrations so far tho we squash them down to 50 or so about once a year.

Thats interesting, if I was using TypeScript to access the data, how would I keep the schemas in sync between TS and python?

Re: Django Styleguide

#65
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…

At my current company, we've had many teams over the years fail to make business logic in model methods work, and I think many other people have had similar results. The issues usually boil down to some combination of "business logic is too coupled to the data model" and "this method lives at an intersection of these two models and creates weird dependency problems". I now feel that Django puts you down a path for failure by naming the DB layer "models" and not giving users a decent place to put cross-model domain logic.

My current preference is a functional core-imperative shell-style architecture where as much code lives in the functional core as possible. It's not very elegant with Django but it works fine. Cosmic Python (really accessible and fairly quick read if you have the time: https://www.cosmicpython.com/book/preface.html) has examples that are similar.

Re: Django Styleguide

#66
post #63

Earlier quoted context omitted.

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?

The short answer is yes. The long answer is if two entities are updating each other you might benefit from shifting all update responsibilities to one of them. Or even to a third entity that knows about both and keeps those two isolated from each other.

Woof. Thank you so much. I like the idea of a third party, like a mediator.

Would that mediator be another app? Or should it be some module sitting in the project directory? (I'm not even sure Django would import something like that.)

Re: Django Styleguide

#67

Earlier quoted context omitted.

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

Well you're writing Python so you're never truly stuck when you run into dependency issues, but if you feel like you're in hell then maybe they do belong in the same app. All complex real world apps have complex dependencies between entities - all I would argue is that "put them all in the same package" generally isn't the most scalable solution.

Re: Django Styleguide

#68
I've found it helpful in several projects to implement the "services layer" described here as a state machine, modeling state transitions for a central object (e.g. an article can be drafted, submitted, reviewed, published). The state machine enforces permissible transitions and handles side effects which touch other models.

Re: Django Styleguide

#69

I've been working on a project with flask + sqlalchemy. I have those sql queries returning a bit of rows (up to 20k) and that are quite slow. SQLalchemy does not seem to support caching the results and I've started to use flask-caching[1] with redis using the @cache.memoize() decorator. Just wondering if I am taking the right path or if there is better alternative. [1] https://flask-caching.readthedocs.io

Indexed?

If complex, what does Sqlalchemy output as the SQL? Could you optimise the query? If quite complex, optimise the tables by redesigning them?

Was the move to allow Redis to cache persistently across requests? Does it do this?

Are you timing each function to look for slowness?

Re: Django Styleguide

#70
post #64

Earlier quoted context omitted.

Same here. If I was starting a non-Python project tomorrow I'd consider using Django to manage the database schema - especially now that we can describe custom indexes and constraints in migrations. Our project has gone thru over 1000 migrations so far tho we squash them down to 50 or so about once a year.

Thats interesting, if I was using TypeScript to access the data, how would I keep the schemas in sync between TS and python?

I've never used TypeScript to talk to a database but there might be tooling to generate classes from tables. Even if there isn't, manually keeping some TypeScript classes in sync might still be worth the effort, for being able to manage schema migrations easily elsewhere.
Post reply on HN