12
Reaction/comments to Cloudflare CTO's question on why no ones's using Django (zyke.social)
submitted 4 months ago by to c/python@programming.dev
20 comments fedilink hide all child comments
 

I think I get why Cloudflare's CTO is asking this question.  personally started using Django for backend development, boy, that thing is robust and cool, esp...

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 4 months ago (8 children)

Does Django support async now? I remember that it was supposed to come with Django 4.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 2 points 4 months ago* (6 children)

    That's the other part that's a bit problematic. There is some async support, but ORM calls, to my knowledge, are still blocking. There has been some effort put into it, but I'm not sure they'll manage to reimplement it. Other parts of the framework and third party middlewares are blocking too, which makes writing async Django a bit of a minefield.

    There needs to be a non negligible amount of work to make sure a given request remains asynchronous across all layers today.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 4 months ago (4 children)

    That's a pity.

    One of the biggest things I miss about django is its ORM. There is simply nothing better in my opinion. It allows me to think about the application I want to write, not about all the database nonsense and how to join tables, make unions, or aggregate stuff, etc. I have to reevaluate if async is that important to me or not. Every other solution without a similar ORM feels inferior.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 4 months ago* (last edited 4 months ago) (2 children)

    There is simply nothing better in my opinion.

    Possibly SQLalchemy? But yeah, it's quite good, and there are ways you can bypass the Django ORM and write your own SQL in the cases where it's suboptimal. I've only had to do that a very small number of times during the 20-plus years I've been using Django (I was an early adopter, left Zope like a .38 round leaves a gun).

    It also helps that I have some decent SQL optimization skills: when I was doing consulting, I triggered the resignations of two client DBAs because they insisted that there was no way to significantly improve a query's performance, then I did it. Stupid hill to die on, all they had to have done was to have said "OK, let's prototype it and see" instead of getting all dogmatic about it. Ego's a dangerous thing in software development.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 4 months ago (1 child)

    SQLalchemy is horrible, IMO. You have to read so much of its documentation to get a grip on things. And the backwards compatible changes they made while moving to (I think) SQLAlchemy2 make it terribly difficult to tell apart the API. And type hints were an abomination to deal with when they tried adding them (it's better now).

    And don't get me started on migrations with alembic.

    I wish the Django ORM could be extracted from Django and used in other projects, but then I also just want to go back to Django.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 3 months ago* (last edited 3 months ago)

    Reply to /u/onlinepersona SQLAlchemy crocodile tears.

    Really need a layer between SQLAlchemy and FastAPI (or litestar, ...). Otherwise would be messing around with SQLAlchemy/alembic internals for years. SQLAlchemy is an incredible time sink without that additional layer.

    Created just such a package just never got around to publishing it:

    • static type checking throughout
    • sync and async support throughout
    • alembic support (both async and sync)
    • multiple databases. One per config file!
    • model built from dotted path of (sqlmodel and sqla mixins) components module
    • UDF (user defined functions)
    • database settings (PRAGMA, SHOW, SET, ...)
    • sqlite-[pysqlite|sqlcipher|aiosqlite] and postgresql-[psycopg2|asyncpg] supported
    • config does not store the password

    Issues:

    • retire sqlite-sqlcipher PRAGMA rekey and key. Password in config unsafe
    • authentication by pulling from a password manager not implemented
    • strict validation of postgresql SHOW/SET keys incomplete
  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 3 months ago

    Remember back in the day ... raw SQL. All the children in unison say, "Woah"!

    There is no avoiding the database part: model module, alembic migrations, static type checking, UDF, UDF rtyping, string PRAGMAs/SET|SHOW. And a beautiful config file to link them all!

    Database work is very time consuming.

    have to reevaluate if async is that important to me or not.

    Why would be concerning yourself about that? Should have both [a]sync support throughout. Discussing this shouldn't even be a topic it should be the norm.

  • permalink
  • fedilink
  • source
  • parent