O que eu adoro no Django

Artigo original ↗ Discussão no Hacker News ↗

O Django surge como um framework web amplamente admirado por sua estabilidade, compatibilidade retroativa de longo prazo, ORM poderoso e recursos integrados como a interface admin e uma documentação robusta. Comentadores destacam como sua evolução “chata”, incremental, reduz retrabalho e o torna bem adequado para produtos grandes e duradouros, sem deixar de oferecer saídas de escape para SQL cru, arquiteturas alternativas ou serviços externos. As críticas se concentram no ORM no estilo Active Record (e sua tendência a consultas N+1), nas limitações de async e desempenho, na complexidade de implantação em comparação com stacks serverless e em filosofias diferentes das de frameworks como Rails, FastAPI e Phoenix.

Sentimento geral

  • Muitos comentaristas são muito positivos em relação ao Django: “bem projetado”, “chato no bom sentido” e produtivo para aplicativos pequenos e grandes.
  • Um tema recorrente é a estabilidade de longo prazo: projetos de vários anos e até várias décadas foram atualizados entre versões principais com quebras mínimas.

Pontos fortes centrais apontados

  • Sem mudanças dramáticas: evolução lenta e cuidadosa é muito valorizada em comparação com frameworks que forçam reescritas.
  • ORM + migrations: amplamente elogiados por potência e flexibilidade; conseguem expressar SQL complexo e têm saídas de escape para SQL cru.
  • Admin: muitas vezes “vende” o Django para clientes e é reutilizado como back-office interno ou inspetor de dados.
  • Flexibilidade: visto como opinativo, mas não rígido; é fácil sobrescrever comportamento, customizar roteamento, usar Jinja2, plugar outros ORMs ou dividir responsabilidades com outros serviços (por exemplo, APIs em Rust com Django para migrations/admin).
  • Ecossistema: DRF + OpenAPI + geradores de TS, django-allauth, ferramentas de arquivo único e frontends em Rust como django-bolt recebem elogios.

Pontos problemáticos e críticas

  • ORM/ActiveRecord:
    • Críticas: incentiva consultas “em todo lugar”, problemas fáceis de N+1, carregamento implícito amplo, padrão ActiveRecord desagradado por alguns; sintaxe como field__gte e relações fortemente baseadas em strings são chamadas de feias / frágeis.
    • Defesas: N+1 pode ser tratado com select_related / prefetch_related, próximos modos de fetch e disciplina. Alguns veem as reclamações como questões de “habilidade/encaixe”.
  • Arquitetura e estrutura dos apps:
    • Preocupações com spaghetti vindo de consultas entre apps, models.py / views.py enormes e falta de camadas de serviço claras.
    • Outros defendem camadas explícitas de serviço/seletor, signals para desacoplamento e apps centrais/agregadores em formato “estrela”. Signals são vistos como poderosos, mas arriscados por terem efeitos colaterais ocultos.
  • Content Types: impressionante, mas com alerta contra seu uso para manutenibilidade de longo prazo.

Comparações com Rails e política

  • Alguns preferem Django ao Rails por motivos técnicos (menos “Rails Way”, mais flexível).
  • Um tópico lateral discute evitar Rails por causa das visões públicas de seu criador; outros argumentam pela separação entre software e política do autor, ou observam inconsistência em boicotes seletivos.

Async, desempenho, implantação

  • A história de async e o desempenho de alta vazão são citados como pontos mais fracos; alguns migram para Go ou outras pilhas por isso.
  • A implantação é vista como mais difícil do que frontends estáticos/microsserviços porque o Django precisa de um processo de servidor 24/7.