Danilo Val

Introdução a Microserviços

2021-02-07T18:00:00+00:00

Bem, projetar software é bastante complexo. Quando comecei a compreender as entranhas de minha primeira linguagem de programação (~~Delphi 7, vê-se aqui a quanto tempo foi isso, rsrs~~), foi bastante natural naquele momento ganhar confiança e me sentir cada vez mais orgulhoso sobre cada linha de código escrita, mas já naquele momento eu sabia que seria muito mais do que arrastar caixas de texto e implementar alguma regra de validação sobre aquele componente.

Conforme o tamanho e a complexidade dos projetos ao qual eu era inserido aumentavam, eu aprendia que nosso meio de trabalho é responsável por tomar decisões que vão muito além de simplesmente escrever linhas e mais linhas de código, estávamos na verdade transcrevendo histórias que outrora foram executadas por outros seres humanos de forma manual, modificando a maneira como tudo fora feito até ali, acelerando de forma imensurável mercados que nem imaginavam até aquele momento a capacidade de crescimento e revolução que a tecnologia nos trouxe.

Lembro-me claramente que no começo da carreira eu me achava o desenvolvedor mais incrível do universo, e tinha certeza que era capaz de fazer qualquer coisa. Por uma dessas coincidências da vida, fui jogado quase que sem querer (~~podemos contar essa história por aqui em outro momento~~) em uma software house (Cadena) da minha cidade, foi um tremendo choque de realidade eu absolutamente não sabia de nada e obviamente não fiquei lá por mais de 3 meses isso me colocou na minha primeira crise do impostor (~~falaremos no futuro também~~), mas me fez buscar mais e mais conhecimento, e entender naquele momento que estudar e testar coisas, provavelmente seria o que eu faria pela vida toda.

Durante os anos, novos projetos, times, empresas, e fui apresentado a um papel denominado “Arquiteto de Software”, estes são responsáveis por conceber e delinear o panorama geral de um sistema, impactando diretamente (~~para melhor ou para pior~~) cada fase do ciclo de vida do projeto, desde o estágio de desenvolvimento até muito depois de seu lançamento final.

Arquitetura de Software

Ao longo dos anos, os arquitetos de software têm a incumbência de encontrar os melhores mecanismos para projetar sistemas que são escaláveis e de fácil manutenção. A arquitetura N-Tier é um exemplo famoso, apresentando uma segregação de responsabilidades que divide o código em pelo menos três camadas: dados, negócio e apresentação. Embora a princípio seja bom, a realidade nos mostra que é bastante difícil manter a camada de apresentação verdadeiramente impermeável. Sem um mecanismo para detectar quando esse princípio é violado, a lógica de negócios eventualmente vazará para a camada de apresentação, criando um acoplamento forte e um pesadelo quanto à sustentabilidade operacional.

A arquitetura hexagonal é uma evolução disso, introduzindo o conceito de portas e adaptadores para impor um encapsulamento mais rígido e uma separação mais forte de interesses, encorajando os desenvolvedores a raciocinar sobre seus softwares como uma série de componentes modulares, em vez de uma pilha de camadas horizontais largas e pesadas. Mas mesmo assim, ainda estamos olhando para um grande aplicativo monolítico que precisa ser gerenciado e implantado como um todo, limitando a capacidade de comprometer efetivamente uma mudança em uma única parte do sistema com a confiança de que não afetará outras.

E finalmente, nos últimos anos, vemos um interesse crescente e cada vez mais difundido no paradigma de microserviços, que se caracteriza por promover componentes para serviços autônomos e implementáveis de forma independente. Os princípios básicos apresentados são vistos como uma forma robusta e confiável de sistemas de construção, e os principais participantes do setor estão usando-os em produtos de produção em larga escala.

Vamos tentar examinar por aqui todos os princípios, por meio de uma análise balanceada de seus benefícios e armadilhas encontradas, terminando com um visão técnica (com um viés bastante opinativo) sobre por que microserviços e Node.js é uma combinação um tanto quanto atraente.

O Monolito

Em uma abordagem tradicional, normalmente possuímos um único software formado por uma base de código dividida internamente nas seguintes camadas:

Camada de apresentação, usada para exibir o conteúdo aos usuários, também potencialmente recebendo entrada (no caso de um aplicativo da web, isso seria um conjunto de páginas HTML);
Camada lógica ou de negócios, responsável por todo o processamento intermediário, executando a lógica que é específica para o domínio de negócios;
Camada de acesso a dados, lê e grava dados em banco de dados.

Os vários componentes que formam cada uma dessas camadas são agrupados e implantados em um servidor de produção como uma entidade única e unitária.

Vamos imaginar que o software deste blog foi construído com essa arquitetura, usando um banco de dados relacional como armazenamento de dados. Se tivéssemos de renderizar uma página com um post específica junto com todos os comentários gerados pelos usuários vinculados a ele, o software consultaria as tabelas de posts e comentários, usando um SQL JOIN ou semelhante, processa e formata os dados conforme necessário e exibir de volta ao cliente. Toda essa comunicação e processamento acontece por meio de chamadas ou requisição única.

Então, o que exatamente são microserviços e como eles se diferenciam do paradigma monolítico? Sempre que alguém me faz essa pergunta ou quando estou fazendo uma palestra sobre o assunto, refiro-me a esta citação de Martin Fowler:

O estilo de arquitetura de microserviços é uma abordagem para desenvolver um único software com um pacote de pequenos serviços, cada um executando em seu próprio processo e se comunicando com mecanismos leves, geralmente uma API de recurso HTTP. Esses serviços são desenvolvidos em torno de recursos de negócios e podem ser implantados de forma independente por meio de máquinas de implantação totalmente automatizadas.

Com microserviços, os componentes não vivem juntos dentro dos limites de uma única unidade. Em vez disso, essa arquitetura promove o desenvolvimento e a implantação de aplicativos como um conjunto de serviços independentes e autocontidos. Se modificarmos o exemplo acima usando esse estilo de arquitetura, as etapas que seguiríamos para obter o mesmo conteúdo poderiam ser bem diferentes.

Em vez de possuirmos o software consultando um único banco de dados para posts e comentários, poderíamos ter um serviço exclusivo para posts, responsável por armazenar, gerenciar e entregar histórias. O serviço seria executado em seu próprio processo e todas as comunicações de e para ele são estabelecidas por meio de chamadas de rede, processadas por seu próprio servidor web e usando uma API que expõe ao mundo exterior. Se o próprio serviço precisar fazer uso de outros serviços, isso também acontece por meio de chamadas de rede (com exceção de uma conexão a um banco de dados, que pode ou não ser uma chamada direta em processo). Os mesmos princípios também podem ser aplicados ao um serviço de comentários, conforme imagem abaixo.

Sabemos que microserviços se referem à construção de um sistema por meio da composição de vários serviços independentes, mas o que mais define essa arquitetura? Abordaremos os princípios chave dos microserviços e os benefícios associados que eles podem trazer para um software no próximo post.

Gostou desse post? Considere assinar a Newsletter logo ai abaixo.

Vem comigo, que no caminho eu te explico...

O que é uma API?

2021-01-29T15:00:00+00:00

APIs do Google, Twitter, GitHub, React, DOM. Parece que tudo se transformou em APIs? O que é uma API e porque este conceito passou a ser tão onipresente? A grande maioria dos aplicativos que utilizamos hoje em dia possuem alguma forma de interface construída exclusivamente para a interação humana. Podendo ser elementos gráficos em um site ou aplicativo móvel, chatbot, ou, até mesmo uma voz condensada em um(a) assistente pessoal.

Humano vs Máquina

Existe ainda um tipo particular de interface, aquela construída com intuito de integrar diferentes softwares e/ou máquinas. ~~Essa talvez seja a pior definição possível sobre o que é uma API, mas espero que seja possível compreender minha linha de raciocínio~~. API - Interface de programação de aplicativo (onde programação é a palavra-chave).

Quando pensamos na construção de software, em diferentes momentos existe a possibilidade ou a necessidade de que soluções troquem informação entre si, máquina para máquina, e nesse sentido a única interface de comunicação entre elas é uma API. É importante entender aqui que sua definição não está profundamente ligada a REST APIs (falaremos sobre isso no futuro) e que existem múltiplos protocolos de comunicação que possibilitam essa troca de informações.

Existem sim soluções que prometem um nível bastante amigável de implementação quanto ao desenvolvimento de software, usando inclusive o conceito de drag in drop, mas, nesse momento ainda é particularmente difícil definir todas as especificidades de um software e abstrair a necessidade de um humano, desenvolvedor, construindo definições e estratégias de implementação, ou para o melhor entendimento, transcrevendo regras do mundo físico para universo digital, esse cenário hoje se mostra tão confuso quanto seria para um pedestre pedir comida na janela de um drive-through ou para um motorista dirigir seu carro direto para a mesa de um restaurante, simplesmente não é a melhor ferramenta para o trabalho.

É especialmente difícil para um software conviver com qualquer tipo de mudança e abstrair ou modificar o comportamento de suas interfaces, assim como é habitual para qualquer ser humano adaptar-se a qualquer tipo de mudança em seu cotidiano, isso nos leva a dois aspectos aos quais eu considero os mais importantes na construção de uma API, e o que os diferencia essencialmente das interfaces de usuário que discorremos no início deste post. Formato e Contrato.

Formato

O formato é o conjunto de tecnologias e linguagens utilizadas pelo software para interagir com o consumidor. Uma vez que o consumidor é a máquina, as solicitações e respostas devem ser construídas de forma otimizada com as máquinas - linguagem de sinais, canções ou poesia são formas interessantes para os humanos se comunicarem, mas não tão eficientes quando se trata de máquinas.

Contrato

O contrato é o que garante aos desenvolvedores que uma API continuará a responder às solicitações de seus softwares de maneira consistente. Veja, caso em uma interface gráfica exista apenas botão verde nos cantos superior esquerdo e o modifiquemos para um botão vermelho no canto inferior direito, a maioria das pessoas se adapta instintivamente e continua usando o software sem nenhuma instrução ou assistência.

Enquanto que, os softwares são um pouco mais controlados, Caso uma API mude qualquer definição sem dar aos desenvolvedores a oportunidade de atualizar seu código, ou ainda sem manter a retrocompatibilidade, softwares inteiros podem falhar.

Os contratos são uma forma de APIs anunciarem exatamente o que produzem e o que recebem, contanto que os desenvolvedores sigam as regras que foram estabelecidas antecipadamente, as coisas continuarão a funcionar da mesma maneira.

Versionamento e Retrocompatibilidade

Retrocompatibilidade parte da necessidade de manter o funcionamento atual do código a partir da implementação de novas features. Este é um termo usado para apontar que os novos recursos, no escopo de software, são compatíveis com os anteriores. Usando um ambiente real como exemplo, o novo Playstation 5 da Sony é retrocompatível com os jogos disponíveis em sua versão anterior o Playstation 4, o que significa que você pode utilizar seus games sem nenhum tipo de impacto na nova versão.

Para lidar de forma mais assertiva com a retrocompatibilidade das APIs criou-se a diretriz de versionamento, onde mantemos o comportamento atual em uma respectiva versão, e implementamos todas as modificações em sua nova versão.

Como um bom exemplo, podemos olhar para um cadastro comum de usuários. Onde uma API recebe os dados usuais para seu processamento.

/v1/user

Quando da necessidade de mudança desse comportamento, por exemplo a inclusão de novos atributos ou de novas respostas desta API, caso não criemos uma nova versão, possivelmente o comportamento dos softwares que consomem esse recurso será impactado.

/v2/user

Subsequentemente existe também a atualização ou reconstrução do contrato desta API. Se define nesta fase também, a validade da API que foi mantida como retrocompatível, a fim de informar a todos os desenvolvedores qual é a validade da versão anterior, e qual é o prazo disponível para a migração.

Paradigmas de API

Então, como você constrói uma API? Existe um conjunto específico de tecnologias e ferramentas que você deve usar? Na verdade não.

Contanto que você use um formato apropriado e coloque um contrato em vigor, você pode usar qualquer paradigma de programação, linguagem ou tecnologia que desejar, até mesmo um arquivo JSON estático em um servidor pode funcionar como uma API, se documentado e publicado corretamente.

Existem, no entanto, algumas diretrizes e especificações que se aplicam às APIs da Web, que conectam um servidor e um cliente pela Web usando o protocolo HTTP. Estas são apenas recomendações sobre coisas como convenções de nomenclatura, quais URLs expor e como transmitir estados de sucesso e erro.

RPC

O paradigma mais antigo era o RPC (Remote Procedure Call), que basicamente funciona como uma função executada em um servidor remoto. Se você quiser criar uma API RPC para adicionar, editar e remover artigos, terá um endpoint em /getArticles para recuperar itens, /addArticle para criar, etc. Como uma função na memória, cada endpoint RPC pode aceitar qualquer número de argumentos.

REST

Uma alternativa mais popular, flexível e usual hoje em dia é o REST (REpresentational State Transfer) e funciona representando entidades como recursos. Em nosso exemplo acima, um artigo seria um recurso, representado em /articles. Para interagir com este recurso, espera-se que o cliente utilize um dos verbos HTTP disponíveis para indicar o tipo de operação - GET para leitura, POST para criação, PATCH ou PUT para atualização e DELETE para exclusão. O REST é caracterizado por utilizar recursos HTTP sempre que possível, como verbos, cabeçalhos e códigos de status.

GraphQL

Um paradigma mais recente que vem ganhando muita força é o GraphQL. Ao contrário de RPC ou REST, GraphQL expõe uma única URL para todas as interações, contando com uma linguagem de consulta personalizada (semelhante ao SQL) para informar ao servidor exatamente quais dados obter e em qual estrutura. É possível que uma única consulta recupere dados de várias coleções de documentos e resolva automaticamente os relacionamentos entre eles. O GraphQL tem um forte foco no desempenho, permitindo que os consumidores recebam apenas os campos de que precisam (embora esse comportamento às vezes seja falsamente retratado como exclusivo do GraphQL, pois o REST também o suporta).

Conclusões

Deste modo, entendemos que APIs são apenas e tão somente mais um tipo possível de interface de comunicação entre máquinas e/ou softwares, estabelecendo formato(s) específico(s) baseado em contratos de trabalho. Em breve vamos discutir por aqui sobre como criar APIs e entrar com mais profundidade no universo dos micro serviços.

Vem comigo, que no caminho eu te explico...

GitHub como plataforma para Bloggar

2021-01-25T19:00:00+00:00

Há um grande número de plataformas disponíveis para você escolher por onde começar um blog. WordPress é provavelmente o mais conhecido dentro todos, afinal ele domina quase 40% de toda a interweb, mas produtos como Medium, Blogger ou Wix, para citar apenas alguns, também são alternativas populares e bastante poderosas.

Todas essas opções nos entregam resultados similares, porém, com algumas pequenas mudanças em seu respectivo funcionamento. Algumas gratuitas, outras pagas ou com inserção de publicidade vinculada aos posts. Algumas cuidam da hospedagem para você, outras precisam da execução de algum software em sua própria infraestrutura. Algumas permitem o uso de domínios personalizados, enquanto outras cobram uma taxa por isso. Parece quase impossível encontrar uma solução que preencha todas as necessidades.

Pensando em como faríamos as coisas por aqui, acabei por esbarrar com uma solução que geralmente não vem à mente quando pensamos em blogs, e que, obviamente, me mantém mais próximo do Maker, do mão na massa/faça você mesmo (DIY – Do It Yourself): GitHub Pages, qualquer repositório no GitHub pode ser transformado em um site associado ao workflow de desenvolvimento mais fácil do que você possa imaginar. Não é preciso executar nenhum software ou preocupar-se com configurações de servidor, sem FTP, SSH ou qualquer outro caminho, simplesmente fazemos push dos conteúdos para o repositório usando arquivos markdown.

O GitHub oferece suporte para um número ilimitado de repositórios de forma gratuita, o que significa que você pode hospedar quantos blogs/sites julgar necessário, gratuitamente, sem publicidade. E ainda permite o uso de seu próprio domínio com HTTPS. Isso não parece um mau negócio, não é?

Em comparação com as plataformas de blog tradicionais

Para prosseguir, é bastante importante apontar algumas diferenças importantes entre as páginas do GitHub e as plataformas de blog mais tradicionais. Muitas dessas plataformas te oferecem um conjunto de interfaces visuais de onde você pode gerenciar seu conteúdo. Você já parou para pensar o que acontece entre a publicação e o lançamento, onde isso está de fato sendo armazenado. Caso o servidor repentinamente não esteja no ar, como você conseguiria acessar seus dados? É fácil extrair o conteúdo se você decidir migra-lo para qualquer outra plataforma?

Nesse sentido, o GitHub Pages é uma opção mais transparente. Por usar o protocolo Git, você pode facilmente manter uma cópia do repositório em seu sistema local ou até mesmo configurar varias espelhos do seu conteúdo em provedores diferentes (como Bitbucket e GitLab), o post é armazenado em arquivos simples, sem interface mágica - ele simplesmente está lá.

Obviamente, isso também torna o GitHub Pages uma solução mais básica. Por exemplo, sem uma solução de gerenciamento de conteúdo pronta para seu uso (embora por meio dos pluggins você possa ter um) e, por baixo do capô, representa paradigmas totalmente diferentes do WordPress. Não tendo essencialmente um sistema onde pode-se buscar, gerar e manipular conteúdos dinâmicos em cada solicitação, o GitHub Pages permite apenas que você entregue arquivos estáticos, o que significa que suas páginas devem ser geradas com antecedência.

Esse paradigma, certamente, não é a escolha óbvia para certos aplicativos, mas para um blog geralmente é uma ótima opção. O conteúdo não deve mudar a cada poucos segundos e geralmente não precisa de geração automática, então, torna-se perfeitamente possível construir um conjunto de páginas estáticas toda vez que você faz uma nova postagem. Quando prontas, basta uma nova publicação (push) e seu conteúdo estará disponível no seu blog com GitHub em segundos.

Introdução às páginas do GitHub

Para começar, primeira vamos construir um repositório. Acesse https://github.com/new e você encontrará uma tela como está.

Depois de escolher um nome e uma descrição para seu repositório, selecione a opção Criar repositório. Caso tudo corra bem, você será direcionado à sua nova página de repositório. Nada muito diferente até aqui além do endereço/url de seu novo repositório. Anote-o, vamos usá-lo em um minuto.

Na sequência vamos construir nossa primeira página. Crie um novo diretório e em seguida crie um arquivo chamado index.html, com algum HTML simples.

<!DOCTYPE html>
<html>
<head>
  <title>Meu novo blog</title>
</head>
<body>
  <h1>Bem-vindo</h1>
  <p>É aqui que tudo começa!!!</p>
</body>
</html>

Agora vamos de publicá-lo. Existem várias maneiras de interagir com seu repositório. Para esse tutorial, vamos com o bom e velho terminal, já que usaremos uma lista simples de comandos. Se for de sua preferencia, use uma interface gráfica como o GitHub Desktop.

Abra uma janela de terminal e navegue até o diretório no qual você salvou o arquivo.

cd /path/to/your/directory

Uma vez lá, digite os seguintes comandos:

git init
git remote add origin git@github.com:daniloval/meu-blog.git (replace this with your repository address)
git add index.html
git commit -m "Create first page"
git push origin master

O que fizemos aqui? Estamos iniciando um novo repositório Git no diretório que criamos e, em seguida, vinculando-o ao repositório GitHub. Na sequência, estamos adicionando index.html à lista de arquivos a serem publicados, enviando-os com uma mensagem que descreve a operação e, finalmente, enviando-os para o repositório remoto.

Se você atualizar a página do repositório no GitHub, deverá ver agora o arquivo que acabamos de enviar.

Por fim, precisamos habilitar as páginas do GitHub para este repositório. Na tela mostrada acima, clique em Configurações e role para baixo até a seção Páginas do GitHub. No seletor de origem, selecione master como a ramificação a partir da qual construir e clique em Salvar.

Depois disso, você verá uma mensagem confirmando que seu site está pronto para ser publicado e indicando uma URL de acesso. Se você navegar até ela, poderá ver seu novo site.

Inserindo o Jekyll na jogada

Criamos uma solução bastante funcional, mas na realidade ainda não muito prática. Mesmo sendo bom gerar manualmente as páginas HTML para este site de exemplo, não é um processo sustentável para um projeto de tamanho razoável.

Por exemplo, imagine que queremos criar uma página de destino para o nosso blog onde todas as postagens são listadas. Para cada entrada, queremos exibir o título, um trecho e um botão “Leia mais” que, quando pressionado, leva as pessoas para outra página onde a postagem completa é exibida. Isso significa que criar ou atualizar uma postagem de repente envolve a edição de dois arquivos. Uma vez que adicionamos coisas como paginação, categorias ou um agregador de tags, esse número começa a crescer e se torna incontrolável.

Ainda assim, se você desejar migrar seu conteúdo para um plataforma diferente no futuro, você certamente deseja que ele esteja em um formato e estrutura o mais bruto possível, separado de qualquer implementação ou tecnologia. Provavelmente, armazená-lo em arquivos HTML que estão inchados com marcações de apresentação não é a melhor maneira de fazer isso.

É aqui que entram os geradores de sites estáticos, que, nada mais são que softwares que transformam o conteúdo em vários formatos e criam páginas HTML. Isso significa pegar um diretório cheio de postagens de blog, em formato como Markdown, e gerar landing pages, páginas completas de post, paginação, páginas de agregação de tags, categorias, pesquisas e qualquer outra coisa que você possa imaginar. Tudo o que você precisa fazer é executar um comando (geralmente chamado de etapa de construção) e um site inteiro será gerado automaticamente para você.

Existem centenas de geradores de sites estáticos para que você escolha a melhor opção, neste post, vamos nos concentrar particularmente no Jekyll. A razão para isso é que ele possui status especial nas páginas do GitHub. Enquanto que com qualquer outro gerador de sites estáticos você precisa executar a etapa de compilação em sua máquina e apenas depois disso enviar os arquivos resultantes para seu repositório, com o Jekyll você pode simplesmente enviar os arquivos de origem e o GitHub Pages irá executar a etapa de compilação para você, publicando os arquivos resultantes automaticamente.

Para adicionar o Jekyll ao nosso blog, primeiro devemos deletar o arquivo index.html que criamos anteriormente.

rm -rf index.html

Em seguida, instale o Jekyll e diga a ele o nome do diretório onde deve criar o site. Devemos usar o diretório que criamos anteriormente, pois já está vinculado ao repositório GitHub. Acrescentei o parâmetro -f para evitar que o Jekkyl nos de um warning ou error sobre a existência do diretório com o nome no blog meu-blog.

gem install bundler jekyll
jekyll new -f meu-blog

Para construir o site, execute jekyll serve. Ele irá gerar todos os arquivos HTML e criar uma URL onde o site estará disponível. Cada vez que você modificar um arquivo, o site será regenerado e o URL refletirá suas alterações. Adicionado o parâmetro -l abaixo, ativamos a opção refresh/reload automático e suas alterações refletirão na URL sempre que você salvar qualquer alteração.

Obs. essa opção não se aplica ao arquivo config e infelizmente você terá de recompilar o Jekyll sempre que estiver trabalhando em configurações.

bundle exec jekyll serve --livereload

bundle exec jekyll serve -l

Se você estiver usando uma URL github.io (por exemplo username.github.io/repositorio), você deve dizer ao Jekyll que o caminho base é /repositorio. Para fazer isso, abra o arquivo _config.yml e defina a propriedade baseurl como /repositorio (no meu caso, meu-blog).

Quando estiver pronto para colocar seu novo site Jekyll no ar, você pode executar:

git add .
git commit -m “Add Jekyll”
git push origin master

Em alguns segundos, você poderá atualizar o URL do GitHub e ver o seu novo site com tecnologia Jekyll em ação.

Escolhendo um tema para seu novo site em Jekyll

Para alterar a aparência do seu site, você pode experimentar diferentes temas. Uma busca rápida por “temas jekyll” levará você a diversas opções de temas, com diferentes layouts e estilos. Quando você encontrar um de que goste, poderá ativá-lo adicionando-o ao arquivo de configuração.

Como mais uma opção, você também pode buscar pelas várias possibilidades do GitHub. Para experimentá-las, vá para Configurações, busque por Páginas do GitHub e pressione a opção Alterar tema. Você verá uma prévia de cada tema disponível e, assim que encontrar um de que goste, clique em Selecionar tema e seu site será atualizado de acordo.

Hello World!

2021-01-14T23:00:00+00:00

#include <stdio.h>

int main() {
    printd("Hello world.");
    return 0;
}

É assim que tudo começa no universo de desenvolvimento de software.

Mais um, dentre milhares de #helloworld, construídos ou criados diariamente por quem resolve se aventurar nesse mundo, seja como hobby, como um novo aprendizado, como, de fato um novo começo, uma nova chance de levar sua obra ao mundo.

Iniciamos esse projeto em 2021, com intuito de compartilhar e criar grandes histórias, muito conteúdo e nos divertir, ~~mas isso tudo é pauta para outra conversa~~.

Vem comigo, que no caminho eu te explico...