You simply can't beat Django's ORM for general stuff. It's too awesome. This alone makes it so hard to choose anything else.
I know django doesn't have that "shiny factor" to it these days - but it's very reliable.
> mixed messaging on best practices for scalable apps
The WSGI stuff can be kinda confusing and is used across a lot of python frameworks including django and I think flask?
My advice for "simple scaling" is to start with a separate Postgres instance, and then use gunicorn. Use celery immediately if you have any "long lived" tasks such as email. If you containerize your web layer, you'll be able to easily scale with that.
Finally - use redis caching, and most importantly - put Nginx in front! DO NOT serve static content with django!
> the ecosystem feels overbloated with vapor ware extensions.
This still exists to some degree for some more niche stuff, largely because of it's age. Although impressively they'll generally still work or work with minimal modifications. It's popular enough and old enough that most normal things you'd want to do have decent extensions or built in support already.
Not only can you not beat Django's modeling in Python, but I simply cannot find an in-kind solution in JS either. Nothing covers all of the bases the way Django does, or more specifically DRF/graphene-django.
The current state of the art is apparently Prisma, but it covers only a small part of the full picture.
> Use celery immediately if you have any "long lived" tasks such as email
Hey, quick question from a relative newbie who is currently trying to solve this exact problem.
Besides Celery, what are good options for handling long-running requests with Django?
I see 3 options:
- Use Celery or django Q to offload processing to worker nodes (how do you deliver results from the worker node back to the FE client?)
- Use a library called django channels that I think supports all sorts of non-trivial use cases (jobs, websockets, long polling).
- Convert sync Django to use ASGI and async views and run it using uvicorn. This option is super convoluted based on this talk [0], because you have to ensure all middleware supports ASGI, and because the ORM is sync-only, so seems like very easy to shoot yourself in the foot.
The added complication, like I mentioned, is that my long-running requests need to return data back to the client in the browser. Not sure how to make it happen yet -- using a websocket connection, or long polling?
Sorry I am ambushing you randomly in the comments like this, but it sounds like you know Django well so maybe you have some insights.
Use anything except Celery, is my vote. Even if that "anything" is something you roll yourself.
Celery is mature, but has bitten me more than anything else.
For scheduling, there are many libraries, but it's good to keep this separate from Celery IMO.
For background tasks, I think rolling your own solution (using a communication channel and method tailored to your needs) is the way to go. I really do at this point.
It definitive is not using async, I think that will bite you and not be worth the effort.
Django ORM has supported async syntax for some time now, and it can work fully async starting with Django 4.2 (and psycopg3). There are still a few rough edges (such as not being able to access deferred attributes from async contexts) but there are workarounds.
I usually use `asyncio.create_task` from async views for small, non-critical background tasks. Because they run in a thread you will lose them if the service crashes (or Kubernetes decides to restart the pod), but that's fine for some use cases. If you need persistency use Celery or something similar.
Django combined with an async-ready REST framework such as Django Ninja is very powerful these days.
True, but it's the best ORM currently available for any language. It might not be the fastest, but it is the one that's has the highest level of developer comfort.
Using Django is probably the reason why I can stand using SQLAlchemy, it's way to complicated for everything I do and it's just not a nice an experience.
> True, but it's the best ORM currently available for any language.
Such a strong assertion!
I've used multiple ORMs (not Django's), including some of Haskell's type-safe ORMs (e.g. Persistent and Beam). I could not imagine going back. What makes Django's ORM so great?
Depending on what you consider important, and I haven't used Entity since... 2010 I think. For me, those two doesn't compare, the simplicity of the Django ORM makes Entity look dated, complex, like something out of the mainframe era.
Entity is way more flexible, in the sense that you can use in any .Net project really. The Django ORM have no value outside Django, I have yet to anyone use just the ORM, without the rest of the framework.
I know django doesn't have that "shiny factor" to it these days - but it's very reliable.
> mixed messaging on best practices for scalable apps
The WSGI stuff can be kinda confusing and is used across a lot of python frameworks including django and I think flask?
My advice for "simple scaling" is to start with a separate Postgres instance, and then use gunicorn. Use celery immediately if you have any "long lived" tasks such as email. If you containerize your web layer, you'll be able to easily scale with that.
Finally - use redis caching, and most importantly - put Nginx in front! DO NOT serve static content with django!
> the ecosystem feels overbloated with vapor ware extensions.
This still exists to some degree for some more niche stuff, largely because of it's age. Although impressively they'll generally still work or work with minimal modifications. It's popular enough and old enough that most normal things you'd want to do have decent extensions or built in support already.