Yes. Still one of the best batteries included web frameworks for creating anything that's more of a website (e.g. E-Commerce) than a web app (e.g. Photoshop). No, you don't need NextJs and friends for everything ;)

Absolutely. For what it does, Django is pretty much the best full stack Python web framework there is. It's also a great way to rapidly develop (just sticking to synchronous, which Django is best at).

One can then later consider spinning certain logic off into a separate service (e.g. in Golang), if speed is a concern with Python.

yes

Just like Python itself, unfortunately yes.

Not in my org. Though we did choose it for _one_ new project recently, mostly because we re-used some code from another Django project we had, and we wanted to lean on some readily available functionality from jazzband libs.

We have a few FastAPI services, but are mostly moving away from Python for projects > 1kloc.

For a complete solution requiring many traditional high-level components like templating, forms, etc, then yes, clearly Django. But for something looking more like a REST API, with auto-generated documentation, I would nowadays seriously consider FastAPI, which, when used with its typed Pydantic integration, provides a very powerful solution with very little code.

I chose Django + htmx and a small amount of Alpine.js for a full-stack software project that is currently being launched. I had zero professional experience with Django (or Python really) before starting. I was able to develop the entire application on my own, in my spare time, and had time left over to also handle infrastructure and devops myself.

I prefer Python and it's web frameworks over Typescript/React because there is a lot more stability and lot less "framework-of-the-week"-itis to contend with. It's much easier to reason about Django code than any React project I've worked on professionally. IMO when you don't have a firehose of money aimed at you, then Python is the way to go

I just rolled a backend using FastAPI and SQLAlchemy and it made me miss Django.

Too much other stuff going on in this app to incorporate Django, but it's still way ahead of the curve compared to bringing together independent micro frameworks.

You bet. Still the easiest (IMO) for websites, perhaps of any language.

If it's the kind of project that is going to run against one PostgreSQL database then I'd probably start a new project with Django just for its database migration support. That doesn't mean everything in the project has to be Django.

The conference coordinators said they would be released in about a month, so I will update the post once they are released! I am really excited to watch them again. Amazingly informative stuff.

And assuming we're not talking v7 UUIDs.. your indexes are gonna have objects you might commonly fetch together randomly spread everywhere.

If you don't have a natural primary key (the usual use case for UUIDs in distributed systems such that you can have a unique value) how do you handle that with bigints? Do you just use a random value and hope for no collisions?

Is it really enormous? bigint vs UUID is similar to talking about self-hosting vs cloud to stakeholders. Which one has bigger risk of collision? Is the size difference material to the operations? Then go with the less risky one.

>Use bigint, never UUID. UUIDs are massive (2x a bigint) and now your DBMS has to copy that enormous value to every side of a relation.

"enormous value" = 128 bits (compared to 64 bits)

In the worst case this causes your m2m table to double, but I doubt this has a significant impact on the overall size of the DB.

Wasn't UUIDs default go to types for primary keys in the .NET/SQL Server world even 20 years ago?

> Never use UUIDs as your primary keys.

This seems like terrible advice.

For the vast, vast, vast majority of people, if you don't have an obvious primary key, choosing UUIDv7 is going to be an absolute no-brainer choice that causes the least amount of grief.

Which of these is an amateur most likely to hit: crash caused by having too small a primary key and hitting the limit, slowdowns caused by having a primary key that is effectively unsortable (totally random), contention slowdowns caused by having a primary key that needs a lock (incrementing key), or slowdowns caused by having a key that is 16 bytes instead of 8?

Of all those issues, the slowdown from a 16 byte key is by far the least likely to be an issue. If you reach the point where that is an issue in your business, you've moved off of being a startup and you need to cough up real money and do real engineering on your database schemas.

I’ll go further; don’t automatically default to a BIGINT. Put some thought into your tables. Is it a table of users, where each has one row? You almost certainly won’t even need an INT, but you definitely won’t need a BIGINT. Is it a table of customer orders? You might need an INT, and you can monitor and even predict the growth rate. Did you hit 1 billion? Great, you have plenty of time for an online conversion to BIGINT, with a tool like gh-ost.

Server side template rendering is popular already and well supported in Django ecosystem