🌐 This article is also available in English.
Se você trabalha com monorepos usando Nx ou Lerna, sabe que o cache remoto é praticamente um superpoder. A capacidade de rodar um build, teste ou lint no CI (ou na máquina de um colega) e compartilhar esse resultado instantaneamente com o resto do time economiza horas preciosas de pipeline e processamento.
Para ter esse benefício, a solução padrão e oficial é o Nx Cloud. É um serviço fantástico, mas que pode pesar no orçamento de times menores ou esbarrar em políticas estritas de segurança de dados de algumas empresas que exigem soluções self-hosted (auto-hospedadas).
Se você tentou fugir dos custos do Nx Cloud recentemente, provavelmente se deparou com um cenário caótico.
A Montanha-Russa do Cache Self-Hosted no Nx
O histórico de quem tenta hospedar o próprio cache no Nx parece uma novela. No início, a comunidade dependia de ferramentas próprias. Depois, a Nx (antiga NRWL) removeu o suporte gratuito open-source, centralizando tudo no plano pago. Mais tarde, voltaram atrás e lançaram pacotes oficiais e gratuitos para self-hosting (com plugins para File System, AWS S3, Google Cloud Storage e Azure).
E então veio o balde de água fria recente: a Nx descontinuou abruptamente todos os pacotes oficiais de self-hosted cache devido a problemas de segurança (você pode conferir os detalhes na documentação oficial de depreciação do Nx).
A funcionalidade de cache remoto ainda existe nativamente no core do Nx, mas a comunidade ficou órfã de ferramentas oficiais e seguras para fazer a ponte com os storages. Para entender a fundo essa novela, o artigo da Emily Xiong no Medium detalha incrivelmente bem esse histórico das soluções de cache.
E foi exatamente passando por essa situação enquanto estudava maneiras de otimizar meu CI que decidi criar uma solução para cobrir essa lacuna.
Nota de reconhecimento: Apesar das mudanças de diretrizes, fica aqui um agradecimento ao time da Nx por manter a arquitetura aberta o suficiente para permitir que a comunidade desenvolva soluções alternativas.
Apresentando o Cacheiro
O Cacheiro nasceu para devolver à comunidade a liberdade de hospedar seu próprio cache remoto de forma segura, moderna e totalmente gratuita.
E antes que você pergunte: sim, o nome é uma brincadeira! É a junção de Cache com o sufixo -eiro (como em pedreiro ou carpinteiro). O "Cacheiro" é, literalmente, aquele que cuida do seu cache.
Diferente de outras soluções engessadas (opinionated), o Cacheiro foi desenhado como uma biblioteca modular, disponibilizada em pacotes individuais. Você escolhe e acopla apenas o que precisa. Ele é:
- 100% Livre e Open Source.
- Altamente extensível: você pode personalizar a lógica conforme a necessidade da sua infraestrutura.
- Ecossistema 100% completo: Já conta com plugins oficiais e prontos para Sistema de Arquivos (FS), Amazon S3, Azure Blob Storage e Google Cloud Storage (GCS), cobrindo com total paridade a lacuna deixada pelos pacotes descontinuados.
🔒 Segurança em Primeiro Lugar: Como a descontinuação dos plugins da Nx aconteceu por motivos de segurança, o Cacheiro foi construído com atenção redobrada nesse aspecto. O projeto utiliza estritamente as versões mais recentes de suas bibliotecas base (sem vulnerabilidades conhecidas), passou por auditoria de código para mitigar brechas comuns e implementa uma camada de criptografia robusta e resiliente contra falhas de injeção ou vazamento de artefatos.
Como testar em menos de 2 minutos (Exemplo Prático)
Embora o Cacheiro seja uma biblioteca para você construir o seu servidor customizado, o repositório principal já vem com um exemplo funcional pronto para rodar localmente no endereço 127.0.0.1:3000.
Se você quer ver a mágica acontecer agora mesmo na sua máquina usando o plugin de File System (FS), basta seguir estes passos rápidos:
1. Suba o servidor de exemplo
Clone o repositório, instale as dependências na raiz, configure o arquivo local do runner e inicie o servidor de desenvolvimento:
git clone https://github.com/rerodrigues/nx-remote-cache-server.git
cd nx-remote-cache-server
npm install
# Navegue até o pacote do runner e configure o ambiente
cd packages/cacheiro-runner
cp config/local.jsonc.example config/local.jsonc
# Inicie o servidor
npm run dev
Pronto! Seu servidor de cache remoto está rodando no endereço http://127.0.0.1:3000.
2. Conecte o seu projeto Nx ou Lerna
O Nx consegue identificar e usar o cache remoto diretamente através de variáveis de ambiente nativas.
Para o ambiente de produção ou desenvolvimento diário, o ideal é salvar essas variáveis no arquivo de configuração do seu terminal (como .bashrc ou .zshrc) ou configurá-las diretamente nos Secrets / Environment Variables do seu CI (GitHub Actions, GitLab CI, etc.).
Para o nosso exemplo local, configure com o token padrão (change-me):
export NX_REMOTE_CACHE_URL="http://127.0.0.1:3000"
export NX_REMOTE_CACHE_TOKEN="change-me"
Com as variáveis definidas no terminal do seu monorepositório, basta rodar os comandos padrão do seu projeto:
# **Se você usa Nx:**
npx nx run-many -t build
# **Se você usa Lerna:**
npx lerna run build
Execute o comando uma vez para gerar e enviar o cache para o servidor local. Rode uma segunda vez e veja o ganho de performance com o cache sendo servido remotamente pelo Cacheiro. Simples assim.
Se você está enfrentando esse desafio hoje, convido você a conhecer o projeto, deixar sua estrela e contribuir com feedbacks ou Pull Requests!
👉 Acesse o repositório no GitHub: rerodrigues/nx-remote-cache-server
O que vem a seguir?
Este é apenas o ponto de partida. Nos próximos posts desta série, trarei tutoriais práticos demonstrando detalhadamente como configurar e usar os plugins de cada storage para colocar o Cacheiro em produção no seu ambiente de nuvem.
E no seu time?
Como vocês lidam com o cache do Nx hoje? Usam o Nx Cloud, migraram para outra alternativa ou estavam travados sem saber o que fazer após a descontinuação dos pacotes oficiais?
Deixe seu comentário abaixo, conte sua experiência e vamos trocar uma ideia! Nos vemos no próximo post!
Top comments (0)