Posted by yakkomajuri 22 hours ago
Answer: Because Django doesn't support async by default.
What honest reaction you expect from readers?
It was a three day small task?
Given they used TS and performance was a concern I would also question the decision to use Node. Deno or Bun have great TS support and better performance.
Don't get me wrong, I use Bun and I'm happy with it, but it's still young. With Hono/Drizzle/Zod I can always switch back to Node or Deno if necessary.
"drizzle works on the edge"
    const results = await query`
      SELECT...
      FROM...
      WHERE x = ${varname}
    `;
Note: This is not sql injection, the query is a string template handler that creates a parameterized query and returns the results asynchronously.  There's adapters for most DBs, or it's easy enough to write one in a couple dozen lines of code or less.I'm not sure what additional help you're getting. I'm just not a fan of ORMs as they tend to have hard edges in practice.
Obviously ORMs and query builders won't solve 100% of your queries but they will solve probably +90% with much better DX.
For years I used to be in the SQL-only camp but my productivity has increased substantially since I tried EF for C# and Drizzle for TS.
With an ORM, you can also over-query deeply nested related entities very easy... worse, you can then shove a 100mb+ json payload to the web client to use a fraction of.
Also the overhead of good ORMs is pretty minimal and won't make a difference in the vast majority of cases. If you find a bottleneck you can always use SQL.
However drizzle makes it very very straightfoward to handle DB migration / versioning, so I like it a lot for that.
>I'll preface this by saying that neither of us has a lot of experience writing Python async code
> I'm actually really interested in spending proper time in becoming more knowledgeable with Python async, but in our context you a) lose precious time that you need to use to ship as an early-stage startup and b) can shoot yourself in the foot very easily in the process.
The best advice for a start-up is to use the tools that you know best. And sometimes that's not the best tool for the job. Let's say you need to build a CLI. It's very likely that Go is the best tool for the job, but if you're a great Python programmer, then just do it in Python.
Here's a clearer case where the author was not very good with Python. Clearly, since they actually used Django instead of FastAPI, which should have been the right tool for the job. And then wrote a blog post about Python being bad, but actually it's about Django. So yeah, they should have started with Node from day one.
Sometimes tools are worth learning!
A function to display help, and another old to parse the CLI parameters isn't PhD level coding.
Also nowadays, any LLM friend can quickly generate them.
That is exactly what I am complaining about.
I guess some people like it, but just, ick.
My personal maybe somewhat "stubborn old man" opinion is that no node.js orm is truly production quality, but if I were to consider one I think I would start with it. Be aware it has only one (very talented) maintainer as far as I recall.
Always happy to hear feedback/issues if anyone here would like to try it out. Thanks!