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

[Dúvida] Django e Arquitetura Escalável

Acredito que aqueles que tiveram contato com o Django reconhecem que sua arquitetura é bastante rígida, tornando-se excessivamente verbose ao tentar implementar arquiteturas mais escaláveis. Embora não seja impossível incorporar a Arquitetura Hexagonal ou uma Clean Architecture, o Django demanda um esforço considerável para evitar a desorganização do código.

Alguém poderia fornecer orientações sobre padrões e arquiteturas de software que se integram bem ao Django, ou será que a arquitetura padrão do Django é suficiente para projetos com potencial de escalabilidade?

OBS: Dúvida tanto para o Django Web Framework quanto para o Django Rest Framework

Carregando publicação patrocinada...
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!

3

Sobre escalável. Django é escalável. E veja ... "tornando-se excessivamente verbose (...)" isso não quer dizer que não é escalável. Isso quer dizer que você seguindo os padrões impostos pelo Django, que é para justamente você não ter dor de cabeça depois. Isso acontece em qualquer framework parrudo (NestJS, Spring, .NET etc).

Agora sobre o Django Rest Framework (DRF), eu prefiro usar o Django-Ninja, que usa o Pydantic (o mesmo do FastAPI).

3

Django usa arquitetura modular.

Não é uma arquitetura ruim, é a mesma utilizada em diversos frameworks.

Agora se você quer aplicar outra arquitetura não vejo problema.
no fim é só importar os arquivos nos locais que ele provê. Arquitetura limpa e hexagonal está mais relacionado com fluxo de informação do que com organização de pastas. Claro organizar as pastas e arquivos ajuda a manter uma certa consistência.

Infelizmente não tenho nenhum exemplo pra te mostrar.

Quando você fala de escalabilidade o que vem na minha cabeça é infra. Você aumenta a potência da máquina, duplica quantidade de máquinas ou separa em serviços.

Antes de escalar obviamente é preciso de identificar os gargalos, algumas perguntas podem ajudar... Quais rotas estão com lentidão? Quais rotas são mais acessadas? Qual o custo de oportunidade pra melhoria disso?

Com relação a arquitetura do sistema o que pode atrapalhar desenvolvimento de novas features são as interações entre módulos, arquivos com muita informação ou mal organizados.

No que tange esses problemas algumas alternativas tais como criação de sub módulos ou arquivos para tarefas específicas podem ajudar.

No fim quando se tem um sistema robusto/grande o que manda é a consistência entre as informações e suas respectivas localizações.
Quanto mais divergir a equipe nesse ponto pior e mais difícil será manter o sistema.