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

Você está diante de um grande desafio com este projeto. Portanto, é crucial abordá-lo com cautela, mantenha as coisas simples. Não adicione complexidade desnecessária. E se apoie no que você conhece melhor.

Como seu conhecimento é mais voltado para bancos de dados do que para desenvolvimento, é aconselhável abraçar profundamente a programação de banco de dados e definir todas as suas regras de negócio em SQL procedural. Em vez dos padrões comumente sugeridos, eu recomendaria adotar o padrão Data Transfer Object (DTO) e construir uma interface simples para sql que englobem consultas complexas.

Isso se justifica porque padrões como MVC, MVP, MVVM (entre tantos outros) são decisões de arquitetura de software que se baseiam essencialmente na separação entre a representação da informação (modelo) e a apresentação para o usuário (visão), o modelo é a essência da sua aplicação, e muitos desenvolvedores web não compreendem plenamente essa importância. Ao focar na construção de um modelo de dados robusto e na utilização, você cria uma base sólida para sua aplicação. Isso permite que você mantenha a flexibilidade na camadas superiores e escolha as ferramentas que melhor complementam suas habilidade e atendam suas necessidades.

Lembre-se de que muitos dos frameworks web são implementações de padrões como MVC, MVP, MVVM, oferecendo um fluxo de trabalho coeso para conectar visualizações a modelos, com um ORM sendo parte de quase todos eles. Contudo, como você já criou seus modelos sem a necessidade desses frameworks, é preferível continuar evitando-os. Um microframework pode ser útil, especialmente para o roteamento, mas talvez seja mais benéfico utilizar recursos nativos do próprio Apache ou Nginx.

Sua visualização deve ser composta por templates PHP simples, com JavaScript minimalista para buscar conteúdo dinamicamente e evitar redirecionamentos. Evite transferir JSON e, em vez disso, opte por HTML gerado diretamente no servidor. Ao adotar uma abordagem semelhante a uma aplicação SPA, você simplifica a lógica do backend e mantém o estado do cliente no próprio cliente. Ao mesmo tempo, ao usar HTML diretamente, você evita complicar seu frontend com frameworks próprios e JavaScript complexo para lidar com o DOM. Essa abordagem representa o melhor dos dois mundos e deveria ser óbvia para todos que estudaram o padrão cliente/servidor, outro padrão clássico que muitos desenvolvedores web negligenciam.

Outra padrão de projeto muito vezes renegado é gerar páginas estáticas sempre que o modelo mudar, em vez de depender de renderização baseada em requisições. Isso não é apenas mais eficiente, mas também pode simplificar significativamente sua arquitetura.

Mantenha sua aplicação o mais simples possível. Evite microserviços, mas abrace módulos e crie várias miniaplicações que funcionem bem juntas, em vez de uma única aplicação gigante. Considere usar soluções de terceiros, como Keycloak, para gerenciamento de autenticação e autorização SSO. Isso ajudará a manter sua aplicação simples e direta.

Em resumo, na sua posição, é isso que eu faria, depois de décadas de experiência com desenvolvimento web. Essas não são apenas algumas ideias aleatórias, mas sim uma abordagem baseada em práticas estabelecidas, que ao mesmo tempo incorporam as últimas tendências e tentam manter a simplicidade.

Estamos falando de uma abordagem baseada no MVC, com DTOs fazendo a ponte entre o Modelo e Controle e Modelo e View, que abraça os principais padrões da web - SSG, SSR, e SPA:

  • Modelo (SSG): Reconstrução automática do site a cada mudança no modelo de dados, utilizando técnicas como pg_notify em triggers do banco de dados. Esta abordagem permite que o site seja atualizado de forma eficiente sempre que os dados são modificados.

  • Visualização (SSR): Utilização de PHP para reconstruir o HTML do site a partir das mudanças do modelo. Aqui, você pode (e deve) integrar scripts Python, se necessário, para complementar a lógica de negócios. Os Data Transfer Objects (DTOs) entram nesta fase, proporcionando uma ponte eficaz entre o modelo e a camada de visualização.

  • Controle (SPA): Para a navegação e interatividade, adota-se uma abordagem SPA-like, utilizando JavaScript e uma configuração adequada do Nginx. Esta configuração é responsável por gerenciar a interação do usuário e servir o conteúdo gerado na etapa de visualização. Para requisições post (put, etc), novamente DTOs funcionam como uma ponte entre o controle e o modelo.

No entanto, é importante ser cauteloso, pois este caminho pode não ser o melhor para você. Uma abordagem muito flexível como esta permite uma grande margem para erros – e eu sei por que eu mesmo já cometi vários. Usar um framework que limita essa flexibilidade pode ser benéfico, pois evita certos erros. Portanto, talvez você esteja melhor servido usando algo como o Laravel ou Django ao invés de seguir qualquer uma das sugestões que eu dei aqui. Ha! Mas, independente das ferramentas e abordagens que você escolher, espero que pelo menos tenha te convencido a passar longe dos ORMs.

Um abraço e bons estudos!

Carregando publicação patrocinada...