🌐 This article is also available in English. (Link soon)

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 sequras 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.

Foi exatamente passando por essa dor no meu trabalho que decidi criar uma solução para cobrir essa lacuna.

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 da raiz técnica Cache (em inglês) com o sufixo -eiro (que em português denota uma profissão ou alguém que faz algo, como fazendeiro ou pedreiro). O "Cacheiro" é 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.
• Pronto para o ecossistema atual: Já conta com plugins prontos para Sistema de Arquivos (FS) e Amazon S3.
• Roadmap alinhado: Em breve, teremos os plugins para Google Cloud Storage (GCS) e Azure, cobrindo 100% da lacuna deixada pelos plugins 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.json.example config/local.json

# 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.

O que vem a seguir?

Este é apenas o primeiro artigo de uma série onde vamos explorar o potencial máximo do Cacheiro. Nos próximos posts, faremos tutoriais passo a passo de como colocar isso em produção de verdade:

• Parte 2: Como criar e customizar seu servidor de cache usando o plugin de File System (FS).
• Parte 3: Como subir o Cacheiro na AWS integrando com o Amazon S3.

Se você está enfrentando esse problema no seu time hoje, não deixe de conferir o repositório oficial do projeto, deixar sua estrela e, claro, contribuir com feedbacks ou Pull Requests!

Acesse o repositório no GitHub: rerodrigues/nx-remote-cache-server

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!