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

PARTE 2 - Meta-Repos e Micro-frontends uma arquitetura alternativa a Mono-repos e multi-repos

META-REPO-2

Se você não acompanhou a parte 1 desse artigo, precisará dar um passo atrás, caso contrário não será capaz de compreender esse conteúdo.

Clique aqui e leia a parte 1.

Entendendo as configurações do Meta-Repo

Arquivo .meta

O arquivo .meta é útil para relacionarmos os projetos e seus repositórios git. Assim, é possível gerenciar centralizadamente multiplos repositórios através da ferramenta meta instalada anteriormente.

pnpm-workspaces.yaml

Observe que dentro de cada arquivo package.json existe a chave name que é usada para expor o projeto como se fosse um pacote NPM dentro do workspace. Isso torna possível importar um projeto dentro de outro sem a necessidade de instalá-los realmente como um pacote NPM.

Essa técnica evita as complexidades do versionamento de pacotes.

Veja a imagem abaixo:

package.json

Nessa imagem, em dependencies, duas bibliotecas estão sendo usadas através do contexto do workspace dawn-js-core: workspace:* e dawn-js-ui: workspace:*. Isso só é possível porque os nomes das dependências foram expostos no arquivo .meta da pasta apps.

.meta

É importante deixar claro que essas imagens ilustrativas são de repositórios que não fazem parte do escopo desse artigo. Essa imagens foram usadas apenas para ilustrar a explicação e tornar um pouco mais fácil entender o que está ocorrendo.

Com as configurações que fizemos desbloqueamos importantes vantagens. Veja a seguir.

  1. Reduzimos a complexidade para gerenciar de forma centralizada multiplos projetos git com auxílio de plugins meta que permitem a independência de versionamento de cada projeto.
  2. Conquistamos o compartilhamento de pacotes entre projetos no mesmo workspace eliminando a complexidade de gerenciar versões de pacotes NPM reais.
  3. Eliminamos a necessidade de troca de contexto e abertura de multiplas instâncias do editor de código e terminal, o que melhora muito a DX (Development Experience).

Já temos um meta-repo devidamente configurado e com seus super poderes na capacidade máxima, ja que o extendemos com uso do pnpm-workspace.

Agora, vincule meta-repo-root, meta-repo-main e meta-repo-message a seus repositiórios usando o terminal.

Acesse via VSCode meta-repo-root e adicione as instruções a seguir no arquivo .gitignore.

/meta-repo-main/
/meta-repo-message/
node_modules
dist
build

Acesse o repo no terminal e execute os comandos:

  1. cd meta-repo-root
  2. git remote add origin [email protected]:seu-usuario/meta-repo-root.git
  3. git add -A
  4. git commit "initial commit"

Repita para meta-repo-main e meta-repo-message.

meta-repo-main:

  1. cd meta-repo-main
  2. git remote add origin [email protected]:seu-usuario/meta-repo-main.git
  3. git add -A
  4. git commit "initial commit"

meta-repo-message:

  1. cd meta-repo-message
  2. git remote add origin [email protected]:seu-usuario/meta-repo-message.git
  3. git add -A
  4. git commit "initial commit"

Agora podemos vincular cada projeto dentro do arquivo .meta no diretório apps. Esse diretório é útil para incluir repositórios privados. Já o diretório packages é útil para incluir bibliotecas que serão compartilhadas mais tarde como pacotes npm reais.

Abra o arquivo .meta do diretório apps e inclua a configuração:

.meta

Abra o arquivo package.json do repositório meta-repo-main e garanta que as configurações em destaque estão presentes.

{
  "name":"app-main",
  "type":"module",
  "private":true
}

Faça o mesmo para meta-repo-message.

{
  "name":"app-message",
  "type":"module",
  "private":true
}

Acesse via terminal o diretório apps e execute o comando abaixo:

  1. meta git update
  2. ls

Observe que 2 diretórios foram criados. Isso ocorreu porque o nome dos projetos em package.json estão relacionados aos nomes dos projetos em .meta.

Perceba, que nem no arquivo .meta nem no arquivo package.json existem os nomes meta-repo-main e meta-repo-message identificando ou relaicionando prejetos. Portanto, elimine os repositórios meta-repo-main e meta-repo-message. Adotaremos em diante app-main e app-message.

  1. rm -rf meta-repo-main
  2. rm -rf meta-repo-message

Acesse o diretório apps e execute no terminal o comando:

meta exec "pnpm i" app-message app-main

O comando acima instalará todas as dependências dos dois repositórios.

Podemos iniciar todas as aplicações no meta-repo com um único comando.

meta exec "pnpm start" --parallel app-main app-message

apps executando

Agora basta acessar o navegar para verificar a aplicação funcionando.

Exportando e importando um repositório como módulo via pnpm workspace

Para fins de exemplo, vou demonstrar como usar o pnpm-workspace para importar um repositório como módulo.

O repositório app-message deve ser importado no app-main como se fosse um pacote NPM.

Para conseguir tal proeza basta garantir que as propriedades abaixo estão presentes no arquivo package.json do repo app-message:

{
  "name": "app-message",
  "version": "1.0.0",
  "description": "",
  "sideEffects": false,
  "main": "./src/main.js",
  "type": "module"
}

Encerre a execução do projeto via terminal. Apenas pressione CTRL + C.

Vá para o diretório app-main e via terminal remova a pasta node_modules e o arquivo pnpm-lock.yaml

rm -rf node_modules pnpm-lock.yaml

Abra o arquivo package.json do mesmo diretório e inclua na chave dependencies o repositório app-main assim:

{
  "dependencies": {
    "htm": "^3.1.1",
    "terezzu": "^0.1.8",
    "app-message": "workspace:*"
  }
}

Agora vá ao terminal e execute pnpm i para instalar as dependências.

Para testar se isso realmente funciona, ainda no mesmo repositório app-main, abra o arquivo routes/index.js no VSCode e o modifique-o da seguinte forma:

import manual appMessage

Volte ao terminal e execute o comando abaixo para iniciar o projeto app-main.

meta exec "pnpm start" app-main

appMain

Observe que apesar de ter uma ligeira diferença de estilizaçã CSS o módulo contendo o componente app-message foi importado como se fosse um pacote NPM através do pnpm-workspace e depois renderizado no navegador.

Espero que esse tutorial ajude você a entender um pouco melhor como organizar e simplificar seus projetos.

Chegamos ao fim desse artigo e acredito que você tenha visto o grande potencial dessa arquitetura que combina Meta-Repos, Micro-frontend e pnpm-workspaces.

Para continuar aprendendo a respeito desses assuntos, dê uma olhada nas documentações a seguir:

Carregando publicação patrocinada...
1

Interessante, mas no meu ver mais adiciona uma complexidade maior. No meu ponto de vista normalmente vc nao precisa de monorepo, e quando precisa ele em 90% vai atender sua demanda. Mas hoje na empresa usamos turborepo e tambem alguns monorepo apenas com workspace e atendem muito bem, nao requerendo mais "complexidade". Mas a ideia é interessante.

1

Primeiro quero agradecer por gastar seu tempo lendo esse artigo que escrevi com grande dedicação.

Também quero dizer que discordo de você. Mas, isso não significa que estamos errados.
Apenas possuimos visão distinta.

Uma grande vantagem do meta-repo que observo em relação a mono-repo é a possíbilidade de utilizá-lo como um gerenciador de versionamento centralizado que permite gerenciar os repositórios de modo independente.

Pense no cenário de pipelines por exemplo. Com essa abordagem é muito mais simples tratar características e validações únicas de cada repositório e gerar um build para produção com muito mais eficiência.

Existem artigos interessantes sobre mono-repo que tratam de complexidades geradas pela abordagem.

No link abaixo bons argumentos dos pontos fracos do mono-repo são expostos. São pontos com os quais me preocupo muito. Gostaria de ler sobre?

https://kinsta.com/pt/blog/monorepo-vs-multi-repo/#problemas-com-a-abordagem-monorepo

1

Acho que nao sao ponto de vista diferentes e sim experiencias, talvez no meu cenario nao se encaixe um multirepo e sim monorepo. Eu acho valido a ideia mas nao acho que assim como monorepo isso é uma bala de prata que vai resolver todos os problemas, ckmo comentei antes acho que isso adiciona mais complexidade e precisa ser bem analizado, assim como o monorepo precisa ser validado. Mesma premisa de criar um backend para um micro saas e sair usando microservices e microfrontends sem necessidade, e adicionando complexidade. Multirepo é bem interessante mas depende da necessidade. Nos na empresa ate pensamo em usar mas depois decidimos criar mais monorepos para certas finalidades ( Vendor | UI | Widgets| Aplicacoes ) dado que nem todos os devs poderao ter acesso a certos codigos ( repositorios ) Entao se diminuirmos o escopo fica mais facil de gerenciar. Sobre build e actions nos estamos usando um repo para colocar nossas actions que podem ser chamadas de outros workflows, assim centralizando muito o trabalho de manutencao deaas actions.

1

Concordo com você que não há bala de prata e que temos experiências diferentes.

Também acredito que você conhece muito melhor que eu os desafios enfrentados e vencidos onde você trabalha.

Fico muito grato por conversar comigo a respeito desses pontos. É mais uma grande oportunidade de aprendizado que estou vivendo.

1

Nao acho que sei mais que voce, acho que temos uma experiencia diferente. Sempre bom aprender novos meios e tecnicas. muito valido a discussao valew por compartilhar conteudo interessante :)

1

Hora sabe mais, hora sabe menos.. e eu também sou assim rs...

Isso é normal. É assim que aprendo. Amo quando pessoas sabem mais e podem compartilhar conhecimento comigo.

Muito obrigado CarlosZiegler por me inspirar a ter mais vontade de compartilhar o que aprendo dirariamente com pessoas de excelência como você.