Executando verificação de segurança...
6

Assunto bem delicado né?

Mas sem querer criar polêmica, na minha opinião nós desenvolvedores entramos numa paranóia achando que tudo que desenvolvemos deve ser altamente escalável, usando microserviços, messageria, docker container, banco de dados não relacional, BDD, CleanCode e todas as outras palavras da moda.

Em muitos casos o gargalo da aplicação termina sendo uma peça que poucos falam, o banco de dados, poderia citar aqui vários exemplos, mas focando no Django muitos criticam dizendo ele peca por acessar muito o banco de dados, mas o Django traz o conceito de lazy load, que numa tradução bem superficial seria carregamento tardio/lento, o que traz um reflexo direto quando estamos acessando dados de models através de Foreignkey porque o Django no padrão desse tipo de relacionamento traz do banco de dados apenas os dados do models "pai" e quando chamamos atributos do models "filho" ele vai no banco trazer esses dados.

Se pensarmos pelo lado do banco de dados essa abordagem pode ser boa ou ruim, mas poucos se atentam que o Django possue um comando quando realizamos a consulta dos dados que traz numa única query os dados tanto do pai como do filho, o que evitaria dois acessos ao banco de dados.

Portanto, partindo desse exemplo simples creio que o padrão do Django atenderia sim qualquer tipo de projeto, até pouco tempo a plataforma Cartola do Globo era Django, isso é uma amostra de que essa obcessão por padrões "moderninhos" muitas vezes desvia o foco do que realmente precisa ser tratado.

Novamente, longe de mim querer dizer o que é certo e errado, apesar quiz trazer para o bate papo uma outra visão sobre escalabidade.

1

Muito bom, meu caro! Compartilho do mesmo pensamento sobre o design de software com foco no objetivo final. A dúvida era sobre as possibilidades que temos com o Django e qual é o limite dele em relação à implementação de outras abordagens. No entanto, você conseguiu sanar bem essa dúvida sobre o padrão imposto pelo Django!