Replies: 1 comment
-
Olá, nunca passei por isso, geralmente quando o projeto fica um pouco distante do original já fazemos um novo repositório com seu próprio build pipeline e deploy. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Bom dia, comunidade.
Estou com um problema e gostaria de saber se alguém já passou por esse desafio e pode me ajudar com alguma dica.
Temos um projeto frontend em que vários times trabalham em cima da mesma base de código. Meu time começou a desenvolver uma parte do sistema que virou um módulo que pode existir integrado ou não ao restante do sistema. Sendo assim, nosso time gostaria de aumentar a velocidade dos deploys sem precisar esperar o restante dos times nem causar impactos indesejados aos mesmos. Volta e meia, os nossos testes pegam erros relativos a um determinado time que simplesmente barra o progresso de deploy de outros times. Seria melhor evitar que nossos erros impactassem outros sem necessidade.
Idealmente, nosso time ainda poderia se integrar com o projeto central, mas sem precisar gerar uma nova build do mesmo, de forma que o nosso módulo sempre estivesse fornecendo a versão mais recente do código e o projeto central conseguisse carregar a versão correta em runtime.
O projeto atual é um
create-react-app
que agora está usando Vite pra fazer o bundle.Com isso em mente, estou pesquisando algumas alternativas:
Separar o módulo em uma biblioteca: Temos uma lib de design system, mas sempre que a versão dela muda, temos que mudar no projeto principal e gerar uma nova build / deploy. Nosso time quer uma solução que evite esse retrabalho.
Astro: Apesar do nosso "módulo" ser uma aplicação TypeScript, o fato de poder colocar menos Javascript na página e acelerar sua renderização e interatividade, permitir controle fino, são grandes atrativos e descrevem ganhos que eu gostaria de ter no meu projeto, como a arquitetura de ilhas. No entanto, lendo essa página sobre por que usar, não me parece a ferramenta certa pro que estou querendo. Nós não estamos usando SSR então não estou certo de que essa seria a melhor abordagem.
Nx: Possui conceitos interessantes de otimização ao rodar tarefas em paralelo e estratégias de caching. Vi alguns videos no canal do YouTube deles, mas não parece atacar o problema do deploy modular sem mexer na aplicação hospedeira.
Module Federation: Quando vamos pra essa opção, o papo já fica mais próximo dos micro-frontends. Tem o benefício de várias dependências compartilhadas, porém parece que abre uma outra caixa de pandora. E ainda precisaria de buildar a aplicação pai.
yarn workspaces: Essa estratégia me parece mais focada em
monorepo
. Nossa aplicação atualmente se comunica com o backend através de APIs que estão num projeto separado, então não vejo muito progresso aqui.Sei que existem muitas variáveis do problema, mas gostaria de saber se alguém já teve a experiência de acoplar um módulo sem precisar reconstruir a aplicação central para incorporar esse dito cujo.
Eu também li esse post relacionado mas resolvi colocar a discussão com foco mais especificamente no deploy.
Qualquer ajuda é bem-vinda. Obrigado de antemão.
Beta Was this translation helpful? Give feedback.
All reactions