Por que a Azion migrou para pacotes npm individuais

Se você usa a biblioteca da Azion ou já trabalhou com bibliotecas JavaScript em larga escala, provavelmente já passou por isso: precisava de um módulo específico, mas acabava instalando dependências de várias funcionalidades que nem usaria. É justamente esse cenário que estamos mudando.

Foi esse problema, entre outros, que levou nosso time a repensar a arquitetura de nossa biblioteca. Neste artigo, você vai entender por que a migração para pacotes npm individuais é uma evolução importante para a experiência de desenvolvimento, para a performance dos projetos e para a sustentabilidade da biblioteca no longo prazo

O que é a arquitetura de monorepo distribuído da Azion

A Azion está evoluindo de um modelo monolítico para uma arquitetura baseada em pacotes independentes publicados dentro do namespace @aziontech. Na prática, isso significa que cada módulo da biblioteca passa a ter seu próprio ciclo de vida, sua própria versão e suas próprias dependências.

Como funcionava a biblioteca Azion no modelo anterior

Antes, ao instalar o pacote principal com:

npm install azion

Você recebia tudo: storage, SQL, IA, utilitários JWT e outros módulos em um único pacote.

Embora isso parecesse conveniente em um primeiro momento, o modelo gerava diversos efeitos colaterais: instalações maiores, atualizações desnecessárias, mais complexidade no versionamento e pipelines de build mais lentos.

O que muda com os pacotes npm individuais

Com a nova estrutura, você instala apenas o módulo de que realmente precisa:

npm install @aziontech/storage

E importa diretamente o pacote específico:

import { createBucket } from '@aziontech/storage';

Esse modelo torna a biblioteca mais modular, leve e previsível.

Quais problemas os pacotes monolíticos causam

A mudança para um monorepo distribuído responde a limitações reais do modelo anterior.

Versionamento confuso entre módulos independentes

Quando um erro crítico era corrigido em um único módulo, como storage, toda a biblioteca precisava receber uma nova versão.

Isso significava que usuários que utilizavam apenas SQL, por exemplo, viam uma atualização da biblioteca sem entender claramente se aquela mudança tinha algum impacto real no que usavam.

Bloat de instalação e dependências desnecessárias

Quem instalava o pacote azion recebia também dependências de funcionalidades que talvez nunca fossem utilizadas, como:

• Webpack
• esbuild
• ajv e validadores JSON
• mathjs
• e outras dependências ligadas a módulos específicos

Na prática, isso aumentava o tamanho do node_modules, elevava o tempo de instalação e criava fricção especialmente em ambientes com restrições, como aplicações serverless.

Atualizações desnecessárias para parte dos usuários

Se uma dependência do módulo builder fosse atualizada, todos os usuários da biblioteca eram impactados, mesmo aqueles que nunca utilizavam esse módulo.

Isso criava um fluxo de manutenção menos eficiente e fazia com que o custo de atualização fosse distribuído para toda a base, independentemente do uso real.

CI/CD lento e ineficiente

Em um pacote monolítico, qualquer alteração em qualquer módulo exigia build e testes completos da biblioteca inteira.

Isso trazia efeitos claros:

• pipelines mais lentos
• maior consumo de recursos em CI/CD
• feedback mais demorado para o time de desenvolvimento
• custo operacional maior

Como os pacotes npm individuais resolvem esses problemas

A solução foi separar cada módulo em um pacote npm independente, mantendo todos organizados sob o namespace @aziontech.

// Antes (pacote único)

npm install azion
import { createBucket } from 'azion/storage';

// Depois (pacotes individuais)

npm install @aziontech/storage
import { createBucket } from '@aziontech/storage';

A mudança é simples do ponto de vista de uso, mas traz ganhos significativos em manutenção, performance e previsibilidade.

Principais benefícios da arquitetura de monorepo distribuído

Versionamento semântico por pacote

Cada pacote passa a ter sua própria versão:

@aziontech/storage@1.5.3  ← Apenas mudanças de storage
@aziontech/sql@2.1.0      ← Apenas mudanças SQL
@aziontech/ai@1.0.2       ← Apenas mudanças de IA

Isso torna o versionamento muito mais claro. Quando você vê uma nova versão, como @aziontech/storage@1.5.3, sabe que aquela alteração está relacionada apenas ao pacote de storage.

Esse modelo respeita melhor o propósito do versionamento semântico: indicar com clareza correções, novos recursos e mudanças quebradas por módulo.

Instalações mais leves e eficientes

A diferença prática pode ser significativa:

• Monólito: cerca de 50 MB com todas as dependências
• Pacote individual: cerca de 5 MB com apenas o necessário

Esse ganho faz diferença em:

• ambientes serverless
• contêineres Docker
• projetos com foco em performance de build
• experiência do desenvolvedor em instalações locais

Dependências Isoladas e Mais Segurança

Se você usa apenas storage, não faz sentido carregar dependências de build ou ferramentas que pertencem a outros módulos.

Com pacotes individuais:

• o pacote de storage mantém apenas dependências de runtime
• o pacote de builder concentra ferramentas como webpack e esbuild
• cada usuário instala somente o que precisa

Isso reduz a superfície de ataque, melhora a relevância das auditorias de segurança e separa melhor dependências de runtime e build-time.

CI/CD Mais Eficiente

No novo modelo, o pipeline pode trabalhar apenas com os pacotes alterados.

Antes: build completo

- compile todos os workspaces
- test todos os workspaces
- release com versão única

Depois: apenas o que mudou

- detectar pacotes alterados
- compilar apenas alterados
- testar apenas alterados
- liberar versões independentes

O resultado é mais velocidade, menor custo de CI e um ciclo de feedback mais eficiente.

Documentação e Changelogs Claros

Cada pacote pode manter seu próprio CHANGELOG.md:, com histórico específico e sem ruído:

@aziontech/storage/CHANGELOG.md
v1.5.3: Corrigido caso de borda na criação de bucket
v1.5.2: Adicionado suporte a nova região

@aziontech/sql/CHANGELOG.md
v2.1.0: Adicionado suporte a transações
v2.0.0: ⚠️ BREAKING: nova API de consulta

Isso facilita a leitura, a manutenção e a tomada de decisão sobre upgrades.

Melhor Tree-Shaking e Bundles Menores

Quando você importa apenas de @aziontech/storage, seu bundler tem mais facilidade para eliminar código não utilizado.

Você não carrega módulos de SQL, IA ou builder quando só precisa de storage. O efeito é um bundle final menor e mais eficiente em produção.

Mais controle sobre as Atualizações

No novo modelo, cada dependência pode evoluir em ritmos diferentes:

{
  "dependencies": {
    "@aziontech/storage": "1.5.3",  // Estável, raramente atualizado
    "@aziontech/sql": "2.1.0",      // Atualizado quando novos recursos vêm
    "@aziontech/ai": "1.0.2"        // Atualizado independentemente
  }
}

Isso permite:

• atualizar apenas o que for necessário
• testar breaking changes isoladamente
• manter versões estáveis em módulos críticos
• reduzir risco em upgrades

Compatibilidade com ferramentas modernas de monorepo

A nova arquitetura também se integra melhor a ferramentas amplamente usadas no ecossistema JavaScript:

• npm workspaces para gerenciamento nativo
• Lerna para versionamento e publicação independente
• TurboRepo para cache e aceleração de build
• Nx para orquestração avançada de monorepos

Isso aproxima a biblioteca da forma como times modernos já organizam e escalam código.

Como será a migração da biblioteca Azion para pacotes individuais

A transição foi pensada para ser gradual e previsível.

Fase 1: avisos, documentação e coexistência

Nesta etapa, a Azion mantém um período de adaptação com:

• avisos de descontinuação no pacote monolítico
• documentação atualizada
• guias de migração
• coexistência entre o modelo antigo e o novo

Fase 2: transição completa para o novo padrão

Na fase seguinte:

• os pacotes individuais passam a ser o padrão
• o pacote monolítico recebe apenas correções críticas
• a migração continua de forma gradual, sem pressão para mudanças abruptas

Como a mudança funciona na prática: workflow antigo vs. novo

Workflow anterior com o pacote monolítico

// Instala tudo
npm install azion

// Importa do monólito
import { createBucket } from 'azion/storage';
import { createDatabase } from 'azion/sql';

// Atualiza tudo de uma vez
npm update azion

Novo workflow com pacotes individuais

// Instala apenas o que precisa
npm install @aziontech/storage @aziontech/sql

// Importa de pacotes específicos
import { createBucket } from '@aziontech/storage';
import { createDatabase } from '@aziontech/sql';

// Atualiza apenas o que precisa
npm update @aziontech/storage
npm update @aziontech/sql

O ganho é direto: mais controle. Mais clareza. Menos ruído.

Monólito vs. pacotes individuais: comparativo geral

Por que essa mudança importa para quem usa a Azion

Essa migração parte de uma ideia simples: respeitar a escolha do desenvolvedor.

Nem toda equipe precisa de todos os módulos da biblioteca. E impor um pacote grande e acoplado para quem só precisa de uma funcionalidade específica não é sustentável em escala.

Ao adotar um modelo de monorepo distribuído com pacotes independentes, a Azion passa a operar de forma mais alinhada com práticas modernas do ecossistema JavaScript:

• modularidade
• versionamento semântico mais preciso
• responsabilidade clara por pacote
• melhor escalabilidade da manutenção

Para quem usa a Azion, isso significa:

• bundles menores
• atualizações mais previsíveis
• mais controle sobre dependências
• menos acoplamento entre módulos
• uma experiência mais eficiente no desenvolvimento e no deploy

A migração já está em andamento. E, à medida que ela avança, ficará cada vez mais claro por que esse era o próximo passo natural para a evolução da biblioteca.

Crie já sua aplicação. Faça seu signup em console.azion.com