Arquivos nodejs - LuizTools

Autorização em Node.js com Passport – Parte 4

Esse tutorial é uma continuação de uma série de artigos sobre segurança em Node.js que iniciei há algum tempo, usando o módulo Passport, o mais popular para autenticação em Node.js. Nas etapas anteriores nós criamos o login, o cadastro, a recuperação de senha e o logout. Hoje vamos criar a camada de autorização, ou seja, uma vez que o usuário esteja autenticado, devemos permitir ou não que ele faça determinadas operações no sistema conforme o seu perfil de acesso.

Atenção: para que possa acompanhar este tutorial é necessário que tenha realizado as etapas anteriores ou ao menos baixado o zip do tutorial anterior, disponível via formulário sempre ao final dos tutoriais. Note que mesmo baixando o zip, você terá de ter o Node.js e o MongoDB instalados na sua máquina (este último rodando) e tem de revisar o arquivo .env para configurar ele com os seus dados (email, string de conexão do banco, etc). Sugiro cadastrar também alguns usuários no seu Mongo para poder usar o sistema corretamente.

Vale salientar que este artigo possui uma versão em videoaula, disponível aos inscritos em meu curso de Node.js e MongoDB.

Vamos lá!

O tripé de segurança

Os elementos mais básicos de segurança em sistemas são o tripé AAA: Autenticação, Autorização e Auditoria. Já falamos extensivamente sobre autenticação nos artigos anteriores e nesse vamos falar de autorização.

A diferença mais básica é que autenticação se resume a dizer quem pode ou não entrar. Já autorização, é o que cada usuário que entrou, pode fazer no sistema.

Existem várias maneiras de implementar isso, das mais elaboradas (usando recursos dedicados de infraestrutura como Active Directory ou LDAP, por exemplo) às mais simples, ter perfis no seu banco de dados e dar match com eles na hora de ver se o usuário pode ou não fazer algo que ele quer. Eu irei neste tutorial pela segunda abordagem.

Espero em artigos futuros falar do terceiro A do tripé: a auditoria, que nada mais é do que o registro das atividades dos usuários no sistema, para consulta futura.

Autorização com ExpressJS e Passport

Como já foi implementado nos tutoriais anteriores e extensivamente explicado, o Passport é um framework genérico para construir de maneira modular a segurança do seu sistema. Nos tutoriais passados usamos ele em conjunto com um conector de MongoDB, pra usar o respectivo banco como sendo a verdade em termos de autenticação do sistema.

Assim, a cada requisição do ExpressJS, usamos o middleware para chamar uma função de verificação e dizer se o usuário pode ou não continuar fazendo aquela requisição ou se deve ser jogado para a tela de login. O que iremos fazer aqui são três coisas:

fornecer funções genéricas para que possa ser verificado a autorização do usuário para determinada operação;
aplicar tais funções no middleware do Express para, nas chamadas do Passport, avaliar não apenas a autenticação, mas também a autorização;
chamar tais funções também na renderização da interface, para garantir que ela atenda às necessidades de segurança conforme usuário autenticado;

Com isso, você não terá um sistema completo, mas um overview de como aplicar tais conceitos e códigos em um sistema real.

Adaptando o cadastro

A primeira coisa que vamos fazer é adaptar a nossa tela de signup para incluir a informação de perfil do usuário. Aqui faremos algo super simples: ao cadastrar um novo usuário, você vai selecionar entre os perfis de administrador e de usuário.

Modifique a view signup.ejs para incluir um select de perfil, como abaixo:

<!doctype html>
<html>
  <body>
    <h1>Signup</h1>
    <form action="/users/signup" method="POST">
      Username: <input name="username" type="text" /><br />
      Password: <input name="password" type="password" /><br />
      E-mail: <input name="email" type="text" /><br />
      Perfil: <select name="profile">
        <option value="1">Usuário</option>
        <option value="2">Administrador</option>
      </select><br />
      <input type="submit" value="Save" />
    </form>
    <% if(message) { %>
      <p>
        <label style="color:Red"><%= message %></label>
      </p>
    <%}%>
  </body>
</html>

<!doctype html>

<html>

<body>

<h1>Signup</h1>

Username: <input name="username" type="text" /><br />

Password: <input name="password" type="password" /><br />

E-mail: <input name="email" type="text" /><br />

Perfil: <select name="profile">

<option value="1">Usuário</option>

<option value="2">Administrador</option>

</select><br />

</form>

<% if(message) { %>

<p>

</p>

<%}%>

</body>

</html>

O que vai resultar em uma tela renderizada assim:

O usuário é salvo no banco de dados através de uma função createUser que fica no nosso módulo db.js. Assim, vamo nesse módulo alterar a respectiva função:

function createUser(username, password, email, profile, callback){
    const cryptoPassword = bcrypt.hashSync(password, 10);
    global.db.collection("users").insertOne({username, password: cryptoPassword, email, profile}, callback);
}

function createUser(username, password, email, profile, callback){

const cryptoPassword = bcrypt.hashSync(password, 10);

global.db.collection("users").insertOne({username, password: cryptoPassword, email, profile}, callback);

}

Note que você já tem usuários cadastrados no sistema, eles não terão a informação de profile (perfil) salva neles. Aí você tem duas opções: tratar quem não tem perfil como sendo um usuário padrão (que não é administrador), ou fazer um script para alterar todos os usuários já cadastrados no MongoDB para terem a informação de profile também.

Eu vou de primeira opção, vou considerar que por padrão os usuários sem profile NÃO são administradores.

Agora, para fazer o botão Save voltar a funcionar, vamos na rota users.js e vamos editar o código que trata requisições POST no endpoint /signup para que ele espere e salve o dado do perfil também, usando a função que acabamos de alterar, como abaixo:

/* POST users */
router.post('/signup', function(req, res, next){
  const db = require('../db');
  db.createUser(req.body.username, req.body.password, req.body.email, req.body.profile, (err, result) => {
    if(err) return res.redirect('/users/signup?fail=true');
    else{
      var text = 'Obrigado por se cadastrar {fulano}, sua senha é {senha}';
      text = text.replace('{fulano}', req.body.username).replace('{senha}', req.body.password);

      require('../mail')(req.body.email, 'Cadastro realizado com sucesso!', text);
      res.redirect('/');
    }
  })
})

/* POST users */

router.post('/signup', function(req, res, next){

const db = require('../db');

db.createUser(req.body.username, req.body.password, req.body.email, req.body.profile, (err, result) => {

if(err) return res.redirect('/users/signup?fail=true');

else{

var text = 'Obrigado por se cadastrar {fulano}, sua senha é {senha}';

text = text.replace('{fulano}', req.body.username).replace('{senha}', req.body.password);

require('../mail')(req.body.email, 'Cadastro realizado com sucesso!', text);

res.redirect('/');

}

})

Com isso, seu cadastro já deve estar funcionando novamente e sugiro que cadastre um novo usuário como sendo administrador, já que os anteriores vão ser todos considerados comuns.

Está curtindo o post? Para uma formação ainda mais completa como programador web recomendo meu livro sobre programação web com Node.js clicando no banner abaixo!

Inserindo autorização por página

Agora que você tem a informação de perfil junto ao usuário cadastrado e cadastrou um usuário administrador, vamos dar alguns privilégios apenas para administradores. Que tal criar uma página que somente eles podem acessar?

Vamos criar uma nova view chamada views/reports.ejs com um conteúdo bem simples, só pra testarmos o conceito:

<h1>Só administradores conseguem ver isso</h1>

1	<h1>Só administradores conseguem ver isso</h1>

E vamos criar um novo arquivo de rota em routes/reports.js com apenas o tratamento de um GET, como abaixo:

var express = require('express');
var router = express.Router();

/* GET reports page */
router.get('/', global.authenticationMiddleware(), function(req, res, next) {
    res.render('reports', { });
});

module.exports = router;

var express = require('express');

var router = express.Router();

/* GET reports page */

router.get('/', global.authenticationMiddleware(), function(req, res, next) {

res.render('reports', { });

});

module.exports = router;

Note como o global.autheticationMiddeware() é chamado, não apenas nesta, mas em todas rotas do sistema. Isso garante uma centralização das regras de segurança de acesso, que vamos modificar depois.

Registre essa nova rota no app.js como abaixo:

var reportsRouter = require('./routes/reports');
app.use('/reports', reportsRouter);

1 2	var reportsRouter = require('./routes/reports'); app.use('/reports', reportsRouter);

Se você rodar essa aplicação agora e tentar acessar digitando a URL http://localhost:3000/reports no seu navegador, conseguirá acessar normalmente esta página com qualquer usuário devidamente autenticado, mas não conseguirá acessar antes de fazer login (o servidor vai te redirecionar pra página de login se tentar fazer isso).

Mas e se quisermos restringir o acesso a essa página somente a administradores?

Existem várias maneiras de fazer isso. Vou te mostrar uma possibilidade que é centralizando em um módulo a estrutura de decisão para acesso às páginas. Certamente você deve ter várias ideias de como fazer melhor isso, mas essa é a mais simples e didática que consegui imaginar.

Crie na raiz do seu projeto um arquivo permissions.js e vamos criar nele uma lógica que, dada uma requisição, verificamos o usuário autenticado e que página ele está tentando acessar. Batemos essas informações com um switch/case e concedemos ou não a autorização para aquela página.

const ADMIN_PROFILE = '2';

function isAdmin(profile){
    return profile === ADMIN_PROFILE;
}

module.exports = (request) => {

    const user = request.user;
    if (!user) return false; // usuário anônimo

    const originalUrl = request.originalUrl;
    const profile = request.user.profile;
    //no futuro, você pode restringir de maneira diferente por method (GET,POST, etc)
    const method = request.method;

    console.log(originalUrl);
    //switch/case para tomada de decisão sobre autorizações
    switch(originalUrl){
        case '/': return true;
        case '/index': return true;
        case '/login': return true;
        case '/signup': return true;
        case '/reports': { return isAdmin(profile); }
        default: return false;
    }

}

const ADMIN_PROFILE = '2';

function isAdmin(profile){

return profile === ADMIN_PROFILE;

}

module.exports = (request) => {

const user = request.user;

if (!user) return false; // usuário anônimo

const originalUrl = request.originalUrl;

const profile = request.user.profile;

//no futuro, você pode restringir de maneira diferente por method (GET,POST, etc)

const method = request.method;

console.log(originalUrl);

//switch/case para tomada de decisão sobre autorizações

switch(originalUrl){

case '/': return true;

case '/index': return true;

case '/login': return true;

case '/signup': return true;

case '/reports': { return isAdmin(profile); }

default: return false;

}

Note que eu inicio o código criando uma constante e uma função muito simples para dizer se um perfil é ou não é admin. Mas é no module.exports que realmente programo algo de valor pois, dado uma request, eu pego as informações que me interessam e confronto elas com as URLs e suas lógicas de autorização.

Essa é uma abordagem centralizada em um módulo para as regras de autorização. Assim fica bem fácil de manter a aplicação com as regras necessárias. Outra abordagem que já usei no passado era de fazer isso em cada página, ao invés de fazer centralizado e ficou bem ruim de dar manutenção pois era fácil de esquecer de adicionar as regras certas. Aqui, do jeito que está, caso você se esquecer, ao testar já não vai abrir a página e você vai lembrar que deve permitir no arquivo permissions.js.

Mas como fazer esse código de fato passar a valer?

Volte ao app.js e você vai encontrar o código que configura o global.authenticationMiddleware. Você vai modificá-lo para, além de verificar se o usuário está autenticado, verificar se ele tem a permissão necessária para acessar aquela rota, usando o módulo que acabamos de criar, assim:

global.authenticationMiddleware = () => {  
  return function (req, res, next) {
    if (req.isAuthenticated() && require("./permissions")(req))
        return next()
    res.redirect('/login?fail=true')
  }
}

global.authenticationMiddleware = () => {

return function (req, res, next) {

if (req.isAuthenticated() && require("./permissions")(req))

return next()

res.redirect('/login?fail=true')

}

Agora, toda vez que uma rota for acionada, além de verificar se o usuário está autenticado ou não, vai ser verificado se ele possui permissão para acessar aquela rota. Eu deixei um comentário no código do permissions.js que lhe sugere no futuro verificar o method da request também. Assim, você pode diferenciar tentativas de acesso de tentativas de submissão de formulários, por exemplo.

Esse código, do jeito que está, já funciona e se você acessar sua aplicação e se autenticar, dependendo do usuário que utilizou vai conseguir ou não acessar a página /reports.

Customizando a interface pelo perfil

Para finalizar esse artigo, outra coisa bem comum de ser utilizado em sistemas são as interfaces customizadas conforme a permissão do usuário. Por exemplo, um botão pode ser visto apenas um perfil específico, pois é um botão importante.

Claro, você nunca deve confiar apenas em esconder elementos de interface, mas considerando que já garantimos na seção anterior a segurança por acesso, independente se foi feito digitando a URL ou clicando em links, agora vamos fazer um exemplo bem simples de esconder ou mostrar um elemento de interface baseado no perfil autenticado.

Primeiro, vamos na rota index.js e vamos mudar o código levemente, para informar o perfil do usuário autenticado no model que enviaremos pra view, como abaixo:

/* GET home page. */
router.get('/:pagina?', global.authenticationMiddleware(), function(req, res, next) {
  const pagina = parseInt(req.params.pagina || "1");
  db.countAll((err, qtd) => {
    if(err) return console.log(err);
    const qtdPaginas = Math.ceil(qtd / db.TAMANHO_PAGINA);

    db.findAllUsers(pagina, (err, docs) => {
      if(err) return console.log(err);
      res.render('index', { title: req.user.username, docs, qtd, qtdPaginas, pagina, profile: req.user.profile });
    })
  })
});

/* GET home page. */

router.get('/:pagina?', global.authenticationMiddleware(), function(req, res, next) {

const pagina = parseInt(req.params.pagina || "1");

db.countAll((err, qtd) => {

if(err) return console.log(err);

const qtdPaginas = Math.ceil(qtd / db.TAMANHO_PAGINA);

db.findAllUsers(pagina, (err, docs) => {

if(err) return console.log(err);

res.render('index', { title: req.user.username, docs, qtd, qtdPaginas, pagina, profile: req.user.profile });

})

});

Note que a única linha que mexi foi aquela do profile, para passá-lo para a view.

Agora, na view views/index.ejs, vamos editar o código HTML para, baseado no perfil do usuário, exibir ou não um link para a página de relatórios. Basta inserir esse trecho em qualquer parte da página:

    <p>
      <%
        if(profile === '2'){
      %>
          <a href="/reports">reports para admins</a>
      <% } %>
    </p>

<p>

if(profile === '2'){

<a href="/reports">reports para admins</a>

<% } %>

</p>

Com isso, você pode testar sua aplicação com diferentes usuários e verificar que somente quando se autentica com os administradores é que consegue ver o dito-cujo link que acabou de adicionar.

O mais legal é que, independente do usuário ver ou não o link, se ele tentar burlar acessando diretamente a página de reports, a nossa segurança que está no middleware vai barrar ele também.

E por hoje é isso, espero que tenha gostado, deixe suas dúvidas nos comentários. Você pode baixar os fontes usando o formulário que pede seu e-mail e, se quiser participar do meu curso de Node.js e MongoDB, além de fazer parte do meu grupo online de Whatsapp com mais de 100 estudantes de Node, clique no banner abaixo.

Este artigo tem uma versão em videoaula em uma das aulas do meu curso de Nodejs e MongoDB que você confere clicando no banner abaixo.

O que é um micro servico ou microservice?

Eu já falei sobre esse assunto antes aqui no blog, em outros artigos, sendo que o principal deles e que recomendo que leia na sequência é o Introdução a Arquitetura de Micro Serviços. A ideia do artigo de hoje é explorar mais o que é um microservice e lhe ajudar no entendimento e no desenvolvimento estudando alguns princípios básicos.

O objetivo principal de usar micro serviços (ou microservices) é ajudar o time de engenharia a entregar produtos mais rápido, de maneira mais segura e com qualidade mais alta. Pequenos serviços desacoplados permitem que os times tenham ciclos de desenvolvimento (sprints ou iterações) rápidos e com mínimo impacto ao resto do sistema.

Um micro serviço é uma pequena porção de software que roda de maneira independente, focada em um único e pequeno (daí o nome micro) conjunto de atividades dentro de um conjunto de serviços muito maior, formando uma arquitetura de micro serviços. Resumidamente é uma versão mais enxuta de web services e web APIs que tradicionalmente os desenvolvedores já faziam há anos.

Em uma arquitetura de micro serviços, múltiplos serviços fracamente acoplados (ou seja, com poucas ou nenhuma dependência entre si) trabalham juntos. Cada serviço foca em um único propósito e tem uma alta coesão (congruência, coerência) de comportamentos e dados relacionados. Note que esta última definição inclui três princípios básicos do design de micro serviços, que vamos ver a seguir.

Os três princípios do design de micro serviços

Quando estamos trabalhando em sistemas que usam a arquitetura de micro serviços devemos sempre ter em mente três princípios básicos.

Propósito Único: cada serviço deve focar em um único propósito e fazê-lo bem. Esta é regra é muito semelhante com o Single Responsibility Principle do acrônimo SOLID, muito utilizado em orientação à objetos.

Assim como o SRP do SOLID diz que uma classe Aluno deve se focar apenas em atender às necessidades de um aluno, o princípio do Propósito Único diz que um micro serviço ‘/alunos’ deve se focar apenas em realizar operações sobre alunos. Precisa lidar com questões financeiras do aluno? Crie outro micro serviço para focar nisso. Precisa fazer uma matrícula, onde tem de lidar com o aluno e com questões financeiras? Crie um terceiro micro-serviço que vai chamar os dois anteriores.

Garantir que cada micro serviço tenha um propósito único não é tão fácil e simples, mas é uma das dicas essenciais principalmente quando você está refatorando uma aplicação monolítica em micro serviços.

Baixo Acoplamento: cada serviço não deve saber nada ou muito pouco dos outros serviços. Eles não devem compartilhar bibliotecas de código, ou apenas o que for genérico e essencial para ter o mínimo de código repetido. Eles devem ter suas próprias validações, seus próprios testes unitários e inclusive não precisam compartilhar sequer a mesma tecnologia ou o mesmo mecanismo de persistência.

Isso tudo para que uma mudança em um serviço não exija mudar outros serviços. Ou que um bug inserido no desenvolvimento de um serviço não atinja o código de outros também. Inclusive a comunicação entre serviços deve ser feita através de interfaces públicas e protocolos leves, funcionando em processos separados.

Este também é um princípio herdado da Orientação à Objetos, onde trabalhamos Loose Coupling ou Low Coupling dentro dos design patterns como sendo um objetivo desejável para garantir boas arquiteturas, muito mencionado no clássico Padrões de Arquitetura de Aplicações Corporativas, do Martin Fowler.

Alta Coesão: cada serviço encapsula todos os comportamentos e dados relacionados juntos. Isso garante que se precisarmos construir uma nova feature sobre um mesmo domínio ou propósito, todas as mudanças devem ser localizadas em um único serviço.

Note que o próprio princípio do Propósito ou Responsabilidade Única dá os subsídios necessários para garantir uma alta coesão, outro tema bem forte nos design patterns da orientação à objetos.

No gráfico abaixo, extraído da Internet, temos a relação entre estes três princípios e como eles se interseccionam para gerar a base desejada para a construção de micro serviços que atendem ao padrão deste tipo de arquitetura.

Quando modelamos microservices nós temos que ser disciplinados em seguir ao menos estes três princípios básicos de design. É o único caminho para atingir o potencial pleno de uma arquitetura de microservices. Deixar qualquer um deles de lado fará com que o seu padrão se torne um antipattern ou anti-padrão, algo que vai te levar a resultados ruins, ao invés do que você espera.

Sem um propósito único, por exemplo, cada microservice pode terminar fazendo muitas coisas, crescendo em uma arquitetura de vários serviços monolíticos. Isso fará com que, além de não colher os benefícios completos de uma arquitetura de microservices, você terá um custo operacional alto para manter isso.

Sem um acoplamento baixo, mudanças em um serviço vão afetar outros serviços, lhe impedindo de liberar releases de maneira rápida, frequente e livre de bugs, que é justamente o benefício principal de uma arquitetura dessas. Mais importante ainda, problemas causados por um alto acoplamento podem ser desastrosos como inconsistências de dados ou mesmo perda deles.

E por fim, sem alta coesão, acabamos gerando uma aplicação monolítica distribuída, muito comum no passado e que há décadas sofremos com legados deste tipo onde, apesar de termos muitos serviços, só podemos aplicar novas features em produção se atualizarmos e implantarmos todos eles em produção, muitas vezes em uma ordem específica e ao mesmo tempo. Na minha opinião e de outros engenheiros com ainda mais experiência, isso é pior do que ter uma grande aplicação monolítica porque a complexidade e o custo operacional disso é muito alto.

O que não é um micro serviço?

Muitas vezes fica mais fácil de entender o que algo é quando definimos o que ele não é, certo?

Um micro serviço não é um serviço que tem um número pequeno de linhas de código ou que faz ‘micro tarefas’. Esta confusão vem do próprio nome, mas não é uma regra e nem é o objetivo desta arquitetura. Os serviços devem possuir a complexidade e quantidade de linhas de código necessárias desde que atendam os três princípios anteriormente descritos.

Um micro serviço não é um serviço construído com a tecnologia mais bacana e hipster que o mercado oferece no momento. Embora a arquitetura de micro serviços te permita sim testar novas tecnologias de maneira muito rápida e fácil, não é um objetivo primário desta arquitetura. Está completamente ok usar qualquer tecnologia que atenda aos princípios anteriores e não faz sentido algum refatorar todos seus micro serviços cada vez que uma nova stack aparece no mercado.

Um micro serviço não tem de ser sempre programado do zero. Quando você está iniciando um processo de refatoração de uma aplicação monolítica, é muito comum que você extraia códigos da aplicação original para os micro serviços e não há problema algum nisso, desde que respeite os três princípios.

Então por hoje é isso, espero que tenha gostado e, caso queira saber mais sobre o assunto, recomendo meu curso de Node.js e MongoDB ou o meu livro sobre micro serviços abaixo.

Dicas para refatorar um monolito em micro serviços

Erroneamente creditei a fonte original em Inglês à Rising Stack, mas na verdade é da Nginx.

O processo de transformar uma aplicação monolítica em micro serviços é uma forma de modernização de aplicação, algo que os desenvolvedores já fazem há décadas. Como resultado, existem algumas ideias que você pode reutilizar quando estiver refatorando uma aplicação em microservices. Se você não sabe o que é um microservice, recomendo este artigo primeiro.

Uma estratégia é não fazer uma reescrita Big Bang, ou seja, esqueça a ideia de reescrever toda aplicação do zero, direcionando todos os esforços do time para isso. Embora muitas vezes isso soe interessante, é algo extremamente arriscado e geralmente resulta em problemas. Como Martin Fowler já disse algumas vezes, em uma tradução livre, a única garantia de um Big Bang é que algo vai explodir!

Ao invés de fazer uma reescrita Big Bang, você deve incrementalmente refatorar sua aplicação monolítica. Construa uma aplicação de microservices gradualmente, rodando cada novo microservice em conjunto do monolito original. Com o passar do tempo, a quantidade de funcionalidades implementadas em microservices versus a quantidade de funcionalidades remanescentes no monolito vai evidenciar que o mesmo encolheu ao ponto de que em algum momento ele irá sumir.

Martin Fowler refere-se à essa estratégia de modernização de Strangler Application (Aplicação Estranguladora). O nome vem da vinha estranguladora, uma espécie de cipó que cresce em árvores tropicais. Esta vinha vai se fixando na árvore original, consumindo seus recursos enquanto ela própria cresce mais rápido que sua hospedeira, não raro causando a morte da árvore original e deixando no lugar um monte de vinhas no formato de uma árvore.

Estratégia #1 – Pare de Cavar

A Lei dos Buracos (Law of Holes) diz que toda vez que você estiver em um buraco, você deve parar de cavar. Este é um ótimo conselho quando sua aplicação monolítica se tornar ingerenciável. Em outras palavras, você deve parar de tornar seu monolito maior. Se tiver de implementar uma nova funcionalidade você não deve adicionar este código ao monolito. Ao invés disso, a grande ideia com esta estratégia é colocar o novo código em um microservice próprio pra isso. O diagrama a seguir, do site Nginx, mostra a arquitetura do sistema depois de aplicar esta abordagem.

Repare no uso de um request router à frente de ambas soluções (monolito e microservice) que pode facilmente ser um API Gateway. Esta camada de software recebe as requisições originais e verifica se elas devem ser direcionadas para o legado ou para o microservice.

O outro componente que surge com esta arquitetura híbrida foi chamado de Glue Code no diagrama e nada mais é do que as dependências responsáveis por acesso a dados. Geralmente o serviço irá usar libs e componentes de acesso a dados do monolito original. Com isso em mente, esse glue code pode usar uma de três estratégias:

Invocar uma API remota fornecida pelo monolito;
Acessar a base de dados do monolito diretamente;
Manter sua própria cópia da parte da base de dados que lhe interessa, a qual deve estar sincronizar com a base do monolito;

Este glue code muitas vezes é chamado de camada anti-corrupção. Isto porque este glue code evita que o micro serviço seja poluído por conceitos do modelo de domínio legado. O termo camada de anti-corrupção foi introduzido pela primeira vez no livro Domain Driven Design do Eric Evans e depois foi refinando em um white paper. Desenvolver uma camada anti-corrupção não é algo exatamente trivial, mas é essencial se quiser sair do inferno do monolito.

Implementar novas funcionalidades como um micro serviço tem uma série de benefícios. Essa estratégia impede que seu monolito se torne ainda mais ingerenciável, ao mesmo tempo que permite que o serviço possa ser desenvolvido, implantado e escalado de maneira independente do monolito. A cada serviço novo que você cria, você experimenta um pouco mais dos benefícios desta arquitetura.

Entretanto, esta abordagem não endereça os problemas do monolito. Para consertar estes problemas você precisa quebrar o monolito, o que falaremos a seguir.

Estratégia #2 – Separe Frontend e Backend

Uma estratégia que ajuda a encolher a aplicação monolítica é separar a sua camada de apresentação da sua lógica de negócio e do acesso a dados também. Uma típica aplicação corporativa consiste de ao menos três diferentes tipos de componentes:

Presentation layer – Componentes que lidam com requisições HTTP e implementam APIs ou UIs. Em uma aplicação que tenha uma interface de usuário muito sofisticada terá uma quantidade de código de front-end substancialmente grande.
Business logic layer – Componentes que são o core da aplicação e implementam as regras de negócio.
Data‑access layer – Componentes que acessam outros componentes de infraestrutura como bancos de dados e message brokers.

Geralmente existe uma separação muito clara entre a lógica de apresentação em um lado e as regras de negócio e de dados em outro. Geralmente a sua camada de negócio vai ter uma API consistindo de uma ou mais fachadas/interfaces que por sua vez encapsulam os componentes de lógica de negócio. Esta API é o que permite fazer a separação do seu monolito em duas aplicações menores. Uma aplicação vai ser o front-end, a outra o back-end. Uma vez separados, o front-end irá fazer chamadas remotas ao back-end, sendo que o diagrama abaixo mostra como isso fica, antes e depois:

Separar um monolito dessa maneira tem dois benefícios principais. Ele permite que você desenvolva, implante e escale duas aplicações de maneira independente. Principalmente quando se fala de front-end e rápidas iterações, testes A/B, etc. Outro benefício é que você combina com a estratégia #1 ao fornecer uma API do monolito para ser consumida pelos novos micro services que você desenvolver.

Esta estratégia, no entanto, é somente uma solução parcial. É bem comum que você troque um problemão gigante por dois problemas menores, mas que ainda são um problema a ser resolvido. Você terá de usar uma terceira estratégia para eliminar os monolitos restantes.

Estratégia #3 – Extrair Serviços

A terceira técnica de refatoração é transformar os módulos existentes dentro de um monolito em micro services standalone. Cada vez que você extrai um módulo e o transforma em um serviço, o monolito encolhe. Uma vez que você tenha convertido muitos módulos, o monolito irá parar de ser um problema. Ou ele irá sumir ou vai virar apenas um serviço por si só.

Priorizando quais módulos vão virar serviços

Uma aplicação monolítica grande geralmente terá dezenas ou centenas de módulos, todos candidatos para extração. Saber quais módulos converter primeiro pode ser desafiador. Uma boa abordagem é começar com alguns módulos que são fáceis de extrair. Isto vai lhe dar experiência com microservices em geral e com o processo de extração em particular. Depois que você extrair estes módulos mais fáceis, poderá partir para os mais importantes.

Converter um módulo em um microservice é algo que tipicamente requer tempo. Uma técnica de priorização é priorizar aqueles que mudam com frequência. Uma vez que você tenha convertido um módulo desses para um serviço, você pode desenvolver e implantar ele de maneira independente do monolito, o que vai acelerar o seu desenvolvimento.

Outra abordagem interessante é extrair os módulos que possuem requisitos significantemente diferentes do resto do monolito. Por exemplo, é útil pegar aquele módulo que usa uma base de dados in-memory e transformá-lo em um microservice, o qual poderá ser implantado em um servidor com muita memória. Da mesma forma, aquele módulo que consome muita CPU pode ser transformado em um microservice e feito deploy em um servidor com muito mais CPU do que RAM. Conforme você vai extraindo estes módulos específicos, você vai ver como se tornará mais fácil escalar os mesmos.

Como extrair um módulo

O primeiro passo ao extrair um módulo é definir a interface entre o módulo e o monolito. Geralmente será uma API bidirecional pois é comum o monolito precisar de dados do microservice e vice-versa. Se a sua lógica de negócio do monolito estiver com muitas associações entre suas classes talvez seja difícil de expor apenas o que importa para o microservice utilizar e não é raro que uma refatoração interna no monolito seja necessária para continuar avançando com essa estratégia de extração.

O diagrama abaixo mostra o passo a passo da extração de um módulo de um monolito para um microservice:

Neste exemplo, o módulo Z é o candidato a ser extraído. Seus componentes são usados pelos módulos X e Y. O primeiro passo de refatoração é definir um par de APIs de alto nível. A primeira interface é de entrada e é usada pelo módulo X para invocar o Z. A segunda é uma interface de saída usada pelo módulo Z para invocar o Y.

O segundo passo da refatoração transforma o módulo em um serviço separado. Uma vez que você tenha extraído um módulo, é mais um serviço que você tem que lhe permite desenvolver, implantar e escalar mais facilmente do restante do monolito. Você poderá inclusive reescrever este serviço do zero mais tarde, uma vez que o módulo já foi isolado.

Cada vez que você extrair um novo serviço, estará um passo mais perto de ter uma aplicação 100% em microservices. Com o passar do tempo, seu monolito vai encolher e a virada de chave entre as arquiteturas vai se tornar algo natural e inevitável.

Até a próxima!

Este artigo é uma adaptação livre do original Refactoring a monolith into microservices, de Chris Richardson.

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre microservices com Node.js!