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

Django and Postgres for the Busy Rails Developer

andyatkinson.com

Post reply on HN
Print view View original

111–120 of 127 posts

Re: Django and Postgres for the Busy Rails Developer

#111

Post by globular-toast »

robertlagrant wrote: post #99
globular-toast wrote: post #90

Earlier quoted context omitted.

The problem with Django is not swapping out defaults. The problem is it doesn't like to sit at the edge of an application where it belongs. Django should be equivalent of any other MVC-style framework (like Qt etc), sitting right out in the "interface" layer of your software. But it just doesn't work well out there, mostly due to how tightly coupled it is with its ORM.

Django isn't that, though. That would be something like Flask. Django is batteries-included for one (broad) purpose: you are going to use a relational database to make a CRUD app and we will make that easier for you by standardising a load of stuff. That constraint buys a lot of power.

Nothing is ever just pure CRUD, though. What would you say is the minimum level of business logic where one should consider Django the wrong tool for the job?

One of the problems I find is gradually complexity creep from the business. It starts off as a little clean method here, a signal there etc. Before you know it you've got a domain model tightly coupled to CRUD primitives.

Re: Django and Postgres for the Busy Rails Developer

#112

Post by aerhardt »

irjustin wrote: post #56
deaddodo wrote: post #43

Earlier quoted context omitted.

> I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.

Yeah SQL Alchemy is 1000x better. Django's ORM is miserable. User.objects.filter(company__product__product_variation__var_type__in=['var1', 'var2']) vs User.where(company: { product: { product_variation: { var_type: ['var1', 'var2'] }}}) Little things like that make it so much harder to read.

To each their own, nothing about the first syntax feels miserable to me, my IDE has got me fully supported on it. I don't dislike the SQL Alchemy one though it takes many more lines on my editor (no way I am going to inline all those nested dicts like that).

Re: Django and Postgres for the Busy Rails Developer

#113

Post by Tainnor »

RangerScience wrote: post #93
Tainnor wrote: post #38

Earlier quoted context omitted.

Rails and especially DHH particularly encourage not having any sort of separation between your domain objects and your persistence (and even your views), which is why N+1 queries are so goddamn common and why people are going to put confirmation mail logic in model callbacks etc.

> your domain objects and your persistence Hmm. Thinking over my career... Maybe I don't know what you mean by "domain objects", "separation", and "persistence", but when I think over the stuff I've worked on in my career, and the problems I've seen in codebases... Yeah, I think I'm with them on this - your domain objects and your persistence should pretty much be the same thing. There's gonna be a few exceptions (an…

Your business logic should not be tied your persistence, that's what I mean by it.

By "domain objects" I don't mean that you need to embrace OOP, they could be simple structs without any associated logic.

> PPS - N+1 queries are kinda trivial to resolve in most cases in Rails? There's core ORM functionality for it.

The problem isn't that you can't fix N+1 queries in Rails, it's that it's incredibly easy to create them by accident because your ActiveRecord objects carry a DB connection around everywhere, even in views.

Re: Django and Postgres for the Busy Rails Developer

#114

Post by dlx »

RangerScience wrote: post #33
czhu12 wrote: post #21

I worked significantly in both Django and Rails, and I found the most magical part of rails is its ORM (ActiveRecord). I find both SQLAlchemy and DjangoORM both more awkward and less natural to use, both for the query side and the relationship definition side. Once the data is loaded into memory, everything else is just syntax. At this point, I only reach for python as a web application if I need to build something t…

FYI, there’s a few projects out there for interoperability between Ruby and Python - stuff like putting one language in another. Also, Jupyter and Zeppelin notebooks allow for interoperability, although I don’t know how. (Oh, lastly, if there’s a JVM implementation of Python you could probably use alongside JRuby)

Any recommended ones? Like the parent, I have to reach for Python for AI / ML work and would love to use Rails as the web frontend instead of Django.

Re: Django and Postgres for the Busy Rails Developer

#115

Post by robertlagrant »

globular-toast wrote: post #111
robertlagrant wrote: post #99

Earlier quoted context omitted.

Django isn't that, though. That would be something like Flask. Django is batteries-included for one (broad) purpose: you are going to use a relational database to make a CRUD app and we will make that easier for you by standardising a load of stuff. That constraint buys a lot of power.

Nothing is ever just pure CRUD, though. What would you say is the minimum level of business logic where one should consider Django the wrong tool for the job? One of the problems I find is gradually complexity creep from the business. It starts off as a little clean method here, a signal there etc. Before you know it you've got a domain model tightly coupled to CRUD primitives.

I'd say you should be able to quantify it. "a domain model tightly coupled to CRUD primitives" is not an intrinsic evil. If you were to genuinely save money or reduce risk by, say, moving off a relational database you would just need to pick that point and motivate for a rewrite.

The much higher risk IMO is building a hyper-flexible application from the start knowing what you need today is a CRUD app, just in case in future you need something else. That's how you get shelfware and awkward conversations.

Re: Django and Postgres for the Busy Rails Developer

#116

Post by Tainnor »

brap wrote: post #48

With all of this praise Rails is getting, even still in 2024, it’s mind boggling how there was never a successful Rails alternative in one of today’s popular web programming languages. Nothing ever caught on.

Everyone who got tired of Ruby and Rails during its hype years has since moved on to various other technologies, now most of the people who are still working on Rails are the people who agree with its design choices, which explains the amount of praise it gets.

IMHO the major upsides of Rails were subsequently adopted by almost all major frameworks in other languages. It may not be sexy or make HN front page a lot, but Spring Boot definitely "caught on", for example.

Re: Django and Postgres for the Busy Rails Developer

#117

Post by giancarlostoro »

silviogutierrez wrote: post #109
giancarlostoro wrote: post #101

Earlier quoted context omitted.

It can, just needs to be built. I'm thinking of something that can both compile to WASM AND be somewhat like Phoenix Liveview. Looks like there's some attempts for Phoenix Liveview for Python. https://github.com/liveviews/liveviews?tab=readme-ov-file#py...

I think the foundation, sure. But the ecosystem of React, including UI libraries, charting, forms, and so forth, is enormous.

Every developer I know who has adopted Blazor never wants to go back and touch JavaScript. If you do it right, it will sell itself, your market isn't people who use React exclusively, but people using Python and possibly react, but also any other web framework. IMHO the key thing would be a standard similar to WSGI for this system, so it can be implemented and supported by any web framework. ... the more I think about it, the more I am going to have to look at writing a draft PEP...

Re: Django and Postgres for the Busy Rails Developer

#118

Post by globular-toast »

davepeck wrote: post #110
globular-toast wrote: post #95

Earlier quoted context omitted.

I use htpy and it's great. There are others like htmy[0] too. The problem with templates in general is you can write malformed HTML in them. The nice thing about htpy et al is you simply can't do that. I feel like what we really want is JSX in Python, where you can write XML-like syntax and it's converted into Python at import time. [0] https://volfpeter.github.io/htmy/

PEP 750 started its life in part as a result of learnings from pyxl [0], which used some clever hacks to add a JSX-like syntax to Python. In the end, my instinct is that t-strings are the better more generic feature to add to the language itself today. That said, I'd love to see the Python ecosystem get to the point where it's relatively easy to implement transpilers and get new grammars integrated with key tools (co…

Wow, had no idea about pyxl. Thanks for the background!

Re: Django and Postgres for the Busy Rails Developer

#119

Post by deaddodo »

aerhardt wrote: post #112
irjustin wrote: post #56

Earlier quoted context omitted.

Yeah SQL Alchemy is 1000x better. Django's ORM is miserable. User.objects.filter(company__product__product_variation__var_type__in=['var1', 'var2']) vs User.where(company: { product: { product_variation: { var_type: ['var1', 'var2'] }}}) Little things like that make it so much harder to read.

To each their own, nothing about the first syntax feels miserable to me, my IDE has got me fully supported on it. I don't dislike the SQL Alchemy one though it takes many more lines on my editor (no way I am going to inline all those nested dicts like that).

> no way I am going to inline all those nested dicts like that

You would rather inline them into a single nested magical variable name instead?

Re: Django and Postgres for the Busy Rails Developer

#120

Post by [deleted] »

globular-toast wrote: post #111
robertlagrant wrote: post #99

Earlier quoted context omitted.

Django isn't that, though. That would be something like Flask. Django is batteries-included for one (broad) purpose: you are going to use a relational database to make a CRUD app and we will make that easier for you by standardising a load of stuff. That constraint buys a lot of power.

Nothing is ever just pure CRUD, though. What would you say is the minimum level of business logic where one should consider Django the wrong tool for the job? One of the problems I find is gradually complexity creep from the business. It starts off as a little clean method here, a signal there etc. Before you know it you've got a domain model tightly coupled to CRUD primitives.

[deleted]
Post reply on HN