Lucas Simon

Tudo bem pessoal!? Estarei iniciando uma nova série, curtinha e direto ao ponto, utilizando o Flask para produzir mensagens para o RabbitMQ e sendo consumidos por um app Node.JS.

Slide

Para entendimento, segue os capítulos que serão abordados.

• Capítulo 1: Introdução, configuração e Hello World

• Capítulo 2: Organizando as dependências e requerimentos

• Capítulo 3: Configurando o pytest e nosso primeiro teste

• Capítulo 4: Configurando o Makefile

• Capítulo 5: Adicionando o MongoDB

• Capítulo 6: Criando e testando o modelo de usuários

• Capítulo 7: Criando usuários

• Capítulo 8: Listando usuários

• Capítulo 9: Buscando usuários

• Capítulo 10: Editando um usuário

• Capítulo 11: Deletando um usuário

• Capítulo 12: Autênticação por JWT

• Capítulo 13: Criando um container Docker

• Capítulo 14: Deploy Flask na Digital Ocean

• Capítulo 15: Automatizando o processo de deploy com Fabric

• Capítulo 16: CI e CD com Jenkins, Python, Flask e Fabric

• Capítulo 17: Utilizando o RabbitMQ com Flask e Sendgrid para enviar e-mails de boas vindas e ativar a conta do usuário Estamos aqui

O repositório com todo o código fonte esta aqui. Os capítulos estão em branches.

A arquitetura

Ao desenvolvermos aplicativos backend, inicialmente recorremos a arquitetura monolitica. E não ha nada de errado nisto, pois precisamos validar um protótipo e entregar nosso MVP.

Porém ao longo do tempo e com acrescimo de funcionalidades a sua aplicação que antes era um monolito para validar o negócio no mercado agora é uma plataforma inchada sendo bem custoso dar manutenção.

A funcionalidade

Neste artigo, vamos fazer as seguintes estórias:

Como usuário devo me registrar no aplicativo para ter acesso as principais noticias do mercado de ações

Como plataforma devo cadastrar o usuário na base de dados e enviar um e-mail de boas vidas com um botão para ativar a conta do usuário

Como plataforma devo receber a URL de ativação, verificar o usuário e ativar a conta para que ele, o usuário, acesse a plataforma

Ao desenvolvermos a funcionalidade de forma procedural em um monolito, segunda estória, podemos correr alguns riscos.

Primeiro por se tratar de uma integração ha uma requisição para o serviço de terceiro que podem:

1. A requisição pode demorar para ser processada devido o custo de rede

2. O serviço de terceiro pode estar fora do ar

3. A requisição está com dados errados e o serviço de terceiro retorna um erro

Devido aos possíveis problemas citados acima temos diversos efeitos colaterais na plataforma como também ao usuário, a equipe de desenvolvimento e a empresa.

Em caso de erro temos:

O usuário registrado não irá receber o e-mail como consequência não irá utilizar o aplicativo pois não está ativado. Em linguagem de CRM perde-se um LEAD.

A equipe de desenvolvimento terá de interferir para recuperar os dados do usuário, ja que houve um erro, e reprocessar todo o processo. Com isso ele deve verificar o serviço de e-mail, fazer um envio de teste, reprocessar o pedido, ir para o código diagnosticar o problema. Constatado um BUG na plataforma é necessário abrir uma nova tarefa, corrigi-la, o que demanda mais tempo de desenvolvimento, subir a correção e torcer para tudo dar certo. Geralemente é assim que acontece =/

Para a empresa tem os gastos envolvidos tanto na alocação de um profissional para corrigir o problema quanto a perda de um valioso usuário que vai deixar de usar a plataforma.

Proposta

A proposta dessa nova série é quebrar os monolitos pouco a pouco até formar uma arquitetura de microserviços com os seguintes preceitos.

• Disponibilidade

• Segurança de dados

• Funcionalidades mais enxutas e desacopladas

Fontes de estudo:

Introdução a mensageria com RabbitMQ

Utilizando o pacote pika para conectar ao RabbitMQ

Consumindo as filas com NodeJS