3 ms·

I have been using Django since 0.95 and I haven't seen anything which is so flexible with amazing DSLs while also making it easy to understand the magic behind

by ranedk 2mo ago

I have been using Django since 0.95 and I haven't seen anything which is so flexible with amazing DSLs while also making it easy to understand the magic behind it. For the last 10 years, even in a Golang stack or Java stack, I still use Django for models and migration. I even have generators which generate Gorm (or other framework) DAO or Java hibernate classes using Django models. With LLMs, it becomes easier since I can now write all the model, custom querysets in Django, ask the LLM to generate Golang DAO, setters and getters... and test the query against the Django generated queries for completeness. Atlas, sqlx, sqlc and all other ORM like things in golang cannot do migrations the way Django does.

0xpgm 2mo ago
I've never done it, but now that you say it, it makes a lot of sense. Using Django just to manage the database and do migrations, even behind other language stacks. You also get the Django admin interface for free. I once tried using SqlAlchemy but I couldn't help asking myself why it felt so complicated compared to Django.
- ranedk 2mo ago
  People who hate ORMs have just never tried Django :D
  - stef25 2mo ago
    Or Laravel's Eloquent
- Klonoar 2mo ago
  Running your API in Rust/Go/etc and then doing the admin and migrations via Django is a hidden superpower. I’ve said this on HN in the past few years.
leetrout 2mo ago
> I still use Django for models and migration There are dozens of us! It's a great db management toolkit. I've used it to much success many times for things like managing migrations from mysql to postgres and php to python. My opinions: - Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries. I will die on this hill. No team is ever disciplined enough to keep apps as boundaries for relationships and constraints. Strong contrast to the rails crowd that doesn't rely on referential integrity in the db by default where this isn't "a thing". - Goose[0] migrations in Go are really great but you have to let go of the dsl and the idea that your ORM drives your migrations, as you explicitly called out. Laravel[1] is on par with django IMO and a delight to use when in php-land. I've not tried to repurpose it like I have with Django and sqlalchemy. - sqlalchemy and alembic is a great toolchain outside of django that get's a bit of a bad wrap / confusion from django devs. it gives you that same ability to drive the changes from the classes / structs without having to drag around all of django. It having more verbose [0] https://github.com/pressly/goose https://github.com/pressly/goose [1] https://laravel.com/docs/13.x/migrations https://laravel.com/docs/13.x/migrations
- pdhborges 2mo ago
  - Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries Totally agree with this. Now we have thousands of unsquashable migrations that require a ton of work to fix.
  - trojans1290 2mo ago
    Can you share more on this? Is it better to keep all models in one app?
    - dotandgtfo 2mo ago
      I found parts of the Django RAPID architecture [0] to speak to me. It specifically advocates for just one app. Here's a part of the justification. > Slicing up your project into apps is something that must be done early, often at the very start of development. This is a simple result of the fact that you need somewhere to put the code you're writing as you go along. In the early days and weeks of work on a new codebase, manage.py startapp gets used a lot, as the high-level structure of the project starts to take shape. > The issue here is that at this early stage, you often don't really know enough about what the project's final form will look like to correctly draw the boundaries around the apps. Functionality that feels separate at first often becomes deeply entangled, and features that sound similar end up sharing little. Over time, the key concepts and models in your system become clear, and if these are colocated with unrelated or irrelevant code, the waters of the project become muddy and maintenance becomes difficult - before the project is even in production! > While it is technically possible to migrate models between apps, Django doesn't make it easy, particularly if the models in question have foreign key or many-to-many relationships with other models. And if you think about it, it's not really a technical limitation of the sort that could easily be solved with a PR into Django. It's a conceptual problem: if migrations are a historical record of changes to models, and migrations are encapsulated in the same app as those models, then moving a model to a different app necessarily creates a historical coupling between the two apps that shouldn't really exist. [0] https://www.django-rapid-architecture.org/structure/ https://www.django-rapid-architecture.org/structure/

by ranedk 2mo ago

0xpgm 2mo ago

I've never done it, but now that you say it, it makes a lot of sense. Using Django just to manage the database and do migrations, even behind other language stacks. You also get the Django admin interface for free. I once tried using SqlAlchemy but I couldn't help asking myself why it felt so complicated compared to Django.

ranedk 2mo ago
People who hate ORMs have just never tried Django :D
- stef25 2mo ago
  Or Laravel's Eloquent
Klonoar 2mo ago
Running your API in Rust/Go/etc and then doing the admin and migrations via Django is a hidden superpower. I’ve said this on HN in the past few years.

leetrout 2mo ago

> I still use Django for models and migration There are dozens of us! It's a great db management toolkit. I've used it to much success many times for things like managing migrations from mysql to postgres and php to python. My opinions: - Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries. I will die on this hill. No team is ever disciplined enough to keep apps as boundaries for relationships and constraints. Strong contrast to the rails crowd that doesn't rely on referential integrity in the db by default where this isn't "a thing". - Goose[0] migrations in Go are really great but you have to let go of the dsl and the idea that your ORM drives your migrations, as you explicitly called out. Laravel[1] is on par with django IMO and a delight to use when in php-land. I've not tried to repurpose it like I have with Django and sqlalchemy. - sqlalchemy and alembic is a great toolchain outside of django that get's a bit of a bad wrap / confusion from django devs. it gives you that same ability to drive the changes from the classes / structs without having to drag around all of django. It having more verbose [0] https://github.com/pressly/goose https://github.com/pressly/goose [1] https://laravel.com/docs/13.x/migrations https://laravel.com/docs/13.x/migrations

pdhborges 2mo ago
- Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries Totally agree with this. Now we have thousands of unsquashable migrations that require a ton of work to fix.
- trojans1290 2mo ago
  Can you share more on this? Is it better to keep all models in one app?
  - dotandgtfo 2mo ago
    I found parts of the Django RAPID architecture [0] to speak to me. It specifically advocates for just one app. Here's a part of the justification. > Slicing up your project into apps is something that must be done early, often at the very start of development. This is a simple result of the fact that you need somewhere to put the code you're writing as you go along. In the early days and weeks of work on a new codebase, manage.py startapp gets used a lot, as the high-level structure of the project starts to take shape. > The issue here is that at this early stage, you often don't really know enough about what the project's final form will look like to correctly draw the boundaries around the apps. Functionality that feels separate at first often becomes deeply entangled, and features that sound similar end up sharing little. Over time, the key concepts and models in your system become clear, and if these are colocated with unrelated or irrelevant code, the waters of the project become muddy and maintenance becomes difficult - before the project is even in production! > While it is technically possible to migrate models between apps, Django doesn't make it easy, particularly if the models in question have foreign key or many-to-many relationships with other models. And if you think about it, it's not really a technical limitation of the sort that could easily be solved with a PR into Django. It's a conceptual problem: if migrations are a historical record of changes to models, and migrations are encapsulated in the same app as those models, then moving a model to a different app necessarily creates a historical coupling between the two apps that shouldn't really exist. [0] https://www.django-rapid-architecture.org/structure/ https://www.django-rapid-architecture.org/structure/