Escreva bibliotecas em vez de serviços, sempre que possível
Os defensores de “bibliotecas em vez de serviços” argumentam que entregar código que os usuários podem executar por conta própria lhes dá controle sobre atualizações, evita quebras surpresa causadas por APIs remotas e reduz a dependência de infraestrutura de terceiros. Outros contrapõem que serviços muitas vezes são mais fáceis de monetizar, observar e operar em escala, especialmente quando há estado compartilhado, bancos de dados ou suporte a múltiplas linguagens. Muitos concluem que a abordagem pragmática é projetar a funcionalidade central como bibliotecas reutilizáveis e, quando necessário, envolvê-las em serviços leves ou ferramentas de linha de comando, com a escolha certa dependendo da arquitetura, da estrutura organizacional e das necessidades dos clientes.
Âmbito de “bibliotecas vs. serviços”
- Muitos concordam com a intuição do artigo: por padrão, opte por bibliotecas; adicione serviços apenas quando necessário.
- Outros argumentam que isso é uma simplificação excessiva e depende do contexto (escala, conformidade, localidade dos dados, tamanho da equipe, monetização).
Falha, atualizações e controle
- Atualizações de bibliotecas só quebram quando o usuário escolhe atualizar; ele pode reverter facilmente.
- Mudanças em serviços podem quebrar clientes no momento escolhido pelo provedor; SLAs e contratos atenuam, mas não eliminam esse risco.
- Alguns veem a migração forçada via serviços como hostil ao usuário; outros dizem que atualizações coordenadas são o trade-off pelo custo compartilhado de desenvolvimento e pelas correções de segurança.
- Ambos os modelos enfrentam dores de versionamento: bibliotecas com muitas versões em circulação vs. serviços com camadas de compatibilidade e APIs versionadas.
Armazenamento de dados e arquitetura
- Uma objeção importante: muitos serviços dependem fundamentalmente de bancos de dados e estado compartilhado; empurrar isso para uma biblioteca transfere operações complexas para os usuários.
- Sugestões: definir interfaces de repositório e deixar os usuários “trazerem seu próprio armazenamento”; usar backends comuns (Postgres, APIs do S3) ou personal data pods.
- Contra-argumento: armazenamento é inerentemente bagunçado (latência, throughput, snapshots, criptografia, tratamento de corrupção); abstrações vazam e a coordenação é ruim.
Dinâmicas organizacionais e escala
- Em muitas empresas, nova funcionalidade por padrão vira um microserviço; bibliotecas são mais raras e mais difíceis de coordenar entre equipes e repositórios.
- Culturas de monorepo às vezes colocam o ônus de atualização sobre os donos da biblioteca, o que desencoraja mudanças quebradoras triviais, mas aumenta o escopo de responsabilidade deles.
- Alguns veem o uso intenso de serviços como um contorno para problemas políticos/de coordenação, e não como necessidade técnica.
Monetização, controle e autonomia do usuário
- Serviços são mais fáceis de monetizar, observar e controlar; bibliotecas são mais difíceis de vender e oferecer suporte, mas dão autonomia aos usuários e evitam lock-in.
- Exemplos citados: dispositivos IoT e produtos SaaS que poderiam ter sido bibliotecas locais, mas em vez disso são serviços recorrentes e com custos opacos.
Orientação prática e abordagens híbridas
- Padrão comum defendido: sempre projete a lógica central como uma biblioteca e depois, opcionalmente, embrulhe-a como:
- Um serviço fino (HTTP/gRPC etc.).
- Uma CLI no estilo Unix que lê/escreve dados estruturados.
- Heurísticas: lógica pura/algorítmica → biblioteca; componentes ligados a armazenamentos de dados privados, estado compartilhado pesado ou infraestrutura especializada → serviço.
Confusão terminológica
- Vários comentaristas acham a definição ampla de “biblioteca” do artigo (qualquer software executável pelo usuário) confusa em comparação com o sentido usual de “dependência não executável”.