5 ms·

Non-performant code is going to eventually slip into any codebase. The trick is to monitor for when performance falls to an unacceptable level. Not toss all ORM

Non-performant code is going to eventually slip into any codebase. The trick is to monitor for when performance falls to an unacceptable level. Not toss all ORMs because some minority of generated queries are problematic. If maximum performance, 100% of the time was the end-goal, I would not be writing Python.

DarkNova6 3y ago
The python team I joined grew their codebase from a thin data access layer into a full blown application. Staff was full of data guys and had no idea about application engineering, but lots of opinions. The client was another company who intended the product as heart of their digital transformation. Guess who had to refactor this mess and steer away from catastrophy. I’m haunted to this day.
- fbdab103 3y ago
  That general story can happen with any tech stack. POC whipped together without good architecture. Having proven itself, usage increases until the application starts to burst at the seams. Program must be redesigned, avoiding performance gotchas. I still think Django + the ORM give you a lot of runway before performance should be a concern.
  - DarkNova6 3y ago
    Idk. The python stack strikes as particularly troublesome if you don’t know exactly what you’re doing. There are no guardrails for less experienced devs that prevents you from making basic mistakes. I also realized mid project that the default rest framework doesn’t support good api model generation from OpenApi or vice versa. And most devs didn’t understand why using untyped dicts everywhere was bad. In all transparency, I am openly biased for static typing and have a background in java, c# and Swift. So what we ended up with looked similar to a statically typed language but without the tooling or performance.
    - rattray 3y ago
      Have you tried django-ninja or FastAPI?
      - DarkNova6 3y ago
        No. It was too late to change. We did not have enough test coverage to change the rest framework with full confidence. And the lack of good refactoring support (or static typing) didn't help either.
andybak 3y ago
I agree. Combined with a few good habits like favouring select_related() - it's never been a problem.

DarkNova6 3y ago

The python team I joined grew their codebase from a thin data access layer into a full blown application. Staff was full of data guys and had no idea about application engineering, but lots of opinions. The client was another company who intended the product as heart of their digital transformation. Guess who had to refactor this mess and steer away from catastrophy. I’m haunted to this day.

fbdab103 3y ago
That general story can happen with any tech stack. POC whipped together without good architecture. Having proven itself, usage increases until the application starts to burst at the seams. Program must be redesigned, avoiding performance gotchas. I still think Django + the ORM give you a lot of runway before performance should be a concern.
- DarkNova6 3y ago
  Idk. The python stack strikes as particularly troublesome if you don’t know exactly what you’re doing. There are no guardrails for less experienced devs that prevents you from making basic mistakes. I also realized mid project that the default rest framework doesn’t support good api model generation from OpenApi or vice versa. And most devs didn’t understand why using untyped dicts everywhere was bad. In all transparency, I am openly biased for static typing and have a background in java, c# and Swift. So what we ended up with looked similar to a statically typed language but without the tooling or performance.
  - rattray 3y ago
    Have you tried django-ninja or FastAPI?
    - DarkNova6 3y ago
      No. It was too late to change. We did not have enough test coverage to change the rest framework with full confidence. And the lack of good refactoring support (or static typing) didn't help either.

andybak 3y ago

I agree. Combined with a few good habits like favouring select_related() - it's never been a problem.