DEV Community: Leomar Linhares

Modularização e Microserviços: Quando Faz Sentido?

Leomar Linhares — Thu, 27 Feb 2025 17:13:19 +0000

Recentemente, esbarrei com um post no Reddit de uns dois anos atrás a partir do dia em que escrevo este artigo (27/02/2025).

Prime Video reduces costs by 90% by switching from distributed microservices to a monolith application

Basicamente, ele cita um case de sucesso onde a Amazon Prime Video deixou de usar uma arquitetura de microserviços e voltou para um monólito, gerando uma economia significativa para a empresa.

Acredito que qualquer desenvolvedor sabe que, nos últimos tempos, criou-se uma crença muito forte de que microserviços são uma bala de prata para garantir escalabilidade (eu incluso). Ou seja, iniciar um projeto já com microserviços seria o caminho certo para garantir seu sucesso a longo prazo.

Entretanto, o que esse case da Amazon mostra é que nem sempre isso é verdade — nem mesmo para Big Techs, que geralmente têm muitos recursos, milhões de usuários e, em teoria, deveriam ter uma arquitetura altamente escalável.

Só que microserviços não significam necessariamente escalabilidade. O que realmente dita a escalabilidade de um projeto é a capacidade de modularização dos componentes essenciais para seu funcionamento.

Modularização como Premissa

Independentemente de estar trabalhando com um monólito ou com microserviços, modularizar deve ser uma preocupação constante. Estamos falando de isolamento de escopo e da responsabilidade única de cada peça dentro do sistema. Esse conceito se encaixa no que chamamos de Modular Monolithic Architecture.

Essa abordagem segue um dos princípios mais importantes da engenharia de software: o KISS (Keep It Simple, Stupid). Manter a estrutura do código simples e bem organizada permite que o time compreenda melhor as partes fundamentais do projeto. E, com essa visão mais ampla, fica muito mais fácil tomar decisões informadas sobre quando (e se) um módulo deve ser transformado em um microserviço.

Microserviços Quando Necessário

A chave aqui não é evitar microserviços, mas sim não começar um projeto já fragmentado em dezenas de pequenos serviços sem uma necessidade real. Alguns fatores devem ser levados em conta antes de tomar essa decisão, sendo os principais:

A importância do módulo: É algo crítico para o sistema? Precisa de uma escalabilidade específica?
A frequência de uso: O serviço será chamado o tempo todo ou é algo esporádico?
O tamanho do time: Esse é um ponto crucial. De nada adianta ter uma arquitetura de microserviços se o time é pequeno e precisa conhecer e trabalhar em todos eles. Assim como não faz sentido ter um monólito enorme com um time gigante brigando por Pull Requests intermináveis e gerando gargalos na entrega.

A Uber por exemplo teve que primeiro IDENTIFICAR que a arquitetura de monolito não era mais suportável.
É uma grande empresa que iniciou de um monolito, mas que teve que, a medida que eles cresciam os microserviços foram se tornando necessários. Aí que o case de sucesso em escalabilidade se faz. Um dos grandes problemas principalmente de iniciantes é querer resolver problemas que não existem (eu fui um iniciante enérgico querendo usar tudo que existe de "boas práticas" por aí 😅), mas que não está atacando nenhuma dor do projeto em si. A solução não se comunica com o que o projeto é.

Service-Oriented Architecture: Scaling the Uber Engineering Codebase As We Grow

No fim das contas, modularização bem feita e uma visão prática da arquitetura são muito mais importantes do que seguir modas cegamente. Microserviços não são sinônimo de escalabilidade, assim como monólitos não são sinônimo de sistemas ruins e antiquados.

Precisamos de um equilíbrio entre simplicidade e organização é o que realmente garante que um sistema seja sustentável no longo prazo. Nossa posição como desenvolvedores é compreender necessidades e atuar sobre elas. Entender as características do nosso produto ou do produto em que trabalhamos para nos perguntar de fato do que precisamos. Toda tendência é bacana para termos o conhecimento, mas não significa que nosso projeto pede por ela.

4 Conceitos legais do JavaScript que você vai achar legal também

Leomar Linhares — Sat, 05 Oct 2024 21:19:12 +0000

Depois de alguns anos trabalhando com JavaScript, percebi que muitos dos problemas que enfrentei se tornaram desafiadores simplesmente por eu não conhecer alguns conceitos essenciais. Se eu tivesse dominado esses tópicos antes, certamente teria evitado alguns estresses.

Então eu trouxe 4 conceitos que de alguma forma ficaram na minha cabeça e que eu fiquei simplesmente ANIMADÃO quando aprendi e recomendo dar uma visitada e entender para trabalhar com JavaScript, principalmente para pessoas que estão iniciando e já tem na memória pelo menos os conceitos básicos da linguagem.

1. Closures

Closures são um dos conceitos mais poderosos e, por muitas vezes, confusos no JavaScript, relacionados ao escopo. Elas permitem que uma função "lembre" do ambiente em que foi criada, mesmo depois que esse ambiente não está mais em execução. Isso é útil para criar variáveis "privadas" e gerenciar estados sem poluir o escopo global.

Exemplo:

function criarContador() {
    let contador = 0;

    return {
        incrementar: function() {
            contador++;
            return contador;
        },
        obterValor: function() {
            return contador;
        }
    };
}

const meuContador = criarContador();

console.log(meuContador.obterValor()); // 0
console.log(meuContador.incrementar()); // 1
console.log(meuContador.incrementar()); // 2
console.log(meuContador.obterValor()); // 2

No exemplo acima, a função interna acessa a variável contador, que pertence à função externa, mesmo depois de meuContador já ter retornado valores usando ou obterValor ou o incrementar. Isso é possível graças ao closure.

2. Herança Prototípica

Embora o JavaScript ofereça suporte a classes e herança de classes (um conceito bem consolidado em linguagens como Java ou C++), ele se diferencia ao adotar, de forma nativa, um modelo de herança baseado em protótipos. Em JavaScript, todo objeto tem um "protótipo", que serve como uma espécie de blueprint (molde), permitindo que propriedades e métodos sejam compartilhados entre objetos. Esse modelo de herança prototípica é uma das características mais fundamentais da linguagem, tornando-a mais flexível em comparação com a herança tradicional baseada em classes.

Exemplo:

function Carro(nome) {
    this.nome = nome;
}

Carro.prototype.buzina = function() {
    console.log(`${this.nome} faz um som de buzina`);
}

const camaro = new Carro('Camaro');
camaro.buzina(); // Camaro faz um som de buzina

Aqui, camaro herda o método buzina do protótipo de Carro, demonstrando a ideia de herança em JavaScript. Através da cadeia de protótipos, conseguimos compartilhar comportamentos entre diferentes objetos sem a necessidade de duplicar o código.

3. Currying

Currying é uma técnica que transforma uma função que recebe vários argumentos em uma série de funções que recebem um único argumento de cada vez. Essa abordagem é útil para criar funções reutilizáveis e compor novas funções de maneira mais flexível.

Exemplo:

function somar(a) {
    return function(b) {
        return a + b;
    }
}

const somarTres = somar(3);
console.log(somarTres(3)); // 6

No exemplo, somar(5) retorna uma nova função que recebe o segundo argumento, permitindo que se reutilize a lógica em diferentes partes do código.

4. Event Loop e Callbacks

O Event Loop é um conceito fundamental para entender como o JavaScript lida com operações assíncronas — e rapaz, entender isso foi um divisor de águas no meu aprendizado de JavaScript. O que ele faz, basicamente, é monitorar a Call Stack (onde o código sincrônico é executado) e a Event Queue (onde ficam armazenadas as tarefas assíncronas, como callbacks, eventos e promessas). Quando a Call Stack está vazia, o Event Loop pega as tarefas da Event Queue e as coloca na pilha para serem executadas. Isso garante que o JavaScript consiga continuar rodando o código sem bloquear outras operações, algo essencial para manter a fluidez de aplicações que lidam com eventos de I/O, timers, e interações com o DOM.
Exemplo:

console.log('Início');

setTimeout(() => {
    console.log('Timer expirou');
}, 0);

console.log('Fim');

// Saída:
// Início
// Fim
// Timer expirou

Mesmo que o setTimeout seja configurado para 0 milissegundos, ele é colocado no Event Queue e só será executado após o código sincrônico (como os console.log) ter sido processado.
Pretendo detalhar isso melhor e com imagens em outro artigo focado nesse conceito, pois pra mim foi muito importante entender e tenho certeza que pra muitas pessoas vai ser também.

Você gostaria de saber mais sobre algum desses conceitos ou tem dúvidas específicas? Deixe nos comentários que eu vou dar uma olhada!