8 ms·

Adding to the pile that agrees with you on django-ninja. It's also worth noting that what Django brings to the table is getting less and less relevant in a wor

Adding to the pile that agrees with you on django-ninja. It's also worth noting that what Django brings to the table is getting less and less relevant in a world where frontend and backend are split. For example, we use django-ninja. As we started using it, we migrated away from allauth and into authlib for authentication, which doesn't have a tie-in to Django. We don't use templates, which means we don't use forms. We're moving away from external django apps because they consistently need to be extended, so we tend to copy the code into our codebase and extend directly. The settings are untyped, which is a PITA; so we replaced them with pydantic-settings: That allows us to use .env files, type them, and we just expose them in settings.py into globals() through a couple lines of code. Our management scripts make more sense as poetry script, so we don't go through manage.py but instead `poetry run <command>`, which is more standardized and doesn't depend on Django. We don't even use the django dev server: In order to be more consistent between production and development, we're using uvicorn in "development" mode as a dev server which works just as well. `poetry run dev` is how we run it. So what does that leave us with? 1. An ORM/data model definition system, which is mostly untyped and the source of many of our issues. This model system also contains weird quirks that have nothing to do with the sql model itself (for example you can't create a UUID field whose default is generated by the db; only in python). This also includes a pretty solid migrations system. 2. The great admin dashboard, which depends on the former. I see the way the wind is blowing. And for #1, we have this now, which we haven't tested yet but makes complete sense: https://sqlmodel.tiangolo.com/ https://sqlmodel.tiangolo.com/ We still need migrations and and admin dashboard. Once we have those, we will likely migrate away from Django entirely and our stack will look like a few prepackaged bits of FastAPI, SQLModel, authlib, and maybe some standardized db tables.

halfcat 2y ago
So you’re living out the trope of reinventing Django but lower quality :-) Maybe ask around about SQLModel. It sounds like the perfect solution, but I’ve never encountered someone that used it and didn’t have the opinion that it isn’t ready for production.
- scrollaway 2y ago
  Why lower quality? Django suffers a lot from having packaged into itself the whole templating and forms systems. It solved a pain point years ago, but it's irrelevant now and it carries that legacy due to backwards compatibility. Furthermore, Django also suffers due to its legacy of being database-agnostic... which was more relevant in a world where mysql was still seen as a serious competitor to postgres; but now, it's more annoying than anything else.
  - halfcat 2y ago
    Backward compatibility is great. Your team needs to learn one thing, and it will work with minor modifications and get security updates until after you’ve retired. SQLModel uses SQLAlchemy, which is database-agnostic. Not sure why this is a problem though. The benefit of the ORM is not being agnostic, it’s in managing schema changes under source control and automatic admin interface. In my experience, the FastAPI-grab-bag always ends in regret, wishing we’d just used Django. It just works, and it has things you don’t even know you’ll need. If you get to the point where Django is the problem, you’re still glad you picked Django because you’ll be able to modify it to suit your needs. It brings convention without being enforced, and it’s pluggable. You can just not use forms (I never have), or templates (I like htpy), or not use the ORM, or use a different ORM. Django is just a request-response handler that’s already thought of everything you might need. If you want the FastAPI/pydantic approach you can use Django-ninja. You can piece together your own car, but you’ll get a lot further if you just pick a Toyota Land Cruiser and drive it for a couple decades.
    - scrollaway 2y ago
      Being database-agnostic is not a problem per se. SQLAlchemy provides highly postgres-specific classes for the databases. The way Django implemented database-agnosticism is bad, because it's lowest-common-denominator which dragged all implementations down with it. They are pulling back from that now with a contrib.postgresql module but it's too late, there's a lot of old cruft now that forced design to be less-than-optimal on postgres. I've done all four approaches on four different startups. Pure Django; DRF+React; FastAPI+React; Django-Ninja+React. The last one is the best, but from my experience, it does seem like SQLModel/FastAPI/React will be the route to go towards, but with some solid libraries to replace the still-useful batteries in Django: Authentication, Administration, Migration.

halfcat 2y ago

So you’re living out the trope of reinventing Django but lower quality :-) Maybe ask around about SQLModel. It sounds like the perfect solution, but I’ve never encountered someone that used it and didn’t have the opinion that it isn’t ready for production.

scrollaway 2y ago
Why lower quality? Django suffers a lot from having packaged into itself the whole templating and forms systems. It solved a pain point years ago, but it's irrelevant now and it carries that legacy due to backwards compatibility. Furthermore, Django also suffers due to its legacy of being database-agnostic... which was more relevant in a world where mysql was still seen as a serious competitor to postgres; but now, it's more annoying than anything else.
- halfcat 2y ago
  Backward compatibility is great. Your team needs to learn one thing, and it will work with minor modifications and get security updates until after you’ve retired. SQLModel uses SQLAlchemy, which is database-agnostic. Not sure why this is a problem though. The benefit of the ORM is not being agnostic, it’s in managing schema changes under source control and automatic admin interface. In my experience, the FastAPI-grab-bag always ends in regret, wishing we’d just used Django. It just works, and it has things you don’t even know you’ll need. If you get to the point where Django is the problem, you’re still glad you picked Django because you’ll be able to modify it to suit your needs. It brings convention without being enforced, and it’s pluggable. You can just not use forms (I never have), or templates (I like htpy), or not use the ORM, or use a different ORM. Django is just a request-response handler that’s already thought of everything you might need. If you want the FastAPI/pydantic approach you can use Django-ninja. You can piece together your own car, but you’ll get a lot further if you just pick a Toyota Land Cruiser and drive it for a couple decades.
  - scrollaway 2y ago
    Being database-agnostic is not a problem per se. SQLAlchemy provides highly postgres-specific classes for the databases. The way Django implemented database-agnosticism is bad, because it's lowest-common-denominator which dragged all implementations down with it. They are pulling back from that now with a contrib.postgresql module but it's too late, there's a lot of old cruft now that forced design to be less-than-optimal on postgres. I've done all four approaches on four different startups. Pure Django; DRF+React; FastAPI+React; Django-Ninja+React. The last one is the best, but from my experience, it does seem like SQLModel/FastAPI/React will be the route to go towards, but with some solid libraries to replace the still-useful batteries in Django: Authentication, Administration, Migration.