4 ms·

Async Django is a bit of a puzzle …. who is it for? People who like synchronous Python can use Django. People who like asynch Python can use Starlette - the a

Async Django is a bit of a puzzle …. who is it for? People who like synchronous Python can use Django. People who like asynch Python can use Starlette - the async web server also written by the guy who wrote Django. It’s not clear why Django needs to be async, especially when I get the sense there’s developers who like async and developers who prefer synch. It’s a natural fit for Django to fulfill the sync demand and Starlette to fulfill the async. They’re both good.

senko 2y ago
Starlette and Django are wildly different. Django has a batteries-includes approach, benefits from tighter integration of orm, auth, form handling, etc, and has a huge 3rd party ecosystem. First-class async support in Django allows Django users to avoid jumping through hoops (celery, channels, ...) for longer-running requests, something especially noticable if you're calling any kind of AI service.
- globular-toast 2y ago
  How much of that is relevant if you're going to be using django-ninja (pydantic) and the whole app has to be async, though? Django is fine for writing a thin CRUD layer around a database. It makes the easy stuff easy. But doesn't seem to help much for the hard stuff and often actively hinders it. Really the main reason for Django is its ORM and migrations. It's basically the other Python ORM (next to SQLAlchemy) but, unlike SQLAlchemy, it's not designed to be used standalone. In my experience I find Django (and active record ORMs in general) easier for people to get started with, but massively limiting in long run for complex domains.
  - senko 2y ago
    > if you're going to be using django-ninja (pydantic) This assumes that people don't do multi-page apps or sites any more, which ... isn't true. And I believe django-ninja replaces forms/serialization/deserialization and routing, while nicely integrating with everything else. > Django is fine for writing a thin CRUD layer around a database. In my dozen or so years with Django, I confess I did more than a few thin CRUD layers around a database. But also worked on billing systems for telecoms, insurance provider API services, live/on demand audio/video streaming services, a bunch of business process apps, AI codegen tools, and other web apps and API backends that were way more than thin CRUD layers around databases. Django was rarely a hindrance. In fact, Python being sync-only (or Django not supporting async) was usually more of a hindrance that anything Django specific. > In my experience I find Django (and active record ORMs in general) easier for people to get started with, but massively limiting in long run for complex domains. In my exprience the only situations where Django's ORM doesn't help much is when you have a lot of business logic in your database (views, stored procedures), or the database is organized in a way that's not Django's preffered way. Still works, mind you, just not as great a experience. However, the vast majority of projects I've encountered have none of those. Otherwise, I've found its ORM quite powerful, and easy to drop down to raw() in cases where you really need it (which was maybe 1% on the projects I've worked).
    - bluewalt 2y ago
      > Django was rarely a hindrance. +1 on this. Django scales pretty well when adopting a clean architecture like Django Model Behaviours with mixins. > Otherwise, I've found its ORM quite powerful. Same. In ten years, the only issue I had is with a very complex query that the ORM was not able to write properly. But a workaround existed. I'm currently using FastAPI in a project. It's very enjoyable (especially with a strictly typed codebase) but I have to write lots of batteries by myself, which is not very productive (unless you keep this boilerplate code for future projects).
  - ensignavenger 2y ago
    In what ways has Django been a hindrance in your experience? In my experience, I have never felt that way. When i have used a micro framework, sooner or later I always regret it and wish I had Django. When I use Django, and I needed to do somthing different, I have never had a problem with it getting in the way, I have used alternate ORMs, Raw SQL, I by default use Jinja templates, and many other "non-standard" things with Django. Async has been about the only area where I would even consider anything different in the past.
    - bluewalt 2y ago
      Not a hindrance, but something like not having a typed database, no auto completion over time, can be a real drawback (I know about django-types). Finally, in my opinion, the best reason to not use Django is not the project itself (because it will do the job in 99% case), it's because all you learn is tied to Django. Having learn Pydantic recently was a breed of fresh air, and I would reuse it in lots of projects, not only web projects.
      - ensignavenger 2y ago
        I'm not sure what you mean? Django ORM works with common SQL databases, which are generally "typed"? Auto completion is generally a function of your IDE, and there are certainly IDE's with autocompletion that work well with Python and Django? I agree that Pydantic is a great library... I use it with Django quite often, as Django is a Python Library and it plays very well with other Python libraries like Pydantic.
    - globular-toast 2y ago
      The main problem with Django is where to put business logic. It's actually kinda funny to write it like that, because that's the most important thing if you want to do something that isn't just CRUD. Quick, where would you put a high-level business function that touches multiple models? Where would you put the model-level validation for that? I've seen all of the following: in a view, in a form, in a service-layer function, arbitrarily in one of the models/managers, implicitly in the database schema (just catch the IntegrityErrror!). There are endless discussions online about where to do this. This isn't a good sign. It should be easy. The business logic should be at the heart of an application. But instead we see Django's ORM at the heart. Django models are really limiting and totally tied to the database. You can't even have a model that has a list/set of items without getting into ForeignKeys etc. You can't test any of it without having the database present. Why would I need the database to be there to test business logic?! The point of an ORM is to do object persistence, not to do business logic. So I've seen people do a separate set of ORM models and domain models and then manually mapping between them. This is possible, but it's a whole lot easier with something like SQLAlchemy which is actually designed for that (it's a data mapper rather than active record type ORM). Then there's stuff like django-admin and ModelForms etc. which are the last thing you want if you're doing more than CRUD. Tbh it would be utterly remarkable if Django somehow made this stuff easy. But it doesn't and I find myself wishing I just put in the effort to set up the boring stuff like auth etc. but with a proper architecture.
- coffeefirst 2y ago
  As a long time Django user (haven’t tried async in prod yet) the appeal is to have the full Django toolkit and be able to set something up async _if_ needed. Which is a very Django way to think: lots of tools ready to go, use only what you need.
simonw 2y ago
Minor correction: Starlette was started by Tom Christie who is also the creator of Django REST Framework, but he didn't start the Django project itself. Django having async support means you can use the Django ORM, and the Django request/response cycle, and generally not need to write your async and your sync web code using slightly different APIs.

senko 2y ago

Starlette and Django are wildly different. Django has a batteries-includes approach, benefits from tighter integration of orm, auth, form handling, etc, and has a huge 3rd party ecosystem. First-class async support in Django allows Django users to avoid jumping through hoops (celery, channels, ...) for longer-running requests, something especially noticable if you're calling any kind of AI service.

globular-toast 2y ago
How much of that is relevant if you're going to be using django-ninja (pydantic) and the whole app has to be async, though? Django is fine for writing a thin CRUD layer around a database. It makes the easy stuff easy. But doesn't seem to help much for the hard stuff and often actively hinders it. Really the main reason for Django is its ORM and migrations. It's basically the other Python ORM (next to SQLAlchemy) but, unlike SQLAlchemy, it's not designed to be used standalone. In my experience I find Django (and active record ORMs in general) easier for people to get started with, but massively limiting in long run for complex domains.
- senko 2y ago
  > if you're going to be using django-ninja (pydantic) This assumes that people don't do multi-page apps or sites any more, which ... isn't true. And I believe django-ninja replaces forms/serialization/deserialization and routing, while nicely integrating with everything else. > Django is fine for writing a thin CRUD layer around a database. In my dozen or so years with Django, I confess I did more than a few thin CRUD layers around a database. But also worked on billing systems for telecoms, insurance provider API services, live/on demand audio/video streaming services, a bunch of business process apps, AI codegen tools, and other web apps and API backends that were way more than thin CRUD layers around databases. Django was rarely a hindrance. In fact, Python being sync-only (or Django not supporting async) was usually more of a hindrance that anything Django specific. > In my experience I find Django (and active record ORMs in general) easier for people to get started with, but massively limiting in long run for complex domains. In my exprience the only situations where Django's ORM doesn't help much is when you have a lot of business logic in your database (views, stored procedures), or the database is organized in a way that's not Django's preffered way. Still works, mind you, just not as great a experience. However, the vast majority of projects I've encountered have none of those. Otherwise, I've found its ORM quite powerful, and easy to drop down to raw() in cases where you really need it (which was maybe 1% on the projects I've worked).
  - bluewalt 2y ago
    > Django was rarely a hindrance. +1 on this. Django scales pretty well when adopting a clean architecture like Django Model Behaviours with mixins. > Otherwise, I've found its ORM quite powerful. Same. In ten years, the only issue I had is with a very complex query that the ORM was not able to write properly. But a workaround existed. I'm currently using FastAPI in a project. It's very enjoyable (especially with a strictly typed codebase) but I have to write lots of batteries by myself, which is not very productive (unless you keep this boilerplate code for future projects).
- ensignavenger 2y ago
  In what ways has Django been a hindrance in your experience? In my experience, I have never felt that way. When i have used a micro framework, sooner or later I always regret it and wish I had Django. When I use Django, and I needed to do somthing different, I have never had a problem with it getting in the way, I have used alternate ORMs, Raw SQL, I by default use Jinja templates, and many other "non-standard" things with Django. Async has been about the only area where I would even consider anything different in the past.
  - bluewalt 2y ago
    Not a hindrance, but something like not having a typed database, no auto completion over time, can be a real drawback (I know about django-types). Finally, in my opinion, the best reason to not use Django is not the project itself (because it will do the job in 99% case), it's because all you learn is tied to Django. Having learn Pydantic recently was a breed of fresh air, and I would reuse it in lots of projects, not only web projects.
    - ensignavenger 2y ago
      I'm not sure what you mean? Django ORM works with common SQL databases, which are generally "typed"? Auto completion is generally a function of your IDE, and there are certainly IDE's with autocompletion that work well with Python and Django? I agree that Pydantic is a great library... I use it with Django quite often, as Django is a Python Library and it plays very well with other Python libraries like Pydantic.
  - globular-toast 2y ago
    The main problem with Django is where to put business logic. It's actually kinda funny to write it like that, because that's the most important thing if you want to do something that isn't just CRUD. Quick, where would you put a high-level business function that touches multiple models? Where would you put the model-level validation for that? I've seen all of the following: in a view, in a form, in a service-layer function, arbitrarily in one of the models/managers, implicitly in the database schema (just catch the IntegrityErrror!). There are endless discussions online about where to do this. This isn't a good sign. It should be easy. The business logic should be at the heart of an application. But instead we see Django's ORM at the heart. Django models are really limiting and totally tied to the database. You can't even have a model that has a list/set of items without getting into ForeignKeys etc. You can't test any of it without having the database present. Why would I need the database to be there to test business logic?! The point of an ORM is to do object persistence, not to do business logic. So I've seen people do a separate set of ORM models and domain models and then manually mapping between them. This is possible, but it's a whole lot easier with something like SQLAlchemy which is actually designed for that (it's a data mapper rather than active record type ORM). Then there's stuff like django-admin and ModelForms etc. which are the last thing you want if you're doing more than CRUD. Tbh it would be utterly remarkable if Django somehow made this stuff easy. But it doesn't and I find myself wishing I just put in the effort to set up the boring stuff like auth etc. but with a proper architecture.
coffeefirst 2y ago
As a long time Django user (haven’t tried async in prod yet) the appeal is to have the full Django toolkit and be able to set something up async _if_ needed. Which is a very Django way to think: lots of tools ready to go, use only what you need.

simonw 2y ago

Minor correction: Starlette was started by Tom Christie who is also the creator of Django REST Framework, but he didn't start the Django project itself. Django having async support means you can use the Django ORM, and the Django request/response cycle, and generally not need to write your async and your sync web code using slightly different APIs.