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.
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
Yes, you can do the whole web app (or web site if you will) like that without any complicated dependencies. This will be great if you touch the project only now and again e.g. the typical side project that you want to still work in the year 2030 without major changes.
Yet the approach also scales up to enterprise grade project, leveraging DRF, Django-cotton and so on (and htmx).
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 ;)
Is Groovy/Grails still popular? I also remember Groovy++ but I believe its features were incorporated into Groovy. But maybe these are already present in modern Java?
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.
It's brave trying FastAPI if you haven't tried it before. Going async is going to be quite different and you need to be more careful when designing your API. Most people will never need it.
This is why most folks just needing a plain Python API without anything else, they usually go for Flask, which is vastly simpler. For a more complete web app or site, I would recommend Django.
The ORM is so so so much better designed that SQLAlchemy v2. Performing queries, joins, executing in transactions all feels clean and concise. The latter feels dated and I find it hard to believe there's not a widely accepted replacement yet.
In terms of views, route configuration and Django's class-based views are sorely missed when using FastAPI. The dependency pattern is janky and if you follow the recommended pattern of defining your routes in decorators it's not obvious where your URL structure is even coming from.
We could probably do with a "SQLAlchemy for Django users" article. SQLAlchemy is much more powerful and flexible than Django. After using SQLAlchemy it's hard to even consider an active record style ORM like Django an ORM at all. SQLAlchemy can truly map relational data onto objects and uses the unit of work pattern to coordinate updates. Django just feels like writing raw SQL but in nicer Python syntax. The details of relational models leak directly into the business logic and there isn't really much you can do about it. In short, SQLAlchemy is a different beast. If all you need is Django then you're probably only doing CRUD and you should just use Django.
Django definitely wins at CRUD because that's what it is. It calls itself a web framework but really it's a web-crud-app framework. Flask and Pyramid are web frameworks.
Dealing with the session object seems a small price to pay for the flexibility in architecture that it gets you.
My only criticism is that die-hard django devs constantly brush aside the admin and can't stop telling people not to use it. I think it's a huge mistake.
It's extremely well-designed and extensible, there is no reason to reinvent the wheel when so much time and effort has been put into it.
They will complain of things like "eventually you will have to start over with a custom solution anyway"... but whatever gripes they have, could just be put into improving the admin to make it better at whatever they're worried about.
Personally I've not run into something I couldn't make work in the admin without having to start over. My own usecases have been CRUD for backoffice users/management and I've had great success with that at several different companies over the last ~15 years.
People will say "it's only for admins you trust" yet it has very extensive permissions and form/model validation systems heavily used in the admin and elsewhere, and they are easily extensible.
I use the heck out of the admin. I wouldn't say I'm super experienced with Django, but my solution to users being overwhelmed by doing things there is to build a bit of extra UI just for the stuff they need to do, more Rails style. Meaning: I don't go into fighting too much with the admin when what it can do out of the box is not feasible for some. But even if the admin ends up being used only by devs and some trained folks, I think it has amazing utility.
LLMs are experts at Django, as there's 20 years of training data on it as well as just being written in the world's most popular language. LLMs can pump out full featured Django sites like anything.
I don't know why anyone would use any other framework.
We've used (and continue to use) Django for bespoke applications for a decade and a half now. It continues to be the most well-supported, well-governed, well-documented, batteries-included, extensible web framework of all the ones we've tried. Finding developers with experience using it (or upskilling them) is easy. As a choice of web technology, it's one of those that we've never regretted investing in.
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.
Works great, I've been using it in production for a few years. DRF was one of my least favorite bits of the Django world and Ninja has been an excellent alternative.
I still love Django for greenfield projects because it eliminates many decision points that take time and consideration but don't really add value to a pre-launch product.
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.
next.js + TS for front ends, C# for pure back-end services. Golang was a close second but we have some team experience with C# and like it's lack of ecosystem fragmentation, as that was another gripe we had with Python. The Dapper "micro-orm" is also refreshing after years of struggling to make Django's ORM do the right thing.
The threshold is arbitrary, and likely higher in reality. But we found that we want something with more sound type checking and mypy has lots of rough edges. The Python ecosystem has a lot of catching up to do here.
Idk if it's best practice, but I usually like to make apps similar to components, where I have an app for accounts which handles user accounts, and a files app which handles all the dimension and fact tables around user uploads, and a social app for social features, etc.
It makes it easy to compartmentalize the business logic in terms of module imports.
This sounds similar to a modular monolith design. But you have to be careful not to directly import things between apps and especially not to make foreign keys between the models of different apps. We ended up doing that and just wishing it was one big app.
Modular monolith is a good idea and if you want to do it in Django then make small apps that just expose services to each other (ie. high-level business functions). Then have a completely separate app just for the UI that uses those services.
Yeah. I was thinking a modular monolith since it's a django project, and I think that's django's sweet spot since it comes with so many things bundled.
For a true modular design I'd probably step away from django to a less comprehensive framework or just write in golang.
A composite is a structure of many pieces that work together.
Thus, a composite monolith is this arrangement of components in a way that they work together as a monolith. Separate modules, but working together as a single thing.
That's the same as what people are calling a modular monolith, no? The key thing with composition is the bits sit next to each other, there's no inheritance or dependencies between the components. In my idea you'd have a bunch of "pure service" apps that are focused on individual areas of the business or processes. Then you'd have one or more UI apps (either user-facing HTML or APIs) that compose those services to do what needs to be done, e.g. a "create order" endpoint might compose the create order service from fulfilment and the send notification service from comms to put an order on the fulfilment backlog and send notifications. Is this what you had in mind?
That sounds to me like good old "replaceable parts oriented programming".
Replaceable parts can have inheritance, but often what is good about them is the composability. Each part can connect to each other in different ways. We call these boundaries "connectors".
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.
Would love to hear an honest discussion of why Django and/or Python is a bad solution for any given problem. Is it because they are old technologies? Do they lack support for something in particular? Are they too expressive/not expressive enough?
- Imports are a mess
- No control of mutation in function signatures, and in general it's still a surprise when things mutate
- Slow
- Types and enums have room for improvement
You just need to work around those and get used to it. Then you can build nice Python projects that keep growing - but Django really helps you do that. Python however is always going to be "10-100x" slower than something like an API written in Go, Rust and so on. That's fine in most cases.
