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
In go, for my personal projects only I don't think it would scale, I made my own migration tool since I am not using an ORM. It works pretty well for my use case and is quite simple.
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.
Well whether it's better or worse depends on your specific situation.
What I'm facing right now is a 10 year monolith modularized with applications. Like a sibling comment already discussed these applications are not reusable application so almost all advantages of having that are moot.
Now, the consequence of having this structure is that we now have complex dependencies between the migrations of these apps i.e. cyclic dependencies, dependecy constrains that are underspecified. Thousands of migrations that now take a significant amount of CI time. We would like to squash them but it requires a lot of review and manual work and if we keep using multiple apps we are going to ave the same problem in the future.
The only meaningfull gain we had with multiple apps is that we have less migration conflicts when people create migrations concurrently.
Is that advantage worth the pain? I don't think so.
We have a distributed monolith that's 20-30 years old, that has various systems written in various different languages interacting with multiple interconnected databases. We're working on migrating all of it to python, using django models.
The key thing in a system like this, that was kind of stumbled upon by previous devs who started the python migrations, is the database should be treated as its own independent unit and managed separately from the individual applications that connect to it. For example, we've defined the django models in an independent library that the individual applications import. It also contains the configuration for routing queries to the different databases - only takes a couple of lines of boilerplate in the application's settings file.
We haven't yet switched to using django migrations and are still doing updates manually, but after some work the past couple of years it would now be an option. They would go in the common library, avoiding the pain points you've listed, and could be run from any application that needed it - django tracks the migrations that were run inside the database so they'd all see the same thing and act the same way.
Not the author, but I no not understand the desire to use multiple apps. I am never going to want to carve one out as a separate module I re-use in another product. It is all interconnected, why add arbitrary boundaries separating them? Put everything into a "core" app and move on with life. Maybe if you are an enormous organization working on Instagram where you have rigid responsibilities per team.
So you’d prefer one file with all models? Do you break out into apps for business logic? Keep models in one app/file. Then domain driven design elsewhere?
You don't have to put all your modules into a single file. You can break them into multiple files and the import them into a model file just so that Django loads it from the expected location.
Instead of apps you can just split your components inside a single app using regular python modules.
You can do a more sophisticated module layout, but essentially something as straightforward as the above, all under a single "core" application. Prevents Django from fighting you when you want to work across the arbitrary "app" boundary.
You may want to elaborate that Django apps are mini apps inside of the Django app (which is called "project"). Those unfamiliar to Django might think of a Django project as an app.
- many controls are now functions/variables (that's good!), and some change name, for example `{% csrf_token %}` -> `{{ csrf_input }}`
- calling methods without parenthesis does not work (that's good!), for example `query.all` -> `query.all()`
- in tests` response.context` is replaced by `response.context_data`, which is not set when calling `render` directly (need to return a proper `TemplateResponse`)
- template folders need to be renamed from `templates` to `jinja2`; there may be a way to change this behavior, but i did not find it, and this change is written so small in the docs i lost an entire day over it
Yea, I was unclear. That's what I meant by "you can't mix them"... just meant using jinja2 is drop it for the backend.
I believe you just set the dirs property in the backend config to look in whatever directory / directories you want it just defaults to jinja2 as you discovered.
From what i understand `DIRS` is only for the top-level app. I couldn't find a way to apply it to inner apps (eg. `auth`, `order`, `etc`). I'd be happy if you know the way i don't have to rename all the template folders!
For now, no. But to be fair, it hasn't reached prod yet. So far, only great upsides: developer experience (in templates) is considerably better, and djlint/j2lint make it even better (one for HTML validation through the templating, the other for jinja syntax).
Also, it should be considerably faster to render, but i haven't properly measured yet. I just know on lower hardware, the django template "static" homepage (rendered, but no conditionals and no DB calls) takes average 23ms to serve with variations 14-53ms, while a real static page takes 3ms average with 1-6ms (that's all on localhost so no network instability is measured). Can't wait to have the jinja stats!
I was prescribed modafinil earlier this year and it worked well when I took it but it was intense at the useful dose so the doctor put in for a sleep study. It was a 3 month wait but I am finally getting it done next week an I'm hopeful it leads to a conclusive diagnosis.
I also noticed my issues were worse after my 3rd bout of covid :-/ I had very high sensitivity to alcohol and caffeine after the 2nd bout and have largely cut both out of my life (I never drank more than 20 drinks / year in my life anyway).
> The situation is so dire that even Netflix’s biggest new series of the second quarter failed to get renewed.
And all the other numbers tie back to this. No one wants to invest in a story that ends on a cliffhanger to not be renewed or even worse to get season 2 that is >50% filler because the writers save up for 5 seasons and then season 2 ends on a cliffhanger to never be renewed.
It's all got too much sprawl and poorer production value now. Good riddance
It is an amazing fumble from Netflix. I thought Reed Hastings actually understood the space pretty well back when he somewhat famously said (paraphrasing) "We have to become HBO faster than HBO can become Netflix" and pivoted to making content.
They've been making content now for a long time, Lilyhammer came out in 2012.
They had all the data telling them that long lived series that built dedicated followings like The Office, Friends, Star Trek, etc. were reasons that people stayed on the platform.
They had 14 years to put together their own dynasty series, shows that people could connect with over the years that would become their comfort shows that they could return to again and again, fully owned by Netflix and completely locked in their walled garden.
Instead they pursued a strategy of starting a thousand promising ideas but if they didn't instantly take off, done. No room for a show to grow and mature and develop, you better have a great first season and you might get a second.
And I think everyone I know has at least one show on Netflix that they got invested in only for it to get axed with a dozen unresolved story threads. I think the one that made me go "why bother?" was Santa Clarita Diet. A funny dramatic show with star power, Drew Barrymore and Timothy Olyphant, interesting character development, a 3 season run and then just killed.
It wasn't the first series they killed with a dozen loose threads dangling, but it was the last one I watched. At first I told myself, "I might watch another series after it goes the distance and I know they won't just leave it half-finished" but that quickly just turned into "I don't watch netflix produced series" and as they lost more and more of their licensed content "I don't watch netflix" and this month I realized I was still handing them nearly $30 a month for nothing and canceled.
I think about a lot of the most popular shows and how bad their first seasons are. But audiences like to see characters grow and that's a big part of what causes people to connect with a show and want to come back to it again and again.
The ‘replace creatives with AI’ industry started with Netflix years before we called it AI, and they’re going to see their shares fall further when the market realizes they’ve been sold a false front. Their growth curve was built up on a lie about curation, revealed as such at last by their own metrics, and I’d put my bet on Netflix taking itself private somehow rather than admitting how badly they’ve misjudged customer patience for expensive mediocrity.
HBO’s priority was to tell excellent stories with big budgets and charge slightly more than average.
Netflix’s priority was to tell stories excellently with big budgets and charge as much as was necessary to accelerate growth in revenue y-o-y.
HBO was really damn good at picking great stories to show us. (Maybe not so great at winding them up before they jump the shark, but we have the trope because humans suck at that universally.) Netflix seemingly believed in its recommendation algorithm so strongly that they let it pick stories for them — but most recommendation engines wear thin, and trying to make a movie from ‘Latinx Moody Deadpan’ or ‘Cooking Biography 4K’ only works so many times before viewers realize that the content is just like the recommendations: a ‘false front’ designed to make Netflix seem like it can pick an entire theater full of stories, that wears off rapidly once you exhaust the algorithm’s top picks. Today, I cannot think of any modern flashy topic-generated Netflix thing that is as strong a story as HBO’s Westworld — or Hulu’s Palm Springs. Whatever their flaws, they’re compelling stories, that you can’t just pick out of an algorithm envelope; Netflix’s are, uniformly, not.
Letterboxd exists now as an immune response to this artificial theater, proof that humans are better at picking recommendations given a starting point than Netflix’s billion dollars of algorithms, and that humans are willing to congregate around something made with good taste. It used to be a sign of social status to have an HBO subscription, and now it’s a sign of social status to earn lots of likes on Letterboxd. In both cases, that social status stems directly from the excellence of curation, whether of what movies to make or of what movies to see. For the categories of curation and respect and social signaling, Netflix and The Algorithm doesn’t earn a single nomination.
This was one of the big reasons I quit using Netflix or following new releases. Why bother investing my time into something that's only going to get killed off not because it didn't make money, but because it wasn't profitable enough?
Netflix put me off of TV as a whole category, which is a pretty great thing, really.
Also what really annoys me as a viewer is that even on a good series that has already been renewed, the waiting between seasons has crept up from 1 year (already bad) to multiple years. Then when the new season finally comes out (in two parts!) I already lost most of the context and am not nearly as interested.
The multi-year gap kills my interest. After a huge hiatus, I have forgotten key plot points, so I have to either accept that some elements will not make sense or commit to re-consuming the original season. Both of which are deeply unappealing.
I keep meaning to watch Arcane season two, but the first one was so dense (not necessarily plot, but just so many little things) that I know I would be cheating myself to watch it after the sizeable gap. Yet rewatching S1 just to start S2 is such a time commitment.
I am alone in my peer group for doing something like this.
Cars, student debt, credit card debt all gone. (And I dread needing a new car). Covered downpayment on my house and cash for a nice shed that matches the house and a fence so my kid can play in the back yard with no issue.
Invested low 5 figures into myself taking a year off and now I am getting serious about the 401k at 41. And I am ok with that.
I never worked at a big tech company and I covered my mom's down payment and appliances and new carpet and part of her move for her to move close to me. Dad died when I was 11 so I am all she has and she was a public school teacher so she's on a small pension.
We all walk a different life and I know people that make my entire life savings in a year but I will eventually grow a retirement to get me through 10-15 years and then it will be what it will be. (Maybe a tank of helium and bag)
you piqued my curiosity so I submitted it for indexing on deep wiki (https://deepwiki.com/azpeeen/NEO-Radar) ... surprised to see it was 1.5gb on disk... 700mb on disk of texture images and doesn't look like they've been quantized / compressed so there's some low hanging fruit there.
I know folks on here have a love / hate relationship but I think this would benefit from moving to cloudflare's stack. Current server is completely dead (has a Hostinger IP so they probably took it down from the traffic spike)
Oh we aren't really planning to. This was purely a vibe coding thing for fun. I mentioned I wanted an airport simulator similar to another game we both play. He started vibe coding one. So I started vibe coding one lol. His was in straight up dotnetcore, mine in unity. We got interestingly far but both kind of slowly let it go, they weren't high quality.
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
[1] https://laravel.com/docs/13.x/migrations
reply