DNS: o que é e como funciona?

Hoje gostaria de compartilhar com vocês o processo de deploy de uma aplicação clássica quando se fala em orquestração de containers. Especificamente, vou mostrar como se dá o processo utilizando a orquestração nativa do Docker, que é o Docker Swarm.

O app em questão é um sistema de votação, cuja arquitetura está representada abaixo e explicada em seguida:

![](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/tech-notes-assets/architecture.png)

## Fluxo

O ponto de entrada do sistema é uma aplicação web feita em Python onde o usuário pode responder a uma pesquisa (imagine a votação do BBB, por exemplo).

Essa informação é colocada em uma fila no `redis`, para que não haja um fenômeno conhecido como [race condition](https://www.youtube.com/watch?v=RY_2gElt3SA), em que há uma tentativa de acessar e alterar a mesma informação, levando a inconsistências.

Os votos da fila são processados de forma ordenada e sincronizada por um serviço em .NET que os armazena num banco de dados PostgreSQL.

Por fim, os dados são acessados por uma aplicação web em Node.js que as lê diretamente do banco.

São um total de 5 serviços que são necessários para que o sistema funcione de forma correta. Um excelente exemplo para aprender sobre orquestração de containers!

## Deploy com Docker Swarm

### Networking

O ponto mais importante para fazer o deploy desse sistema é que devem existir duas redes distintas. A rede que chamaremos de `backend` é interna e serve para isolar o banco de dados. Os serviços Node e .NET ficam nessa rede para ter acesso ao mesmo. A porta `5001` é exposta para que os administradores do sistema tenham acesso ao resultado.

A rede `frontend` expõe a porta `80` para que os usuários possam responder à pesquisa. Nessa rede está também o serviço do Redis, que é para onde a aplicação web manda os resultados.

O "worker", que é o responsável por passar os votos do Redis para o banco de dados, tem que estar, claro, nas duas redes.

### Subindo os serviços

_Aqui vamos subir os serviços "manualmente" utilizando o `docker service create` do swarm. Isso é um ótimo exercício para entender como as coisas acontecem por trás dos panos, mas em uma aplicação real automatizamos esse processo usando um arquivo compose e o comando `docker stack deploy`._

O primeiro passo para subir os serviços é criar as redes apropriadas.

Em seguida, de acordo com o fluxo descrito anteriormente, devemos começar a subir os serviços pelo banco de dados Postgres, depois o Redis, o worker e, por fim, as aplicações web. Veja que começamos pela parte de baixo do diagrama e escalamos conforme as dependências.

Dessa forma, alcançamos nosso objetivo com os seguintes comandos:

```bash
docker network create --driver=overlay frontend
docker network create --driver=overlay backend

docker service create \
    --name db \
    --network backend \
    --replicas 1 \
    --mount type=volume,source=db-data,target=/var/lib/postgresql/data \
    -e POSTGRES_HOST_AUTH_METHOD=trust \
    postgres:9.4

docker service create \
    --name redis \
    --replicas 1 \
    --network frontend \
    redis:3.2

docker service create \
    --name worker \
    --replicas 1 \
    --network backend \
    --network frontend \
    bretfisher/examplevotingapp_worker

docker service create \
    --name vote \
    --replicas 3 \
    --network frontend \
    -p 80:80 \
    bretfisher/examplevotingapp_vote

docker service create \
    --name result \
    --replicas 1 \
    --network backend \
    -p 5001:80 \
    bretfisher/examplevotingapp_result
```

### Compose e docker stack

Em uma aplicação real, como dissemos, a ideia é automatizar o processo com arquivo compose e `docker stack deploy`. E a boa notícia é que o processo é muito simples. Se você já conhece e usa o Docker Compose no ambiente de desenvolvimento, a ideia é bastante similar. A diferença é que agora o arquivo `.yml` vai ter configurações específicas para o Swarm.

Depois de pronto o arquivo de configuração, subimos o serviço com um comando:

```bash
docker stack deploy -c config.yml
```

Para o exemplo acima, nosso arquivo de configuração ficaria da seguinte forma:

```yaml
version: "3.9"

services:
  redis:
    image: redis
    networks:
      - frontend

  db:
    image: postgres:9.4
    environment:
      POSTGRES_HOST_AUTH_METHOD: "trust"
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend

  vote:
    image: bretfisher/examplevotingapp_vote
    ports:
      - 80:80
    networks:
      - frontend
    deploy:
      replicas: 2

  result:
    image: bretfisher/examplevotingapp_result
    ports:
      - 5001:80
    networks:
      - backend

  worker:
    image: bretfisher/examplevotingapp_worker
    networks:
      - frontend
      - backend
    deploy:
      replicas: 2

networks:
  frontend:
  backend:

volumes:
  db-data:
```

E é isso! Com esse exemplo, que é baseado no curso de Docker do [Bret Fisher](https://www.udemy.com/course/docker-mastery/) - recomendo muito -, fica bem claro que a orquestração nativa do Docker é bastante versátil e poderosa, sendo ao mesmo tempo muito simples e intuitiva.

_Cheers!_


Orquestração com Docker Swarm

Na parte III do Clean Architecture, somos apresentados aos famosos princípios SOLID. Esses princípios foram formalmente apresentados pela primeira vez no livro _Agile Software Development, Principles, Patterns and Practice_ em 2002 e são trazidos aqui novamente no contexto mais amplo da arquitetura.

### Arquitetura: uma discussão de múltiplos níveis

É interessante notar como o livro constrói uma progressão no _nível hierárquico_ das entidades e elementos alvo da discussão sobre arquitetura.

No nível mais baixo, está o "clean code" ou as boas práticas de programação. Coisas como escrever funções com uma única funcionalidade e com menos parâmetros, saber nomear variáveis, refatorar código difícil de entender em uma estrutura clara. Isso é mencionado, mas não discutido neste livro, porque existe um outro de mesmo nome inteiramente dedicado ao assunto, o _Clean Code_.

O livro segue com uma discussão dos paradigmas de programação e sua importância para arquitetura e, em seguida, somo apresentados aos princípios de design de "classes". A palavra "classe" aqui se refere a um agrupamento de dados e funcionalidades relativas a esses dados - e não necessariamente às "classes" de linguagens orientadas a objetos. Portanto, esse princípios são aplicáveis de forma ampla e não pressupõe o uso OO. Poderia-se usar o termo _componente_, porém o autor reserva esse termo para entidades de nível hierárquico maior, como veremos mais adiante.

### O que são e qual o objetivo dos princípios SOLID

Os princípios SOLID são uma série de práticas que têm o intuito de melhorar a estrutura, confiabilidade, testabilidade e facilidade de manutenção do código que escrevemos.

Especificamente, o objetivo desses princípios é o de combater 7 tipos possíveis de falhas identificadas pelo autor. Os três defeitos ou falhas principais que nos interessam de perto são explicados abaixo e os demais são apenas mencionados em seguida.

1. **Rigidez** - é a dificuldade fazer mudanças no código, porque uma alteração em uma parte do sistema nos força a fazer mudanças em várias outras partes;

2. **Fragilidade** - é quando mudanças em uma parte do programa fazem o sistema quebrar em partes que, conceitualmente, não têm nada a ver a parte que foi alterada;

3. **Imobilidade** - é a dificuldade extrair componentes reutilizáveis do sistemas porque esses componentes estão fortemente acoplados.

Os demais são

4. **Viscosidade**;
5. **Complexidade desnecessária**;
6. **Repetição desnecessária**;
7. **Opacidade**.

Com essas falhas de design em mente, vamos ver de que forma esses princípios nos ajudam a combatê-las.

Antes de tudo, é bom enfatizar que o nome dos princípios e a sua definição são apenas uma forma de nos remeter ao que eles se referem. Para entendê-los precisamos investigá-los a fundo.

### O princípio da Responsabilidade Única

O primeiro princípio é o princípio da responsabilidade única e ele que diz que

> Uma entidade deve ter um único motivo para ser alterada

Ou, alternativamente:

> Uma entidade deve ter um único eixo de mudança

Primeiro vamos raciocinar de uma maneira abstrata e em seguida vamos analisar dois exemplos.

Se uma classe tem mais de uma responsabilidade, essas responsabilidades se tornam acopladas. Isso significa que, se precisarmos fazer mudanças em uma das atribuições desta classe, essa mudança pode impactar as outras responsabilidades/atribuições. Confuso? Vamos ver como isso acontece na prática.

### Exemplo 1: Apresentação vs. Lógica

![](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/articles-assets/SRP-6)

Dê uma olhada nesse diagrama. Ele representa um programa em que a classe Retângulo é usada tanto por um módulo de geometria computacional, quanto por um módulo gráfico. Essa dependência é representada pelas setas que saem das caixas, que, por sua vez, representam os respectivos componentes.

Observe que nossa classe Retângulo tem a dupla responsabilidade de fazer os cálculos geométricos (utilizada pelo módulo de geometria computacional) e de desenhar-se (utilizada pelo módulo gráfico).

Isso tem consequências bastante negativas para o projeto. Em primeiro lugar, perceba que, nesse modelo, o módulo de geometria computacional passa a ter uma dependência no módulo gráfico, apesar de ele jamais precisar renderizar um retângulo.

Além disso, se mudanças nos requerimentos do módulo gráfico necessitarem de alterações da classe Retângulo, essas mudanças podem impactar a o módulo de geometria computacional. E assim, no mínimo, nós precisaríamos compilar novamente (no caso de linguagens compiladas, claro) e testar novamente um módulo não relacionado com nossa mudança.

Fica claro que esse acoplamento de responsabilidade é bastante nocivo para a nossa aplicação.

Observe agora este design alternativo.

![](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/articles-assets/SRP-7)

Com esse modelo, mudanças feitas na renderização do retângulo jamais podem afetar nosso módulo de geometria computacional.

### Exemplo 2: Persistência vs. Regras de Negócio

Um exemplo mais realista e bastante corriqueiro é o do acoplamento de regras de negócio com a camada de persistência da aplicação.

![](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/articles-assets/SRP-8)

Nesse diagrama, a classe Employee tem a dupla responsabilidade de guardar as regras de negócio e de persistir os dados na camada de persistência. Dessa forma, a classe depende diretamente da camada de persistência. Isso significa que mudanças nesse componente podem afetar diretamente as regras de negócio, o que é absurdo.

Novamente, um modelo melhor para essa situação é o que consta no diagrama abaixo.

![](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/articles-assets/SRP-9)

Aqui separamos completamente as responsabilidades de guardar as regras de negócio e de persistência utilizando inversão de dependência.

### A interconexão dos princípios

Como veremos em seguida, os princípios SOLID são altamente dependentes um dos outros. Você acabou de testemunhar como usamos inversão de dependência para separar responsabilidades. Isso acontece com frequência é um aspecto bastante positivo, porque boas práticas vão puxando boas práticas.

E acontece que o recíproca frequentemente é verdadeira: os maus padrões e as más práticas nos levam para um buraco negro do qual é bastante difícil sair. Essa é uma das falhas de design que foram mencionadas e que fica explicada aqui: trata-se da **viscosidade**, que é quando se tem um projeto em que é mais fácil fazer a coisa "errada" do que a coisa "certa".

E por hoje é só. Na próxima publicação, discutiremos um dos mais importantes princípios: o princípio aberto-fechado.

Vejo vocês lá, _cheers_!

_Este artigo é parte da série **Clean Architecture** baseada no livro de mesmo nome do Uncle Bob. Confira os demais:_

**Seguinte:** Hold on tight 🥰

**Anterior**: [Paradigmas de programação e Arquitetura](https://www.felipebarbosa.dev/artigos/arquitetura-e-design-de-software:-clean-architecture-parte-3)


Princípios SOLID: o princípio da Responsabilidade Única

Eu tenho lido mais do que escrito nesses últimos dias, mas hoje vamos tentar diminuir a distância entre esses dois processos, já que esse último encontra-se consideravelmente atrasado em relação ao primeiro 😂.

Na parte 3 do livro, Uncle Bob discute os blocos que constroem qualquer sistema: código. Para além de uma sintaxe particular, toda linguagem de programação adota um ou mais **paradigmas**. E é sobre esse fundamento e sua importância para a arquitetura de que trata essa seção.

A essa altura, fiquei um pouco descrente: imaginei que viria por aí mais do mesmo sobre a velha discussão do assunto. Mas eu me surpreendi bastante. Os quatro capítulos que vieram em seguida trouxeram uma abordagem única que eu nunca tinha visto antes. E com zero enrolação: num livro sobre arquitetura de software, o autor sabe que você, leitor, está familiarizado com esses paradigmas. O que ele traz de forma bastante direta é uma análise sobre:

- a _motivação_ por trás de cada um, isto é,
- qual problema cada paradigma tentava resolver dentro do contexto histórico em que foi criado e;
- qual a relevância disso para arquitetura.

Esse entendimento realmente faz diferença quando nos perguntamos qual melhor maneira de resolver determinado problema.

Além disso, Uncle Bob desmistifica alguns pontos dentro deste tópico e faz algumas observações notáveis que podem ser bastante surpreendentes.

Por exemplo, geralmente quando se pensa em OOP (_Object Oriented Programming_), a primeira coisa que vem à mente são classes. Por conseguinte, frequentemente essas duas ideias são associadas no pensamento de que só é possível escrever código OO com esse recurso. Quando falo de “classe” me refiro aos artefatos usados nas linguagens de programação para implementar esse conceito (pense em uma declaração de classe em Java ou em TypeScript). Entretanto, não é bem assim.

No JavaScript, por exemplo, é perfeitamente possível implementar as ideias e conceitos do paradigma sem jamais escrever uma classe (usando funções e _closures_). Falo do JavaScript porque é a linguagem que eu mais domino hoje (junto com o TypeScript), mas isso provavelmente vale para as demais: Uncle Bob chega ao extremo de mostrar como alcançar implementações das ideias do OO em C! Sim, C!

Claro, as linguagens modernas trazem formas infinitamente mais _convenientes_ de fazer isso. O ponto aqui é o de que, ao invés de se prender aos artefatos específicos utilizados nas linguagens que adotam o paradigma X ou Y, devemos, ao contrário, entender qual o problema que cada paradigma tenta resolver e quais são as ideias e conceitos das quais cada um se vale para tanto.

Dessa forma, podemos decidir com mais confiança sobre o uso de um ou de outro quando nos deparamos com os problemas. Isso porque a maioria das linguagens de programação modernas são multiparadigma e temos a opção de escolher qual melhor abordagem em cada situação. Ou podemos escolher uma linguagem específica que adota um paradigma de forma mais inflexível (Haskell é uma que vem à mente) se soubermos que aquele é o paradigma ideal para o escopo do problema que estamos tentando resolver.

De todo modo, ao final dessa parte do livro, você vai sair com um aprofundamento nesse tema que você talvez nem achasse que precisava (meu caso).

### …

A abordagem do Uncle Bob é começar dos fundamentos e ir construindo o conhecimento até chegar nas discussões amplas e estratégicas. Depois de falar sobre paradigmas de programação, a sessão seguinte fala sobre princípios usados para construir e interconectar os componentes de um sistemas. Esses princípios são aqueles referidos pelo famoso acrônimo **SOLID**.

Essa discussão, entretanto, nos interessa de perto e pretendo fazê-la de forma minuciosa nos próximos artigos.

Vejo vocês lá!

_Este artigo é parte da série **Clean Architecture** baseada no livro de mesmo nome do Uncle Bob. Confira os demais:_

**Seguinte:** [Princípios SOLID: o princípio da Responsabilidade Única](https://www.felipebarbosa.dev/artigos/principios-solid:-o-principio-da-responsabilidade-unica)

**Anterior**: [Arquitetura: o bem maior](https://www.felipebarbosa.dev/artigos/arquitetura-e-design-de-software:-clean-architecture-parte-2)


Paradigmas de programação e Arquitetura

Em primeiro lugar, eu realmente gosto muito do estilo de escrita do Uncle Bob.

Não é à toa que ele tem esse apelido: ao longo da leitura você tem aquela sensação intimista de estar falando com um velho (e sábio) tio que está tentando colocar algum juízo na sua cabeça e colocar você no caminho certo.

No prefácio e na introdução do livro, U.B. trás uma discussão bastante interessante sobre o por quê que arquitetura é um tópico universal e por que se trata de um tópico que é tão essencial para a computação há 50 anos, desde o surgimento das primeiras máquina programáveis, quanto é hoje, quanto (provavelmente) será daqui a mais 50 anos, independentemente dos novos tipos de tecnologias que possam surgir.

### O impacto **real** da arquitetura

No capítulo 1, entramos numa discussão prática da importância da arquitetura no mundo real. E nada pode ser mais brutalmente concreto do que isto: rentabilidade, custo ou, em outras palavras, dinheiro.

Nesse capítulo ele apresenta um estudo de caso de uma empresa. Acompanhamos a evolução de um projeto específico analisando os seguintes parâmetros: produtividade, custo e recursos dispendidos longo do tempo. Esse estudo trás uma realidade brutal que, se você é desenvolvedor, já experimentou em algum momento de sua carreira.

Os dados apresentados - que eu não posso reproduzir aqui sem violar alguma lei de direitos autorais - mostram que, no início do projeto, que começa com um número pequeno de desenvolvedores, a produtividade é alta e novas funcionalidades são adicionadas no sistema de forma rápida e ágil. "Produtividade" aqui é medida simplesmente pelo número de linhas de código adicionadas ao projeto. Uma abordagem simplista, mas que serve perfeitamente para demostrar o problema.

Ao longo da evolução do projeto, apesar de o número de desenvolvedores estar sempre aumentando, a produtividade começa a cair vertiginosamente e os custos por linha de código começam a subir na mesma proporção.

Por que? Esse é o sinal claro de uma bagunça! Sejamos francos: você e eu já estivemos aí. É aquele situação em que a menor mudança na base de código pode gerar uma grande dor de cabeça. E embora não seja impossível fazer a mudança, frequentemente ela se torna **impraticável**, porque a alteração desse componente tem o potencial de afetar o sistema como um todo.

#### ...

Se nós vivêssemos em um mundo estático, isso não seria um problema: faríamos nossa grande e gigantesca bagunça _funcionar_ e o problema estaria resolvido para sempre.

Porém vivemos em um mundo dinâmico de constante mudanças onde os requerimentos e especificações do sistemas precisam se adaptar a esse cenário. E se continuarmos construindo bagunças é isto que nós teremos: um sistema que eventualmente vai se tornar inútil por não atender mais às demandas do mundo real e por ser, não impossível, mas absolutamente _impraticável_ de mudar.

O que nos leva ao capítulo 2: uma fábula de dois valores (tradução livre).

### O bem maior

Aqui temos a ideia de que software pode ser enxergado através da dicotomia de dois valores ou duas virtudes: **funcionalidade** e **estrutura**.

Funcionalidade diz respeito à capacidade do software de realizar o que ele foi projetado para fazer.

Estrutura ou arquitetura se refere à articulação dos componentes de um sistema. Em outras palavras, pode ser entendido como uma medida:

- do quanto ele é resiliente a mudanças;

- do quanto ele é testável;

- do volume de esforço humano que é necessário para fazer com que esse sistema _continue_ a entregar valor aos seus usuários ao longo do tempo.

Funcionalidade é primeira coisa que a maioria das pessoas enxergam no software. Afinal, esse é o propósito _imediato_: resolver o problema que está na mesa. Entretanto, se esse for o único objetivo que temos em mente, mais cedo do que se imagina vamos construir para nós mesmos uma grande armadilha: a princípio pode parecer que estamos avançando rápido, porém, **rapidamente**, o processo que nos levou até ali vai nos frear de forma brutal.

O que a maioria das pessoas tende a pensar é que **estrutura** só é uma virtude válida a ser considerada em projetos grandes. Mas o que o U.B. traz aqui - e o que eu mesmo já experienciei por conta própria - é que **estrutura** é a a virtude primordial do software em qualquer contexto.

E, sinceramente, eu poderia gastar várias linhas tentando explicar o por que disso, mas esse é o tipo de coisa que você só consegue absorver tendo vivido o processo na pele. E esse processo é mais ou menos o seguinte:

- Escrever "bagunças" que te levam de A a B rapidamente (se a distância entre A e B for _bem_ pequena), mas que têm um custo infinito para te levar de B a C (por menor que seja);

- Se frustrar com essa forma de construir;

- Buscar formas alternativas (melhores);

- Sentir atrito e desconforto ao tentar por em prática o que você aprendeu;

- Começar a entender e enxergar valor na arquitetura, inclusive no aspecto produtividade.

Não me entenda mal: apesar de já ter vivido esse processo em algum grau, estou longe de estar "no fim" dessa jornada, muito pelo contrário (de outra forma não haveria sentido em ler esse livro, haha).

Mas quanto mais eu projeto e construo software, mais eu tendo a chegar nesse consenso... Sobre que arquitetura é, de fato, o bem maior.

E assim terminamos a primeira parte do livro.

#### ...

Espero que a essa discussão desperte o interesse por arquitetura. Lembrando que estou sempre disponível para falar/discutir a respeito. Não hesite em entrar em contato!

Talvez para os próximos capítulos eu resolva trazer conteúdo em outros formatos. Tenho a impressão de que talvez consiga me aprofundar mais nas discussões do livro trazendo o conteúdo em formato de vídeo.

Bem, de toda forma, é isso!

_Este artigo é parte da série **Clean Architecture** baseada no livro de mesmo nome do Uncle Bob. Confira os demais:_

**Seguinte:** [Paradigmas de programação e Arquitetura](https://www.felipebarbosa.dev/artigos/arquitetura-e-design-de-software:-clean-architecture-parte-3)

**Anterior**: [Arquitetura e Design de Software: Clean Architecture](https://www.felipebarbosa.dev/artigos/arquitetura-e-design-de-software:-clean-architecture-parte-1)


Arquitetura: o bem maior

_Arquitetura é sobre como construir soluções que não só funcionam (agora), mas que continuarão a funcionar e entregar valor aos seus usuários de forma contínua, escalável, testável, que seja fácil de manter e resiliente a mudanças._

Depois de ter lido livros como **Clean Code** e **Node.js Design Patterns** há algum tempo e de ter trabalhado em projetos o suficiente para me convencer de que eu tenho uma proficiência mínima em escrever código com um padrão de qualidade bastante razoável, o passo natural seguinte foi o de me debruçar sobre um dos tópicos mais importantes e bonitos da engenharia de software: arquitetura.

Depois de alguma pesquisa procurando os recursos certos por onde iniciar essa jornada, encontrei um indivíduo chamado [Khalil Stemmler](https://khalilstemmler.com/).

Khalil é um engenheiro de software muito talentoso que dedicou os últimos anos de sua carreira ao ensino e aprendizado do universo da arquitetura. O seu livro [Solid - The Software Design and Architecture Handbook](https://solidbook.io/) é um _excelente_ ponto de partida para iniciar os estudos na área, principalmente para quem vem do ecossistema Node: o livro tem foco total em arquitetura com Node e TypeScript!

Porém, apesar de ir bastante longe em tópicos como DDD, testes, arquitetura em camadas e tantos outros, se você quiser se aprofundar de verdade no assunto ainda vai ter que recorrer a livros específicos em cada um dos tópicos que compõe essa área.

Depois de ter concluído a leitura do mesmo, fiquei na dúvida sobre qual ler em seguida. DDD é uma abordagem que me interessou bastante, então um bom candidato seria o clássico livro do Eric Evans.

Porém DDD é uma abordagem específica e eu senti que queria uma visão mais ampla.

Por isso me decidi pelo **Clean Architecture** do Uncle Bob. Já tinha lido o **Clean Code** e eu realmente gosto bastante do estilo dele. Lendo o preâmbulo do livro fiquei ainda mais certo de que era a escolha certa.

Porém dessa vez resolvi fazer algo diferente. Ao invés de trabalhar no livro sozinho de forma isolada decidi que seria bastante interessante compartilhar meu progresso ao longo do mesmo. Portanto, à medida que for avançando no livro pretendo trazer notas, comentários, reflexões, aprendizados e discussões sobre o conteúdo abordado. E esse é o pequeno anúncio que eu queria trazer com esse post.

Na verdade, minha intenção de médio prazo é criar uma pequena comunidade de estudos avançados em arquitetura e design de software. Porque aprender de forma coletiva é sempre mais construtivo do que aprender sozinho!

Se você se interessa por essa área, não hesite em entrar em contato comigo!

É isso! Fiquem seguros e sãos. Vejo vocês em breve.

_Este artigo é parte da série **Clean Architecture** baseada no livro de mesmo nome do Uncle Bob. Confira os demais:_

**Seguinte:** [Arquitetura: o bem maior](https://www.felipebarbosa.dev/artigos/arquitetura-e-design-de-software:-clean-architecture-parte-2)


Arquitetura e Design de Software: Clean Architecture

### Introdução

_Full-text search_ refere-se a um mecanismo que permite buscar palavras, termos, expressões e frases em grandes volumes de documentos de maneira rápida e eficiente. Trata-se de um mecanismo bastante sofisticado, que é bem diferente de uma simples busca textual que pode ser feita no navegador ou em um documento (com o famoso atalho `Ctrl + F`). Para entender como esse tecnologia funciona, vamos compará-la a uma busca comum.

### Como um resultado é encontrado

Em primeiro lugar, existe uma diferença fundamental na forma como resultados (_match_ ou _matches_ no plural) são encontrados.

Enquanto que numa busca textual simples é necessário uma correspondência exata entre as palavras, quando estamos utilizando _full-text search_ (FTS), as diversas flexões de uma mesma palavra são consideradas uma só. Por exemplo, as flexões de um adjetivo como _revolucionário, revolucionária, revolucionários, revolucionárias, revolucionaríssimo_ são entendidas como correspondência para a palavra _revolucionário_. Assim, se você estiver procurando por uma correspondência como "invenção revolucionária" no texto, independentemente de qual flexão esteja empregada você vai achar um resultado.

Isso acontece porque, quando usamos FTS, antes que consultas possam ser feitas, os documentos, textos, etc., são pré-processados de forma a normalizá-los e otimizá-los para busca. Isso significa, por exemplo, que apenas os lexemas ([mais ou menos equivalente ao "radical"](#distinção-entre-lexema-e-radical-segundo-o-chat-gpt3)) das palavras são mantidos. Outra transformação aplicada é a de remover coisas com artigos _o, a, os, as, uns, umas_, preposições _de, para_, etc, de forma que um título como "O Poderoso Chefão" possa ser encontrado com uma busca de "poderoso chefão".

Além dessa normalização, os lexemas são indexados, isto é, uma estrutura de dados apropriada é utilizada para indicar todos os lexemas presentes em um texto e sua correspondente posição no mesmo.

Por fim, mas não menos importante, o FTS traz a ideia de **relevância** de um resultado: se, por exemplo, em um texto são encontradas 10 ocorrências de um termo, pode-se dizer que esse resultado é mais relevante do que um outro em que apenas uma ocorrência é encontrada. Ou ainda: se o termo é encontrado no título de um artigo, ao invés de no corpo, é razoável imaginar que esse resultado seja mais _relevante_. Discutiremos melhor como isso funciona mais adiante.

Com essas e outras ideias e otimizações, FTS torna-se uma ferramenta bastante poderosa, como veremos a seguir.

### Como FTS se compara a outras ferramentas

Ainda assim, poderia-se argumentar que existem ferramentas elaboradas para buscas textuais que não se limitam aos cenários simples descritos anteriormente.

Uma dessas que é bastante poderosa e bem conhecida por desenvolvedores são as chamadas*regular expressions* (regex). Para os não familiarizados, regex são um mecanismo que usa uma sintaxe específica para buscas textuais avançadas.

Por exemplo, a expressão regular

```plaintext
/.*\?\!$/
```

Serve para procurar todas as frases de um texto que terminam em "!?".

O problema é que não é razoável pré-conceber todas as variações de termos que se pode querer procurar em documento e transformá-los em regex para futuras consultas.

Outra questão envolvida diz respeito a performance: por mais que expressões regulares se valham de algoritmos sofisticados que buscam otimizar o máximo possível a busca, esse mecanismo ainda assim precisa percorrer todo o texto em busca de correspondências, o que, para grandes volumes, não é nada eficiente.

Existe ainda o operador `LIKE` no mundo do SQL que serve para buscas textuais. Porém, novamente uma expressão como

```sql
SELECT body from documents WHERE body LIKE '%crescimento%';
```

Só consegue achar uma correspondência exata da palavra "crescimento" (e não _cresceu_, _crescendo_, etc).

Além dessas limitações, nenhum desses mecanismos possui a ideia de relevância de um resultado discutida mais cedo.

Uma vez que entendemos o que é e por que utilizamos FTS, vamos ver como podemos usar esse mecanismo no postgresql.

### Full-text search no PostgreSQL

Existem softwares especiais que são utilizados exclusivamente com o objectivo de realizar buscas do tipo FTS. Um bom exemplo é [ElasticSearch](https://www.elastic.co/what-is/elasticsearch).

Porém, o sistema do Postgres é perfeitamente capaz de fazer esse tipo de busca, como mostraremos a seguir. Apesar de não ter todas as funcionalidades de um sistema como o ElasticSearch, a implementação nativa de FTS é boa o suficiente para diversos casos de uso - e tem a vantagem de ser bem mais simples.

### A base do FTS no Postgres: `tsvector` e `tsquery`

As estruturas de dados utilizadas no Postgres para trabalhar com FTS são basicamente duas:

- `tsvector`
- `tsquery`

Como já vimos, FTS não trabalha com _strings_ comuns para fazer consultas, então essas duas estruturas de dados especiais são necessárias. Vejamos como elas funcionam.

`tsvector` pode ser entendido como um vetor de lexemas junto com suas correspondentes posições no textos. É contra essa estrutura de dado que iremos fazer nossas consultas.

`tsquery` é um tipo de estrutura de dado usado para fazer buscar contra o `tsvector`. Com ela podemos criar buscar de frases, termos e expressões, como veremos adiante.

Com esses dois tipos de dados, uma busca pode ser feita com a seguinte sintaxe:

```sql
SELECT ts_vector @@ ts_query;
```

A consulta acima retorna um _boolean_ que indica que a expressão indicada foi encontrada no vetor.

### Utilizando ts_vector e ts_query

As duas estruturas descritas acimas são bastantes específicas e meticulosamente desenhadas. Felizmente, na prática nós não as criamos do zero, mas usamos texto convencional para interagir com elas.

Para criar uma `ts_vector` a partir de um documento ou texto, utilizamos a função `to_tsvector`. Ela recebe uma _string_ e um configuração de linguagem e nos retorna nosso vetor normalizado. Assim, exemplo:

```sql
SELECT to_tsvector('portuguese', 'O PIB  do Brasil cresceu consideravelmente no ano passado');
```

retorna

```plaintext
'ano':8 'brasil':4 'consider':6 'cresc':5 'pass':9 'pib':2
```

que é o nosso vetor.

Para fazer uma busca em cima dessa frase, utilizamos a função `to_tsquery` da seguinte forma:

```sql
SELECT to_tsvector(
  'portuguese',
  'O PIB  do Brasil cresceu consideravelmente no ano passado'
) @@ to_tsquery('portuguese', 'crescer & pib');
```

A consulta acima busca pelas palavras "crescer" e (&) "pib" na frase destacada, podendo estar as mesmas separas por qualquer distância (veremos como fazer consultas mais sofisticadas). O retorno dessa frase é `TRUE`, apesar de a palavra "crescer" não presente de forma exata, mas sim sua flexão: "cresceu".

Com esse exemplo, dá para se ter uma ideia do quão poderoso é essa mecanismo.

### Fluxo de uso real em um banco de dados

Naturalmente, a ideia é que possamos fazer buscas em registros de um banco de dados.

Imagine, por exemplo, que temos um banco de dados utilizado para gerenciar notícias em um site como o G1.

Nosso objetivo final é o de poder fazer uma busca como "PIB" e achar as principais notícias que contenham esse termo.

E aí que entra um grande trunfo da pesquisa FTS: com ela, podemos definir parâmetros para determinar a relevância de uma correspondência. Como assim?

Uma notícia tem uma manchete (o título), uma sinopse ou subtítulo e o corpo da notícia em si.

Naturalmente, se encontramos a palavra "PIB" na manchete de uma notícia, esse resultado é mais relevante do que se a palavra fosse encontrada apenas no corpo da mesma.

E se encontramos a mesma palavra na sinopse, ainda assim trata-se de um resultado mais relevante do que apenas no corpo.

Agora, se corpo da notícia encontramos o termo 10 vezes, parece razoável que esse resultado seja mais relevante do que se o encontramos apenas 3 vezes.

E é exatamente esse tipo de "rankiamento" que podemos definir nas buscas: o correspondências no título ganham peso "A", na sinopse, "B" e no corpo "C", por exemplo.

### Implementação

Vamos usar como exemplo prático o banco de dados utilizado nesse blog. Os "posts" têm a seguinte estrutura:

```sql
CREATE TABLE public.posts (
    id uuid NOT NULL,
    title text NOT NULL,
    excerpt text NOT NULL,
    slug text NOT NULL,
    "ogImageUrl" text NOT NULL,
    body text NOT NULL,
    "createdAt" timestamp(3) without time zone NOT NULL,
    "updatedAt" timestamp(3) without time zone,
    "authorId" uuid NOT NULL,
    note boolean NOT NULL
);
```

Por trás dos panos, esse é o _schema_ gerado pelo excelente ORM Prisma.

O primeiro passo para implementarmos FTS é criar _gerar_ uma coluna que corresponda a chamar a função `to_tsquery` nos campos `tile`, `excerpt` e `body`, atribuindo pesos A, B e C, respectivamente.

Para isso usamos a seguinte query:

```sql
ALTER TABLE
  posts
ADD
  COLUMN textsearchableIndex tsvector
  GENERATED ALWAYS AS (
    setweight(to_tsvector('portuguese', title), 'A') ||
    setweight(to_tsvector('portuguese', coalesce(excerpt, '')), 'B') ||
    setweight(to_tsvector('portuguese', body), 'C')
  )
  STORED;
```

Essa query adiciona uma nova coluna chamada `textsearchableIndex` na tabela `posts` do banco de dados. Essa coluna é um tipo especial de dado chamado `tsvector` que já abordamos.

A cláusula `GENERATED ALWAYS AS` especifica que os valores da coluna `textsearchableIndex` serão gerados automaticamente com base em uma expressão que combina os textos das colunas `title`, `excerpt` e `body`.

Essa expressão é composta por uma sequência de chamadas para a função `to_tsvector`, que converte o texto em um vetor de termos de busca. Cada vetor resultante é ponderado com um peso específico (`A`, `B` ou `C`) usando a função `setweight`, que indica a importância relativa de cada coluna na pesquisa.

A cláusula `STORED` indica que os valores da coluna `textsearchableIndex` serão armazenados fisicamente no banco de dados em vez de serem calculados toda vez que a consulta é executada. Isso torna as consultas de pesquisa mais eficientes, pois os valores já estarão pré-calculados e prontos para uso.

### Criando um index

Para aumentar a eficiência de nossas buscas, criamos um índice para essa coluna

```sql
CREATE INDEX posts_textsearch_idx ON posts USING GIN (textsearchableIndex);
```

O tipo de índice utilizado é o "GIN" (Generalized Inverted Index), que é otimizado para pesquisas FTS em grandes conjuntos de dados.

O índice GIN armazena um mapa invertido das palavras presentes nos textos da coluna "textsearchableIndex". Esse mapa é organizado em uma estrutura de árvore, que permite a pesquisa FTS de forma eficiente.

Ao criar esse índice, as consultas de pesquisa que utilizam a coluna "textsearchableIndex" serão muito mais rápidas, pois o índice pode ser usado para localizar rapidamente os documentos relevantes. Em outras palavras, o índice acelera a pesquisa de texto completo na tabela "posts".

Pronto! Tudo certo. Vamos ver como podemos usar essa coluna para fazer consultas!

### Fazendo consultas

Concluída a construção e indexação da nossa coluna, estamos aptos a fazer pesquisas rápidas e eficientes pelo banco de forma bastante simples! Observe a query abaixo

```sql
SELECT
  title,
  excerpt,
  slug,
  ts_rank(
    textsearchableIndex,
    plainto_tsquery('portuguese', '<plain text input>')
  ) as rank
FROM
  posts
WHERE
  textsearchableIndex @@ plainto_tsquery('portuguese', '<plain text input>')
ORDER BY
  rank DESC
LIMIT 5;
```

O destaque dessa query fica para a função `ts_rank`, que ainda não foi explicada.

Essa função é justamente a parte do FTS no Postgres que lida com a **relevância** dos resultados. Ela recebe dois parâmetros: um `tsvector` e uma `tsquery`, respectivamente, e retorna um número entre 0 e 1 indicando o grau de relevância do resultado baseado em critérios como frequência das ocorrências, proximidade entre os lexemas e, claro, os pesos atribuídos aos vetores. Esse último garante que ocorrências no título (a que atribuímos peso "A") terão uma nota maior do que ocorrências no corpo.

O valor calculado é usado para ordenar os resultados em ordem decrescente de sua relevância.

Uma outra observação é válida para a função utilitária `plainto_tsquery`, que simplesmente converte texto comum no tipo especial `tsquery`. Assim, por exemplo, “casa vermelha” vira “casa & vermelha”.

E pronto! Isso é realmente tudo que você precisa para ter um sistema de FTS integrado ao seu bando de dados Postgres.

### Indicando as ocorrências no texto com `ts_heading`

Por fim, gostaríamos de, além de mostrar os resultados mais relevantes (baseados nos critérios discutidos), também indicar _onde_, nos textos, esses resultados aparecem.

Para tanto, o PostgreSQL conta com a função `ts_heading`, que recebe o texto a ser buscado (formato `string`) e uma `tsquery` e retorna uma ou mais `strings` que correspondem a fragmentos do documento onde as ocorrências aparecem.

Por padrão, as ocorrências são destacadas com o marcador `<b></b>`, porém pode ser configurado para qualquer outro indicador.

Um exemplo de uma _query_ que usa a função `ts_heading` seria a seguinte:

```sql
SELECT
  title,
  excerpt,
  slug,
  ts_rank(
    textsearchableIndex,
    plainto_tsquery('portuguese', '<plain text input>')
  ) as rank,
  ts_headline(
    'portuguese',
    body,
    plainto_tsquery('portuguese', '<plain text input>'),
    'MaxFragments=10'
  ) as headline
FROM
  posts
WHERE
  textsearchableIndex @@ plainto_tsquery('portuguese', '<plain text input>')
ORDER BY
  rank DESC
LIMIT 5;
```

A opção `MaxFragments=10` especifica que devem ser retornadas no máximo 10 ocorrências destacadas no texto.

É necessário cuidado ao utilizar essa função porque, diferente das outras apresentadas até então, ela atua no formato de texto ao invés da estrutura `tsvector`.

### Conclusão

Com os elementos discutidos nesse artigo, você tem toda a base de que precisa para implementar um sistema FTS no Postgres.

Para mais detalhes, acessa a documentação [aqui](https://www.postgresql.org/docs/current/textsearch.html).

É isso por enquanto, espero que tenha sido útil. Qualquer dúvida estou à disposição!

_Happy coding!_

### Anexos

#### Distinção entre **lexema** e **radical** segundo o Chat GPT3

"Não, lexema e radical não são exatamente a mesma coisa, embora estejam relacionados.

O lexema é a parte da palavra que carrega o seu significado central e é comum a todas as suas formas. Por exemplo, o lexema da palavra "cantar" é "cant-". Ele é a base para todas as outras formas da palavra, como "canto", "cantava", "cantaremos", entre outras.

Já o radical é a parte da palavra que contém as suas informações gramaticais e varia em suas formas flexionadas. Ele geralmente é o mesmo que o lexema, mas pode sofrer alterações quando a palavra é flexionada em gênero, número, tempo, modo, pessoa, entre outros aspectos. Por exemplo, o radical da palavra "cantar" é "cant-", mas ele se altera para "cantav-" na forma "cantavam".

Resumindo, o lexema é a base semântica da palavra, enquanto o radical é a base morfológica que varia nas formas flexionadas."


Full-text search com PostgreSQL

### Introdução

Paginação no backend é uma solução que resolve o problema de ter uma quantidade substancial de dados a serem retornados em uma requisição.

Um exemplo de situação desse tipo seria a de retornar o feed de um usuário em uma rede social. Esse feed pode ter potencialmente milhares de registros, o que poderia levar uma quantidade impraticável de tempo para carregar, além de ter o potencial de esgotar a memória da aplicação cliente.

Ao invés de retornar esses dados todos de uma vez, a paginação divide-os em partes que podem ser enviadas e processadas de forma adequada.

O objetivo deste artigo é analisar as possíveis abordagens para implementação desse mecanismo, observando em quais situações cada uma se adéqua melhor.

### Uma distinção importante: implementação vs. API

O foco da discussão aqui está relacionada à implementação de um sistema paginação. Porém, uma vez implementado o mecanismo, deve-se escolher uma forma de expô-lo às aplicações consumidoras.

Caso estejamos usando REST, a maneira recomendada de expor essa funcionalidade é através de `querystring`'s e meta-informações no corpo da requisição. Vamos imaginar que estamos falando de um _endpoint_ que retorna pedidos. Então, se esse _endpoint_ implementa paginação, teríamos algo como:

```plaintext
https://example.com/orders?page=1&limit=10
```

O que nos retornaria os 10 primeiros pedidos (em uma ordem pré-definida) na primeira página. No corpo da resposta, teríamos um campo para a lista de pedidos `"records"` e um campo para informações da paginação `"pagination"`, algo como:

```json
{
  "records": [
    ...
  ],

  "pagination": {
    "current": "https://example.com/orders?page=1&limit=10",

    "next": "https://example.com/orders?page=2&limit=10",

    "previous": null,

    "last": "https://example.com/orders?page=26&limit=10",

    "first": "https://example.com/orders?page=1&limit=10"
  }
}
```

### A abordagem tradicional

A abordagem mais simples para esse problema é usar mecanismos de **OFFSET** e **LIMIT** presente na maioria dos sistemas de banco de dados. Em bancos de dados relacionais, essas são exatamente as palavras reservadas usadas para esse propósito. Entretanto, raramente escrevemos SQL puro em nossas aplicações.

O seu ORM de preferência certamente tem uma API para acessar esse mecanismo do banco de dados em algum lugar. No caso do [Prisma](https://www.prisma.io/) (Node.js), esse funcionalidade pode ser acessada com:

```typescript
const results = await prisma.post.findMany({
  skip: 3,
  take: 4,
});
```

O que significa que estamos buscando 4 registros, "pulando" os três primeiros, tal como na imagem abaixo:

![](https://www.prisma.io/docs/static/8cbb3ea8b5fc961b73cd2e583313f3a9/77e4e/offset-skip-take.png)

Dessa forma, fica extremamente simples implementar paginação.

Se estivermos lidando com paginação começando com o índice 1 e com 10 itens em cada página, para acessar a n-ésima página, basta especificar um offset de `(n - 1) * itens` e um limit de 10.

A quantidade de itens e de páginas disponíveis geralmente são retornados no corpo da requisição, como mostrado anteriormente.

Uma outra possibilidade é usar _offset_ ao invés de _page_ para especificar que parte da lista de recurso queremos visualizar.

Com _offset_, especifica-se exatamente quantos items devemos "pular" até alcançar os items que desejamos visualizar. Por exemplo, o endpoint

```plaintext
https://example.com/orders?offeset=30&limit=10
```

Retornaria os 10 items depois dos 30 primeiros.

Nesse caso a aplicação cliente fica responsável por ajustar o _offset_ de cada página, o que pode ser mais sujeito a erros.

### Por que essa pode não ser a melhor opção

Existem dois problemas cruciais com essa abordagem:

1. Eficiência
2. Consistência

#### Eficiência

Em primeiro lugar, quando usamos **OFFSET** em um banco de dados relacional, o banco efetivamente tem que percorrer todos os registros presente no banco até chegar no registro especificado.

Se usamos um offset de 20,000, por exemplo, o banco necessariamente precisa percorrer esses 20,000 registros antes de chegar no registro que desejamos.

Como se pode ver, isso não é nada eficiente, caso estejamos lidando com um numero suficientemente grande. Em outras palavras, trata-se uma solução que não escala bem.

#### Consistência

Outro problema surge quando temos um conjunto de dados dinâmico que muda com o tempo. Com essa abordagem, se dados forem inseridos ou excluídos no momento em que estamos atravessando os registros, poderemos ter omissão ou duplicidade nos resultados.

Por exemplo, imagine que temos 10 itens e estamos percorrendo os mesmo de 5 em 5. Se no momento em que acessarmos a segunda página um novo item for adicionado na primeira, teremos um item da primeira página mostrado novamente na segunda.

Ficou difícil de entender? O diagrama abaixo descreve melhor a situação:

```plaintext
legenda

1,2,3: páginas
X: item da lista
Y: novo item
O: item específico que estamos observando

lista inicial

1   2
X   X
X   X
X   X
X   X
O   X

👇 novo item adicionado (Y)
1   2   3
Y   O   X
X   X
X   X
X   X
X   X

```

Nesse exemplo, vê-se que o item `O` aparecerá na página 1 e novamente na página 2, caso acessemos esta última no momento da inserção.

Apesar desses dois pontos, se não estamos lidando com uma serviço que tem uma número enorme de registros e em que consistência não é algo de primeira importância (ou o conjunto de dados muda pouco), então essa abordagem se torna aceitável. Um bom exemplo disso seria um blog pessoal.

### Abordagem alternativa

Uma forma alternativa de paginar os dados é usando um parâmetro que sirva para ordenar os dados de forma única e, dessa forma, ser usado como cursor. Geralmente esses parâmetros são indexados no banco de dados. Um bom exemplo é a chave primária de uma tabela ou um carimbo de data/hora de criação/atualização. Vejamos como isso funciona com um exemplo.

Numa primeira requisição, pedimos por itens sem especificar páginas ou _offsets_, especificando, opcionalmente, um _limit_ (caso não seja especificado, a maioria das API's terá um limite padrão):

```plaintext
https://example.com/orders?limit=10
```

No corpo da requisição, recebemos nos metadados um campo que pode ser usado para receber mais dados a partir do último item requisitado. Esse parâmetro pode se chamar, por exemplo, _`after_id`_. Em geral, recebemos um **link** para o próximo conjunto de dados e não o parâmetro em si, o que é mais conveniente. Esse link teria um forma como:

```plaintext
https://example.com/orders?after_id=53&limit=10
```

_`after_id`_ funciona como cursor, sinalizando que os itens devem ser requisitador a partir do `id` especificado por ele.

Essa requisição, por sua vez, nos daria acesso a mais dois links para acessar items posteriores e anteriores, governados pelo parâmetro _after_id_ ou algum outro que pudesse cumprir essa função.

A grande desvantagem desse método é que não é possível pular páginas: para acessar a n-ésima página precisamos percorrer todas as anteriores, sempre tomando nosso "cursor" como referência.

Em contra-partida, trata-se de um método muito mais eficiente, porque usa um campo indexado da tabela para fazer as consultas. Portanto não haverá perda de performance mesmo se for necessário atravessar um grande quantidade de items.

Além disso, com essa abordagem temos consistência garantida: nunca teremos duplicação de itens enquanto percorremos os registros.

Esse é um excelente método para ser usado para _infinite_scrolling_, por exemplo, já que não é necessário acessar páginas específicas, mas simplesmente manter um constante (e performático) fluxo de registros ordenados.

### Conclusão

As duas abordagens de paginação apresentadas são suficientes para cobrir a maioria dos casos de uso. É importante observar as características de cada uma para poder decidir qual utilizar em qual situação.

É isto! Espero que tenha gostado do artigo. Se tiver alguma dúvida ou sugestão, não hesite em entrar em contato.

_Cheers!_


Paginação de APIs no Backend

### A motivação e o projeto

Todos os posts que são publicados aqui no blog são também compartilhados no [Linkedin](https://www.linkedin.com/in/felipe-andre-barbosa/). Isso é uma maneira de sinalizar aos possíveis interessados que um novo conteúdo está disponível. Uma outra maneira de fazer isso seria implementar [_SSR Feed_](https://felixcrux.com/blog/feeds-the-only-civilised-way-to-read-online), mas poucas pessoas fora e até dentro da bolha _tech_ estão familiarizadas com essa ferramenta.

O problema é que o Linkedin provavelmente não é a ferramenta primária de consumo de conteúdo técnico da maioria das pessoas. E mesmo que seja, é bastante possível que essas pessoas não acessem a rede todos os dias.

Entretanto, uma ferramenta que provavelmente é acessada todos os dias pela maioria das pessoas é o e-mail. Então resolvi criar um sistema de inscrição para que as pessoas que acompanham o blog pudessem ser notificadas por e-mail toda vez que um conteúdo novo fosse adicionado. Essa também era uma ótima desculpa para pôr em prática alguns conceitos de arquitetura design de software que eu vinha estudando, além de ser um ótimo candidato para criação de um microsserviço, que foi um dos alvos de estudo que eu elenquei para 2023.

### Fluxo de uso

O serviço é simples e pode ser dividido em duas partes.

A primeira parte do serviço expõe uma API para a criação e confirmação de uma inscrição. O processo de confirmação acontece via e-mail e garante que **usuários maliciosos** não vão cadastrar e-mails aleatórios, poluindo o serviço com e-mails inexistentes ou que não estão em uso.

Essa primeira parte é bastante simples, porém foi, como mencionado antes, uma ótima oportunidade para testar e pôr em prática meus conhecimentos de arquitetura de software. DDD, _Clean Architecture_, testes, foram todos incluídos no projeto.

A segunda parte envolveu conceitos realmente novos para mim e bastante interessantes que estavam no meu mapa para serem explorados.

### Comunicação assíncrona de microsserviços

Uma vez que um e-mail foi cadastrado e confirmado a ideia é a de que o usuário esteja apto para receber e-mails na sua caixa de entrada toda vez que um conteúdo novo for adicionado.

Para tanto, [o serviço de gerenciamento de conteúdo](https://github.com/Felipe-53/tech-blog-cms-api) precisa se comunicar com o recém-criado serviço quando um conteúdo novo for adicionado, para que então os e-mails possam ser disparados por ele.

Essa comunicação poderia ser implementada de forma síncrona: o serviço de e-mails poderia expor uma rota que poderia ser chamada para disparar e-mails para todos os recipientes confirmados.

Entretanto, o que aconteceria se essa comunicação falhasse? Se por qualquer motivo o serviço de e-mails estivesse indisponível no momento, essa “ordem” de envio de e-mails seria perdida.

Seria possível implementar uma lógica de re-tentativa no lado da API de gerenciamento, porém não seria algo muito elegante, principalmente porque todos os serviços mencionados aqui estão em uma ambiente _serverless_, especificamente na AWS Lambda. O que fazer então?

### A solução: filas

Note que o tipo de comunicação descrito anteriormente é _síncrono_: um serviço fala diretamente com o outro e ambos precisam estar disponíveis naquele instante para se comunicar. O problema acontece quando possíveis erros de comunicação aparecem no caminho. Uma possível solução é implementar uma comunicação assíncrona usando filas, que funcionam como um intermediador da comunicação entre serviços.

Ao invés de se comunicarem diretamente, mensagens que um serviço quer fazer chegar a outro são colocadas na fila. O segundo serviço pode, então, procurar por mensagens na mesma e consumi-las. Note que esse é um padrão de comunicação _**a**ssíncrono_: se por acaso o serviço responsável por processar as mensagens estiver indisponível no momento, as mensagens **continuam retidas na fila** e disponíveis para serem processadas assim que o serviço estiver novamente de pé.

Esse modelo de comunicação dá um nível de confiabilidade muito grande e robusto para a comunicação desses serviços.

### Implementação

Na AWS, o serviço básico de filas chama-se SQS: _Simple Queue Service_. E é bastante simples integrá-lo a uma função Lambda.

Funciona da seguinte forma:

1. Cria-se uma fila e uma função Lambda.

2. Configura-se a função Lambda para ter permissões de consumir mensagens da fila.

3. Adiciona-se mensagens da fila como um _trigger_, um acionador da função Lambda e... pronto.

Se a função Lambda conseguir processar com sucesso a mensagem consumida, o serviço automaticamente exclui a mensagem da fila. Se não, a função tenta processar novamente com intervalos cada vez maiores. Uma estratégia de _logging_ e _error handling_ é necessária para fazer com que as coisas fluam de forma suave, mas não é nada particularmente sofisticado.

### Conclusão

Comunicação assíncrona entre serviços usando filas é uma maneira bastante robusta de implementar microsserviços. É possível usar outras tecnologias para fazer isso, como o Redis, para ter maior flexibilidade e minimizar a possibilidade de ficar preso a um provedor como AWS.

Seja como for, é um padrão de arquitetura bastante poderoso.

Agora que você já sabe como o sistema funciona, aproveite e se inscreva abaixo para ser notificado quando houver conteúdo novo!

Vejo vocês na próxima, _cheers_!


Comunicação assíncrona entre microsserviços: filas

_Developer experience_ é algo primordial que, na minha visão, deve ser levado muito a sério.

É pouco razoável esperar de um desenvolvedor produtividade e eficiência quando se está trabalhando em um projeto que é difícil de configurar, testar, de fazer deploy, etc. Acredito que é papel de um arquiteto e engenheiro de software buscar ferramentas que facilitem a vida dos desenvolvedores. A tecnologia está aí para tornar as coisas mais fáceis, mais prazerosas e mais satisfatórias. Se não estamos construindo esse tipo de tecnologia, então estamos fazendo algo muito errado.

Automação no geral é uma desses princípios que tornam nossa vida mais fácil e prazerosa. Se estamos fazendo algo enfadonho repetidamente, eis aí um bom candidato para automação. Uma dessas coisas que é extremamente enfadonha e repetitiva é fazer deploys manualmente, independentemente de qual ambiente se está trabalhando. Uma vez que uma nova funcionalidade é implementada, testada e assegurada com sucesso, deveríamos ser capazes de “mergiar” a mudança ao nosso repositório e deixar nossa pipeline tomar conta do resto. É o tipo de experiência que se tem com alguns serviços como a Vercel, onde hospedo esse site. Um merge na `main` significa uma atualização do serviço no ar em produção.

Acontece que hoje em dia, com o Github Actions, é mais fácil do que nunca ter um sistema de CI/DC de forma simples e gratuita. Qualquer projeto, grande ou pequeno, pode e deve fazer uso dessa ferramenta para automatizar e simplificar várias tarefas do ciclo de desenvolvimento de aplicações. Hoje eu vou mostrar especificamente como usá-la para automatizar o deploy de uma função Lambda.

## O contexto: Lambda com Docker images

Para atualizar e fazer deploy de uma função lambda, é necessário, claro, apontar para a AWS o “pacote” (seu código junto com todas as dependências) que deve ser usado na execução. Existe uma limitação no tamanho desse pacote. 50 MB (ou de 250MB sem compressão quando usando o S3). Já falei sobre isso [nesse post](https://www.felipebarbosa.dev/tech-notes/aws-lambda-com-docker#o-jeito-tradicional).

Para se ter uma ideia do quanto isso é limitante, considere que só a pasta `node_modules` do API de Gerenciamento de Conteúdo desse blog tem mais de 300 MB:

![node_modules wheight: 300 MB](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/articles-assets/node_modules_wheight.png)

Por isso, há algum tempo eu sempre faço uploads de funções usando imagens Docker, [uma feature recente do serviço](https://www.felipebarbosa.dev/tech-notes/aws-lambda-com-docker).

O que eu vou mostrar hoje é como automatizar esse processo.

## Github Actions

Para criar um workflow no GA, tudo que é preciso é criar na raiz do repositório uma estrutura da seguinte forma

```bash
.github
└── workflows
    └── main.yaml
```

O arquivo `.yaml` é onde podemos declarar workflows a serem seguidos na ocorrência de algum evento. Esse evento pode ser um pull request, merge, commit, ou qualquer evento que possa ocorrer dentro do seu repositório. Ou seja, apesar de eu estar mostrando uma automação de deploy, o GA pode ser usado para vários propósitos relevantes no ciclo de vida de um projeto.

O workflow apresentado a seguir é o que eu uso na [Api de Gerenciamento de Conteúdo do Blog](https://github.com/Felipe-53/tech-blog-cms-api). Será nossa base para explicar como tudo funciona. Vamos lá!

```yaml
name: Deploy to Lambda through ECR

# evento
on:
  push:
    branches: [main]

# tarefas
jobs:
  build:
    name: Build Image and Deploy Lambda Function
    runs-on: ubuntu-latest

    # etapas
    steps:
      # 1. checkout
      - name: Check out code
        uses: actions/checkout@v2

      # 2. credenciais
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: sa-east-1

      # 3. login to ECR
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      # 4. upload to ECR and update Lambda Function
      - name: Build, tag, push image to Amazon ECR and update Lambda Function
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: ${{ secrets.AWS_ECR_REPOSITORY }}
          IMAGE_TAG: tech-blog-cms-api
          LAMBDA_FUNCTION_NAME: ${{ secrets.LAMBDA_FUNCTION_NAME }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          aws lambda update-function-code \
            --function-name $LAMBDA_FUNCTION_NAME \
            --image-uri $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
```

## Os Pilares

Existem três entidades principais no GA:

- events
- jobs
- steps

### Eventos

Eventos são, claro, algum acontecimento que dispara a execução de um workflow. No nosso caso, a diretriz

```yaml
on:
  push:
    branches: [main]
```

Diz que o workflow deve ser acionado em commits na branch principal.

### Tarefas

Tarefas são quaisquer ações que você deseje executar quando do acontecimento dos eventos especificados. No nosso caso, desejamos:

1.  Construir uma imagem Docker baseado no repositório do projeto
2.  Publicar essa imagem no ECR (Elastic Container Registry, o repositório de imagens da AWS)
3.  Atualizar o código da nossa função Lambda com essa imagem criada

Como se pode ver, uma tarefa geralmente segue um conjunto específico e ordenado de etapas para que a mesma seja concluída, o que nos leva à próxima entidade do GA. Porém antes de falar sobre as etapas, vamos tentar responder uma pergunta importante: onde roda as tarefas que são especificadas nos workflows?

#### Containers, containers, containers

O mundo do DevOps e do Serverless não existiria sem containers. E pelo subtítulo, você já sabe a resposta da pergunta anterior. Pois é, para toda tarefa especificada em um workflow, o GA inicializa um container para a sua execução. E não só linux: o github provê uso de imagens windows e macOS também. E é aí que seu código é rodado. Isso é interessante porque significa que você tem acesso normal a ferramentas como `bash` e você pode executar qualquer tipo de código arbitrário dentro de uma tarefa. Então você tem basicamente um universo ilimitado de possibilidades do que fazer em um workflow.

É possível ter mais de uma tarefa no mesmo workflow. Por padrão, elas rodam em paralelo, em containers separados. Porém é possível também especificar dependências entre tarefas, para que uma só seja iniciada depois do término de outra.

No nosso caso específico, vamos rodar nossa tarefa no linux, como especificado pela diretriz `runs-on: ubuntu-latest`.

### Etapas

Etapas são o passo-a-passo que deve ser seguido para que uma tarefa seja concluída. Já sabemos que estamos dentro de um container ubuntu, então temos acesso a todos os comandos do `bash`, por exemplo. Uma ação pode ser um comando ou então uma _action_ - que é algo que vamos dar uma atenção especial.

#### Actions

Uma das melhores partes do GA é que você não precisa escrever seus workflows do zero. Sendo uma ferramenta do Github, é claro que existem maneiras de compartilhar e distribuir soluções para tarefas cotidianas e repetitivas. Por exemplo, é razoável esperar que em um workflow de um repositório vai se desejar, em algum momento, usar o código do repositório para fazer alguma ação (“buildar”, testar, fazer deploy, etc). Sabemos que nossas tarefas rodam em containers linux inicializados com o propósito único de executar nossas ações. Porém, esse container recém-criado não vem com nosso código. Temos que cloná-lo Github para ele… E isso pode envolver autenticação, credenciais, etc.

Porém ao invés de criar um script para fazer isso, o GA tem uma ação padrão chamada `checkout` que faz exatamente isso. Usando a diretriz `uses` podemos especificar uma ação feita e distribuída por terceiro para ser executada na nossa instância.

```yaml
 - name: Check out code
        uses: actions/checkout@v2
```

`actions/checkout@v2` faz o upload do código do nosso repositório e o disponibiliza no diretório de trabalho atual. Assim, mais tarde, quando formos construir a imagem Docker, podemos usar a diretriz `.` (a pasta de trabalho atual, no comando `docker build`) para especificar nosso repo.

As quatro etapas necessárias para alcançarmos nosso objetivo são (como numeradas no arquivo yaml):

1. `checkout`

Já explicamos o motivo dessa ação e como funciona. Usamos a ação `actions/checkout` para trazer nosso repositório para o container onda a tarefa está sendo executada.

2. Credenciais

Precisamos configurar nossas credenciais da AWS para poder subir nossa imagem Docker (a ser criada) para ECR. Usamos novamente uma ação de terceiros (da AWS, nesse caso) para isso, a `aws-actions/configure-aws-credentials@v1`. Nessa etapa, usamos o conceito de secrets. Secrets são variáveis que podemos configurar no nosso repositório para uso em coisas como workflows. Funcionam de forma muito parecida com variáveis de ambientes e servem para não precisarmos expor informação sensível no nosso código.

3. Autenticação no ECR

Usando as credenciais da etapa anterior, autenticamos no ECR. Mais uma vez, usamos uma ação oficial da AWS.

4. Construir imagem, subir no ECR e atualizar o código da função Lambda

Todas as etapas anteriores foram basicamente configurações para a etapa atual. Aqui vamos usar `bash` e `docker` para construir nossa imagem, subir no ECR e atualizar nossa função. Usamos a CLI do Docker e da AWS, que estão disponíveis para nós graças às etapas anteriores. Definimos variáveis de ambiente para ficar mais fácil de referenciar as variáveis sensíveis de nosso workflow com a diretriz

```yaml
env:
  ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
  ECR_REPOSITORY: ${{ secrets.AWS_ECR_REPOSITORY }}
  IMAGE_TAG: tech-blog-cms-api
  LAMBDA_FUNCTION_NAME: ${{ secrets.LAMBDA_FUNCTION_NAME }}
```

Por fim, executamos nossos comandos:

```yaml
run: |
  docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
  docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
  aws lambda update-function-code \
    --function-name $LAMBDA_FUNCTION_NAME \
    --image-uri $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
```

## Conclusão

Dessa forma, temos um workflow completo para um deploy automatizado de nossa função Lambda.

É perfeitamente plausível incluir uma outra tarefa para rodar os testes da aplicação - e só então construí-la e subí-la para produção. É claro que é possível fazer isso localmente, porém DevOps é sobre automação e sobre _garantias_.

Depois dessa introdução ao GA com um exemplo prático, recomendo fortemente a leitura da excelente [documentação oficial](https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions).

É isso, espero que tenham gostado e vejo vocês na próxima.

Cheers!


Automatizando o deploy de funções Lambda com Github Actions

Pois bem, aqui estamos novamente com mais relatos da minha aventura no mundo do open source.

No [último artigo](https://www.felipebarbosa.dev/artigos/minha-primeira-tentativa-de-contribuicao-para-a-comunidade-open-source-parte-1), eu tinha aberto um [issue](https://github.com/denoland/deno_blog/issues/103) para saber a opinião da comunidade sobre uma melhoria proposta.

Mesmo sem ter recebido um feedback, resolvi implementar minha solução. Fiz um fork do projeto e comecei a trabalhar. Não era algo difícil: consegui fazer funcionar em pouco tempo. Entretanto, fiquei refletindo bastante se aquilo se encaixava na proposta do projeto. Na descrição do github, lê-se:

> Minimal boilerplate blogging

Trata-se de um projeto clean e minimalista, tanto na interface de uso que ele entrega ao programador (é possível construir o blog com duas linhas), quanto na implementação (o projeto tem basicamente dois arquivos e mais um para testes).

A solução que eu estava propondo contava com a comunidade para adicionar ao projeto adaptações para cada língua desejada das pequenas porções de texto que aparecem no site que não é conteúdo do autor. Coisas como “Home”, “Read More”.

Porém isso envolve ter na base de código as traduções em várias línguas desses termos. Nem um pouco minimalista.

Uma outra solução plausível, porém mais trabalhosa para o desenvolvedor, seria a de fazer um fork do projeto e alterar esses termos _in place_, no próprio código. Como o Deno [suporta imports de url diretamente](https://www.felipebarbosa.dev/tech-notes/deno's-module-system), bastaria apontar para o seu fork no seu projeto, ao invés da url oficial.

Isso é bem menos conveniente e requer um conhecimento técnico específico, inclusive para manter o projeto atualizado, o que demanda, se essa solução for escolhida, que você esteja sempre sincronizando o seu fork com o repositório oficial.

Todas essas considerações eu adicionei no issue que eu já tinha aberto. O que resta saber agora é a opinião dos moderadores.

A minha opinião pessoal mudou um pouco à medida que eu fui refletindo.

Em primeiro lugar, o projeto deixa o usuário ciente de que é uma solução minimalista desde o princípio. Ter traduções para outras linguagens seria uma feature interessante de se ter, mesmo no contexto minimalista? Provavelmente, mas, a não ser que eu esteja redondamente enganado, isso iria requerer um esforço que simplesmente não faz sentido para um projeto desse porte.

Em segundo lugar, essa provavelmente não vai ser a única coisa que você vai querer mudar se você está buscando customização. Então, de qualquer forma, em algum ponto, você iria acabar querendo fazer um fork de qualquer jeito.

Diante disso, eu acharia compreensível se os moderadores do projeto não quisessem incorporar essa funcionalidade.
### O novo problema

Pois bem, essa foi a solução do fork foi a que eu adotei e agora meu blog pessoal está 100% em português.

![git-diff](https://tech-blog-assets.s3-sa-east-1.amazonaws.com/tech-notes-assets/git-diff.png)

Entretanto, como eu havia dito no post anterior, esse não é o único ajuste que julguei que o projeto merecia.

Um outro problema diz respeito a visualização do blog em dispositivos móveis.

O `deno_blog` dá acesso a configuração de tema claro ou escuro, algo indispensável nos dias de hoje, haha. Entretanto, quando visto no smartphone com tema escuro, a barra de navegação do browser continua clara, uma experiência nada agradável 🥲.

Estava diante de uma funcionalidade que claramente poderia e deveria ser implementada sem muitas controvérsias dessa vez.

Assim, resolvi mudar de marcha e atacar esse problema.

### O primeiro Pull Request

Depois de analisar cuidadosamente o código fonte, escrevi uma solução que achei a melhor. Precisei de ajustes mínimos. Escrevi dois testes para garantir que tudo estava OK: tudo lindo, tudo funcionando.

Depois de me ver satisfeito com o meu trabalho, foi o momento de abrir o PR:

https://github.com/denoland/deno_blog/pull/106

PR aberto, resta agora saber se vai ser aceito ou não. 🤔

### Conclusão

Claro, mesmo antes de o PR ser aceito eu já incluí a solução ao meu fork e evidentemente já estou usando-a em meu blog pessoal. Mesmo que o PR acabe não sendo aceito por algum motivo, meu trabalho já está mais do que pago com a experiência realmente _full dark mode_ que pode ser encontrada lá no [meu blog](https://felipebarbosa.deno.dev), haha 😜.

Vejo vocês em breve.

Cheers!


Minha primeira tentativa de contribuição para a comunidade open source - Parte 2

Eu sou grande fã e entusiasta da comunidade open source.

É incrível a quantidade de ferramentas das quais nós dependemos que são construídas em código aberto pela comunidade.

Depois de ter construído meu blog profissional, eu alimentei por um bom tempo a vontade de ter um blog pessoal. Mas nesse caso eu não queria construí-lo do zero: eu estava em busca de uma solução simples, fácil, minimalista com uma interface agradável e recursos essenciais.

Pois bem, eu estava explorando o universo do [Deno](https://deno.land/), o novo runtime do JavaScript/TypeScript, e descobri um projeto que se encaixava perfeitamente dentro daquilo que eu queria: o [deno_blog](https://github.com/denoland/deno_blog)!

Essa é a ferramenta que o próprio Ryan Dahl, criador do Node e do Deno, usa no blog dele, o [tinyclouds.org](https://tinyclouds.org/).

Era perfeito: minimalista, bonito, baseado em markdown. Entretanto, trata-se de um projeto que não atingiu ainda sua primeira _major version_ (atualmente se encontra na versão 0.5.0) e obviamente ainda tem alguns ajustes a serem feitos e algumas funcionalidades a serem implementadas.

Uma dessas coisas é suporte para linguagens diferentes do inglês no conteúdo do site que não são os posts em si. Coisas como “Leia Mais”, “Princial”, etc, estão todos em inglês: “Read More”, “Home” - e sem possibilidade de configuração 🥲.

Então comecei a ver o projeto para saber como era estruturado e vi que a funcionalidade era bastante factível de ser implementada.

Fiquei bastante empolgado com a possibilidade de contribuir para o projeto, então resolvi abrir um **[issue no repositório](https://github.com/denoland/deno_blog/issues/103)** para saber a opinião da comunidade a respeito de uma possível implementação sugerida por mim.

Foi o primeiro issue que eu abri em um repositório público e fiquei extremamente animado com isso.

Não sei qual vai ser a recepção, mas de toda forma considero um primeiro passo importante na tentativa de retribuir um pouco tudo aquilo que o open source me deu.

Vou trazer aqui todas as atualizações a respeito e ver qual será o desfecho dessa história.

### P.S.

Existem ainda outras _features_ que eu gostaria de trabalhar nesse projeto. Tenho a intenção de continuar contribuindo. Se não for dessa vez, certamente tentarei novamente. E se der certo, isso com certeza me dará ainda mais ânimo para continuar trabalhando nele.

Ansioso pelos próximos capítulos, haha.

Cheers!


Minha primeira tentativa de contribuição para a comunidade open source - Parte 1

### Tchau, 2022 👋

2022 foi um ano incrível, porém bastante conturbado para mim.
No segundo semestre do ano, tive problemas pessoais que me deixaram afastado da programação por pelo menos dois meses.
Desde de que eu iniciei na computação, em dezembro de 2019, não tinha havido um período tão longo longe desse universo. Foi um período de dificuldade, mas também de muita superação e, principalmente, autoconhecimento.

Acredito que quando passamos por dificuldades que nos levam a ser melhor do que éramos antes, nosso sofrimento não é em vão e podemos encarar esses eventos adversos com serenidade. É dessa forma que eu enxergo esse momento e me sinto cheio de entusiasmo para construir um ano bastante prolífico em todos os aspectos, incluindo na tecnologia.

### Bem-vindo, 2023! 🤩

E para começar o ano com o pé direito, resolvi trazer uma lista de coisas sobre as quais pretendo me debruçar esse ano na área de TI. Todas são tecnologias, conceitos, abordagens para as quais estou bastante empolgado em utilizar e/ou aprender. Vamos a elas!

### Arquitetura e Design de Software

Em primeiro lugar, tenho a intenção de investir uma parte considerável do meu tempo no estudo de arquitetura e design de software. Esse é um tópico gigante e de extrema importância. É sobre como construir soluções que não só funcionam (agora), mas que continuarão a funcionar e entregar valor aos seus usuários de forma contínua, escalável, testável e que seja fácil de manter e resiliente a mudanças. Acredito que esse é o verdadeiro papel de um engenheiro de software. Nessa jornada pretendo fazer uso da seguinte literatura:

- [Clean Architecture](https://www.google.com/search?q=clean+architecture+book)
- [Solid Handbook](https://solidbook.io/)

### [NestJS](https://nestjs.com/)

Arquitetura e Design de Software é um tópico completamente desprendido de qualquer linguagem, paradigma ou tecnologia. Porém especificamente dentro do ecossistema Node, o NestJS é uma tecnologia que me chamou muita atenção pelo seu apelo à arquitetura. Além disso, trata-se de um framework “opinionado” e com “baterias inclusas”. Isso significa que o framework impõe seu jeito próprio de fazer as coisas e já tem a maioria das soluções comuns incluídas.

Isso é algo que não costuma agradar a todos, especialmente àqueles apegados a seu próprio jeito de fazer as coisas ou àqueles que gostam de ter total controle e flexibilidade.

Entretanto, é algo que reduz bastante o atrito quando se trabalha dentro de um time ou quando se deseja avançar de forma rápida e consistente. Isso porque todos os aspectos do desenvolvimentos já estão pré-moldados no framework e você não tem outra opção a não ser seguir o modelo. Claro, isso não garante que você vai ter código limpo ou que vai ter uma boa arquitetura - a ferramenta não te impede de construir soluções ruins ou código sujo -, porém facilita bastante o processo.

### [GraphQL](https://graphql.org/)

GraphQL é uma ferramenta que supostamente supera algumas limitações da abordagem RESTful. Sempre tive curiosidade de testar, mas sentia que precisava amadurecer meus conhecimentos antes de adentrar nessa tecnologia. Passado já algum tempo em que lido exclusivamente com REST, me parece que se aproxima o momento de aprender e usar GraphQL em algum projeto.

### NoSQL

Aqui acontece algo semelhante ao tópico anterior. Sempre trabalhei com bancos de dados relacionais, mas desde aprendi sobre a proposta que tenho vontade de testar bancos NoSQL. Nunca pareceu ser o momento certo, porém, mais uma vez porque eu tinha a impressão de que precisava consolidar meus conhecimentos em bancos de dados relacionais antes de adentrar nesse universo.

Atualmente me sinto razoavelmente confiante com SQL e me parece que o momento se aproxima de usar bancos como Mongo, Dynamo, etc.

### Container Orchestration Tool

Desde que entrei em contato com o mundo dos containers e Docker eu - e não sou o único a sustentar essa opinião - considero essa a tecnologia mais importante e revolucionária da área de tecnologia da informação dos últimos anos. Considero algo indispensável para qualquer pessoa que trabalhe com TI.

Me considero bastante versado em Docker, porém uma ferramenta que não está no meu kit é um orquestrador de containers. Um container sozinho não faz muita coisa: é no conjunto de containers rodando em paralelo e com comunicação mútua que está o verdadeiro poder dos containers. Conheço bem o `docker-compose`, que é um “orquestrador” de containers para o ambiente desenvolvimento. Ela dá um gostinho de como é realmente trabalhar com o conjunto de containers, mas trata-se de uma ferramenta exclusiva para teste e desenvolvimento.

Ano passado eu comecei a estudar Docker Swarm e pretendo dar continuidade a esses estudos esse ano. Se tudo correr bem, provavelmente terei tempo também de me aprofundar em ferramentas mais robustas como [Kubernetes](https://kubernetes.io/).

### Microservices

O tópico anterior casa muito bem com esse. Isso porque a maneira mais comum de se fazer deploy de microsserviços é através de containers. Eu nunca implementei de verdade um sistema usando microsserviços, mas sou versado sobre como funcionam e tenho muita vontade de colocar esse conhecimento em prática.

Tenho certeza que 2023 vai me proporcionar oportunidade de fazer isso e eu estarei aqui pra contar essa história!

### Cloud

Eis aqui outra tecnologia que é absolutamente indispensável para qualquer pessoa que trabalha com TI. Entender e dominar serviços de nuvem é algo primordial. É muito incomum hoje em dia uma empresa ter a própria infraestrutura. É simplesmente algo que não faz sentido em 90% dos casos. A nuvem oferece um universo vasto de serviços de altíssima qualidade, escalabilidade e disponibilidade com um modelo de precificação que faz sentido.

Eu estou bastante familiarizado com AWS e Google Cloud Platform, mas quero dar um passo adiante e conseguir minha primeira certificação este ano. E essa certificação será da [AWS](https://aws.amazon.com/), que é o provedor com que eu tenho trabalho nos meus últimos projetos.

### Infrastructure as Code

Por último, mas não menos importante, IaC. Gerenciar infraestrutura na nuvem manualmente pode se tornar algo extremamente trabalho e suscetível a erros quando se trata de uma grande operação. Por isso, ao longo do tempo as pessoas inventaram uma forma de representar infraestrutura na nuvem de uma maneira fácil de alterar, manter, versionar, colaborar e que é familiar a qualquer desenvolvedor: código.

Ao invés de navegar no console para criar uma instância EC2 com todas as configurações desejadas, ou fazer isso através da CLI, com uma ferramenta de IaC, o estado da infraestrutura é especificado em forma de código. Esse código é então “transpilado” em comandos passo a passo que alcançam na nuvem a infraestrutura representada e descrita por esse código.

Trata-se de um conceito bastante interessante e a ferramenta de IaC que eu pretendo utilizar chama-se [TerraForm](https://www.terraform.io/). Bastante empolgado pra por a mão na massa!

### Feliz ano novo! 🥳🎉

Em resumo, esses são os planos para 2023 em termos de aprendizado em tecnologia. É claro que pretendo trazer parte disso para cá à medida que eu for enveredando pelos caminhos que eu tracei. Uma das melhorias que eu pretendo implementar aqui é abrir um espaço para comentários, além de outras novidades para as quais não vou dar spoiler 🤫.

Bem, é isso. Desejo a todos muita saúde e paz! Que esse ano tenhamos em primeiro lugar sabedoria para discernir nossos objetivos e em segundo lugar coragem para empreendê-los.

Feliz 2023!


Minha lista de Tecnologias para 2023

ESM (ECMAScript Modules) é a maneira oficial normatizada de trabalhar com módulos no JavaScript. Hoje qualquer ambiente que suporta a linguagem é capaz de entender e processar scripts usando esse recurso. Mas a história nem sempre foi essa.

Quando surgiu o projeto do Node.js, esse padrão ainda não estava completamente formulado. O JavaScript não tinha uma solução nativa para a segmentação de código em arquivos. Mesmo assim, a comunidade precisava de uma maneira de dividir projetos cada vez mais complexos em arquivos menores e reutilizáveis.

Assim, surgiu um padrão amplamente adotado pela comunidade chamado CommonJS. Estamos falando da famosa sintaxe do `require` e `module.exports`. Mas essa maneira de escrever módulos não é reconhecida pela linguagem, de forma que, para que esse código pudesse rodar no navegador, era necessário que esses arquivos fossem pré-processador por uma espécie de compilador responsável por transformar o código resultante em JavaScript puro. Essas ferramentas, que ao longo do tempo evoluíram para servir a mais propósitos além desse, se chamam Module Bundlers, sendo um exemplo conhecido o WebPack.

Quando o Node surgiu, seu criador, [Ryan Dahl](https://en.wikipedia.org/wiki/Ryan_Dahl), implemetou o CommonJS nativamente no runtime, o que significa que o `require` e `module.exports` são entendidos _out of the box_, e essa se tornou a maneira padrão de escrever módulos no Node.js.

Tempos depois, veio a oficialização do ESM e a comunidade se viu no dilema entre as duas abordagens. O CommonJS continuou e continua sendo a forma padrão habilitada no Node, mas a comunidade viu a necessidade de adotar o ESM com o propósito de universalizar a linguagem; isto é, fazer com que haja um padrão único e oficial em qualquer ambiente.

Seguindo essa tendência, o Node adotou suporte para ESM, vindo com uma versão estável da implementação a partir de 2020.

Hoje, o ESM pode ser habilitado (>= v16) bastando para isso incluir no `package.json` a seguinte diretriz:

```json
...
"type": "module",
...
```

Alternativamente a extensão `.mjs` pode ser utilizada, sem a necessidade de adicionar a instrução no `package.json`, embora esse método seja considerado menos elegante.

Conquanto seja relativamente fácil ativar ESM no Node, é importante salientar que infelizmente as coisas ficam mais complicadas na prática.

Qualquer projeto real provavelmente fará uso de bibliotecas externas. E essas bibliotecas provavelmente foram originalmente escritas usando CommonJS. Isso significa que elas serão incompatíveis com o seu projeto, caso você esteja usando ESM.

Muitas libs já oferecem uma versão ESM em paralelo à original que funciona sem nenhuma configuração necessária. Mas isso está longe de se aplicar a todas.

A tendência é que a maneira oficial eventualmente se torne a padrão em todos os ambientes. Trata-se de um processo orgânico de amadurecimento e universalização da linguagem. Enquanto isso não acontece, usar o TypeScript é uma excelente alternativa. ESM é o padrão e, na transpilação, tudo volta para o CommonJS (se assim desejado), eliminando quaisquer incompatibilidades. Além do benefício da tipagem, claro!

Usar o TypeScipt com Node pode parecer intimidador à primeira vista, mas os benefícios são enormes. Isso, porém, é um tópico para um outro artigo.


Um Panorama do ESM no Node.js

Database Transactions é um tópico tão importante que a primeira frase da [documentação do PostgreSQL](https://www.postgresql.org/docs/current/tutorial-transactions.html) a respeito do assunto é, em tradução livre:

> Transações são um conceito fundamental em qualquer sistema de banco de dados.

De fato, esse conceito é um dos aspectos que torna o armazenamento e manipulação de dados em um banco SQL robusto e confiável - e ao mesmo tempo em que é essencial, trata-se também uma ideia bastante simples de ser entendida.

Recorrendo novamente à referida documentação, nos deparamos com o seguinte resumo (tradução livre):

> O ponto principal sobre uma transação é que ela junta várias ações em uma única operação de tudo ou nada. Os passos intermediários dessa operação não são visíveis a outras ações paralelas e se qualquer ação intermediária da operação falhar, então a operação falha como um todo e nenhuma alteração é feita no banco.

É uma ideia extremamente poderosa e muito simples de entender com um exemplo.

Vamos imaginar uma aplicação bancária que intermedia operações financeiras entre contas. De forma extremamente simplificada, poderíamos ter uma tabela chamada `conta` com um campo chamado `saldo` usado para manter o saldo atual das contas.

```sql
  CREATE TABLE conta (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(255),
    saldo DECIMAL(10,2)
    ...
  );

```

Além disso, provavelmente teríamos uma tabela para registrar as operações em si (histórico). No entanto, no intuito de tornar mais clara a abordagem, vamos considerar apenas a primeira tabela.

Se um usuário desejasse transferir uma quantia para outro, precisaríamos atualizar o saldo de duas contas: seria necessário subtrair a quantia de uma conta e acrescentar na outra. Em termos de ações no banco, isso se traduziria em duas atualizações na tabela `conta`. Especificamente, supondondo dois usuários, Alice e Bob (não poderia ser diferente), e imaginando que Alice deseja transferir R$ 100,00 para Bob, teríamos:

```sql
  UPDATE conta SET saldo = saldo - 100.00 WHERE nome = 'Alice';

  UPDATE conta SET saldo = saldo + 100.00 WHERE nome = 'Bob';
```

_Usaremos o campo_ `nome` _como filtro de seleção a fim de facilitar o entendimento. Numa aplicação real, usaríamos uma chave primária ou campo com restrição de unicidade._

Tudo bastante simples. Mas o que aconteceria se, durante essa operação, conseguíssemos atualizar o saldo de uma conta, mas não da outra? Isto é, o que acontece se apenas _uma_ das ações for bem sucedida? Claramente algo inaceitável. E um cenário como esses pode acontecer por uma infinidade de razões: perda de conexão com o banco, erro na query, etc. O que precisamos aqui é de uma maneira de garantir que as duas ações sejam realizadas ou a operação como um todo falhe. E é exatamente pra isso que servem as _transactions_.

No Postgres, uma transação é iniciada e concluída com os comandos `BEGIN` e `COMMIT`, respectivamente. Todas as ações ou comandos que estiverem entre eles serão executados de forma completa ou não terão nenhum efeito. Isso quer dizer que se algum passo intermediário falhar, os dados possivelmente alterados no caminho são restaurados para o estado inicial em que se encontravam antes de a transação ser iniciada. Usando esse recurso no nosso exemplo, teríamos:

```sql
  BEGIN;

    UPDATE conta SET saldo = saldo - 100.00 WHERE nome = 'Alice';

    UPDATE conta SET saldo = saldo + 100.00 WHERE nome = 'Bob';

  COMMIT;
```

E, dessa forma, poderíamos garantir que os saldos das duas contas seriam devidamente atualizados ou a operação como um todo falharia.

Existem ainda situações em que seria desejável salvar parte das alterações já feitas nos dados em determinado ponto de uma transação, mesmo que algum passo subsequente viesse a falhar. É possível ter esse tipo de controle refinado com transações, mas essa discussão está além dos nossos objetivos no momento.

Vale acrescentar que, em uma aplicação real, em que em geral um ORM é utilizado para facilitar e intermediar a interação da aplicação com o banco de dados, frequentemente transações já são utilizadas por debaixo dos panos para garantir a integridade dos dados. Mas em situações mais específicas, faz-se ainda necessário o uso explícito dessa funcionalidade, e os ORM’s normalmente possuem API’s para abranger esse tipo de circunstância.

Os cenários em que o uso de transações são necessários são abundantes. Um caso real de uso que posso destacar da minha experiência pessoal se deu quando estava construindo um sistema de automação de pedidos, o [Agilizze](https://www.instagram.com/agilizze.app). A atualização de status de um pedido precisava sempre ser acompanhada de uma inserção numa tabela de histórico, que poderia ser usada para acompanhar a evolução dos status de um pedido no curso do tempo. Isto é, a tabela principal, `pedido`, mantinha o status atual em um campo `status` e atualizações nesse campo deveriam vir juntamente com a inserção na tabela de histórico. Como se trata de duas ações distintas, seria possível que uma delas fosse bem sucedida e a outra não, fazendo com que surgissem inconsistências nos dados, não fosse o uso das transações.

Tempos depois, em contato com outras bases de código, me deparei com vários outros cenários que exigiam o uso desse recurso - e fiquei surpreso ao constatar que frequentemente ele não estava lá. Isso não implicava necessariamente que o banco em questão estivesse abarrotado de inconsistências. Mas se a tecnologia nos provê meios de nos salvaguardar de falhas (que sempre vão existir), é sempre bom estar do lado da segurança.


Database Transactions

### Como funciona um Bot no Telegram

No contexto do Telegram, um robô é uma conta/usuário que é capaz de receber, processar e enviar mensagens (e algumas outras ações) de forma programática, sem interação humana. Por trás dos panos, isso é feito através da comunicação entre os servidores do Telegram e um servidor web gerenciado pelo indivíduo ou entidade responsável por esse robô, comunicação que se dá através da [API de robôs do Telegram](https://core.telegram.org/bots/api).

Qualquer ação realizada por um robô (a ação mais comum, atualmente, é o envio de mensagens para usuários) se traduz em uma requisição feita a essa API, contanto que a mesma atenda aos critérios definidos na documentação da mesma. Por outro lado, existem ações que partem de uma fonte externa ao robô, mas dizem respeito a ele diretamente. O evento mais comum é, mais uma vez, o envio de mensagem - mas dessa vez, por parte de um usuário, endereçada ao robô. É evidente a necessidade de um mecanismo que possibilite que Telegram possa notificar o serviço por trás desse robô do acontecimento desse evento. Isso é feito através de um mecanismo chamado Webhook.

Em termos simples, **webhook nada mais é do que uma URL fornecida a um serviço externo no intuito de ser chamada por ele a fim de notificar do acontecimento de algum evento.** No caso do Telegram, é assim que são comunicados aos robôs eventos ocorridos dentro da plataforma que dizem respeito ao mesmo.

Diante dessas explicações, vê-se que para implementar e gerenciar um bot no Telegram, é necessário termos um serviço exposto na internet que possa ser notificado de acontecimentos na plataformas (através de webhooks) e que possa reagir a iniciar ações (através de chamadas na API do Telegram). Uma abordagem possível nesse caso seria a de manter esse serviço em pé em um servidor à espera de requisições. Porém essa solução geraria um grande desperdício de recursos quando o nosso servidor não estivesse processando requisições.

A proposta desse artigo é mostrar como fazer isso com uma solução chamada _Serverless Functions_, que se adequa perfeitamente a esse caso de uso.

### Serveless Functions

Serveless functions (FaaS) são uma maneira de distribuir software sem gerenciar qualquer infraestrutura. A designação "serveless" pode ser enganadora, porque afinal de contas nosso código precisa ser executado em _alguma_ infraestrutura, o ponto em questão é que o gerenciamento dessa infraestrutura é completamente abstraído do usuário.

FaaS são uma das formas mais antigas de se conseguir isso (a AWS introduziu seu serviço, Lambda, no final de 2014) e uma das abstrações mais completas também: tudo o que é fornecido ao provedor é o código do que será executado. Essa abstração tem um custo, porém: apenas algumas opções de runtime estão disponíveis e em versões específicas. Existem maneiras de superar essa limitação, mas que estão fora do escopo deste artigo. Existem também outras soluções serveless baseadas em containers, que eliminam toda essa limitação, pois o código que será executado vem de uma imagem fornecida e completamente controlada pelo usuário. Destaco aqui a [AWS App Runner](https://aws.amazon.com/apprunner/) e [Google Cloud Run](https://cloud.google.com/run), duas soluções/servicos fantásticos. Em termos de custo, entretanto, FaaS ainda são mais atrativas, isso se o serviço ou funcionalidade que se está tentando implementar e distribuir for simples o suficiente para "caber" dentro do contexto da execução de uma função - como é no caso de um bot no Telegram: como vimos, tudo que é necessário é expor uma URL para receber notificações sobre eventos e fazer chamadas na API para realizar ações. Vamos ver como podemos fazer isso utilizando o produto FaaS da AWS: Lambda.

### A função Lambda

#### `Handler`

Nesse projeto, nosso robô não fará nada particularmente útil. O objetivo aqui é mostrar como fazer o deploy desse robô em produção. Portanto, nosso robô apenas responderá com um "Hello, there" a cada mensagem enviada para o mesmo.

A função Lambda espera receber um arquivo chamado `index.js` que exporta uma função chamada `handler`. Aqui vamos usar TypeScript e será necessária uma etapa de transpilação para convertê-lo em JS. A função `handler` fica da seguinte forma:

```typescript
const handler: APIGatewayProxyHandler = async (event, context) => {
  // Handling Authentication
  try {
    assert(event.queryStringParameters?.token)
  } catch {
    return buildResponse({
      statusCode: 401,
      message: "Unauthorized",
    })
  }
  const queryStringToken = event.queryStringParameters.token

  try {
    assert(queryStringToken === botToken)
  } catch {
    return buildResponse({
      statusCode: 403,
      message: "Forbidden",
    })
  }

  assert(event.body, "Empty request body")
  const body = JSON.parse(event.body)

  // Take a look at the Telegram Bot Api to know more!
  // https://core.telegram.org/bots/api#update
  const chatId = body.message.chat.id
  assert(typeof chatId === "number")

  const responseData = await sendMessageTo("Hello, there!", chatId)
  try {
    // Again, check Telegram Bot Api:
    // https://core.telegram.org/bots/api#making-requests
    // "The response contains a JSON object, which always has a Boolean field 'ok'"
    assert(responseData.ok === true)
  } catch {
    console.warn("Unsuccessful request", "Reponse:", "\n", responseData)
  }

  return buildResponse({
    statusCode: 200,
    message: "ok",
  })
}
```

A função `handler` recebe dois argumentos no momento de sua invocação pela AWS. Basicamente, como se pode imaginar, eles contêm informações sobre o evento que ocasionou o disparo da função e o contexto. É possível ver exatamente os dados que são passados na [documentação](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html), mas o TypeScript pode nos dar uma grande força aqui. Instalando a lib @types/aws-lambda, temos ajuda de _intellisense_ para os tipos dos argumentos, bem como do formato da resposta.

#### Autenticação

Na primeira parte da função, lidamos com a autenticação. O token do nosso bot é armazenado numa variável de ambiente que é definida no console da AWS (nunca se deve armazenar segredos em código, deve-se usar variáveis de ambiente). Portanto, nosso programa terá acesso a essa variável no momento da invocação.

Procuramos o token na query string e se o mesmo estiver ausente ou diferir do nosso token, retornamos um `401` ou `403`, respectivamente. Vamos mostrar mais adiante como passar ao Telegram a url que deve ser chamada quando um novo evento acontecer com o nosso robô.

#### Enviado mensagens

Enviar uma mensagem do nosso robô consiste em nada mais do que chamar um endpoint da API do Telegram. Para fazer as requisições estamos usando a lib [axios](https://github.com/axios/axios). O schema dessa requisição pode ser verificado [nesse ponto da documentação](https://core.telegram.org/bots/api#sendmessage). Estamos encapsulando essa lógica na função `sendMessageTo` destacada abaixo:

```typescript
async function sendMessageTo(message: string, chat_id: number) {
  const response = await axios({
    method: "POST",
    url: `https://api.telegram.org/bot${botToken}/sendMessage`,
    data: {
      text: message,
      chat_id,
    },
  })

  // the response payload
  return response.data
}
```

### Subindo a função para a AWS

Tudo que precisamos fazer agora é subir o código para a AWS. Uma das maneiras de fazer isso (a mais simples) é comprimir a pasta que contém nosso projeto e fazer o upload da mesma através do console da AWS. Veja que é necessário incluir a pasta `node_modules`, que é onde estão nossas dependências.

Vê-se que esse é um método bastante manual e moroso, mas é também o mais simples. Penso em escrever um artigo sobre como construir uma pipeline CI/DC para funções Lambda no futuro, mas foge ao escopo deste projeto.

Note-se também que como se trata de um projeto TypeScript é necessário transpilá-lo antes de fazer o upload. Para evitar em parte o trabalho manual, criei o seguinte script que transpila e comprime o projeto:

```JSON
"scripts": {
    "build": "npx tsc && zip -r ../handler.zip *"
  }
```

Esse script cria o arquivo `index.js` e comprime nosso projeto na pasta `handler.zip` na raíz.

### Adicionando um _trigger_ à função

Uma função pode ser acionada por uma variedade imensa de eventos. No nosso caso, estamos interessados em invocá-la através da chamada de uma URL, nosso webhook. Para tanto, é necessário integrar nossa função Lambda com um serviço chamado **API Gateway**, que provê uma URL pública que direciona o tráfego para o nosso backend, nesse caso, nossa função. Esse é um processo um tanto moroso de descrever com palavras e imagens, portanto pretendo fazer um vídeo explicando com fazer isso passo-a-passo. A intenção aqui é a de dar uma visão geral do processo e, com sorte, o leitor conseguirá informações adicionais consultando a documentação. Nesse meio tempo, porém, fico à disposição para dar mais detalhes através do [e-mail](/sobre#me-encontre).

### Criando o robô e passando ao Telegram nosso webhook

#### Criando o robô

No Telegram se cria um robô... Através de um robô! Basta falar com o @botfather. No final do processo, seu robô será criado e você receberá seu token como output.

#### Informando o Telegram sobre nosso webhook

Os servidores do Telegram precisam saber qual URL devem chamar afim de notificar nosso serviço sobre um evento. O processo para fazer isso é simples. De posse do token, informamos ao Telegram da nossa URL (obtida através da integração do Lambda com o API Gateway) através de uma requisição ao endpoint `/setWebhook`. Para saber se o processo foi bem sucedido, podemos também consultar o `/getWebhookInfo`. Com esse propósito, criei uma pasta chamada `webhook-config`, que contém scripts para as duas finalidades. Mais uma vez fazemos uso de variáveis de ambiente para armazenar o `token` bem como nossa `url`. Nesse caso, porém, armazenamos essa informação no arquivo `.env`. Segue o código e os scripts:

```typescript
import assert from "assert"
import axios from "axios"
import { config } from "dotenv"

const result = config()
if (result.error) {
  throw Error("failed to load .env file")
}

async function setWebhook() {
  const resp = await axios({
    url: buildTelegramUrlEndpoint("setWebhook"),
    method: "POST",
    data: {
      url: `${getWebhookUrl()}?token=${getToken()}`,
    },
  })

  console.log(resp.data)
}

async function getWebhookInfo() {
  const resp = await axios({
    url: buildTelegramUrlEndpoint("getWebhookInfo"),
    method: "GET",
  })

  console.log(resp.data)
}

const map = {
  setWebhook,
  getWebhookInfo,
}

async function main() {
  const option = process.argv[2]
  if (!option) {
    throw Error("Command line argument not provided")
  }
  assert(option === "setWebhook" || option === "getWebhookInfo")

  await map[option]()
}

function getToken() {
  if (!process.env.TOKEN) {
    throw Error("Failed to load TOKEN key from environment")
  }
  const botToken = process.env.TOKEN
  return botToken
}

function getWebhookUrl() {
  if (!process.env.WEBHOOK_URL) {
    throw Error("Failed to load WEBHOOK_URL key from environment")
  }
  const webhookUrl = process.env.WEBHOOK_URL
  return webhookUrl
}

function buildTelegramUrlEndpoint(endpoint: string) {
  const token = getToken()
  return `https://api.telegram.org/bot${token}/${endpoint}`
}

main().catch((err) => {
  console.log(err)
  process.exit(1)
})
```

```JSON
"scripts": {
    "set-webhook": "ts-node-dev ./index.ts setWebhook",
    "webhook-info": "ts-node-dev ./index.ts getWebhookInfo"
  },
```

### Conclusão

Vimos como usar o serviços Lambda e API Gateway para criar um bot usando a API do Telegram. Trata-se de um caso de uso perfeito para FaaS e a melhor parte de tudo é que a AWS nos dá, ao tempo em que escrevo esse artigo, **um milhão** de invocações de graça por mês para sempre. Isto é, conseguimos fazer o deploy de um bot com custo zero. Esse é certamente um excelente momento para ser desenvolvedor.


Como fazer deploy de um bot do Telegram com AWS Lambda

_Nessa segunda parte, mostro na prática como conteinerizar o ambiente de desenvolvimento de uma aplicação simples que usa um banco de dados Postgres, Node.js no backend, frontend em React e Nginx como reverse-proxy. Veja a parte 1 [aqui](/artigos/conteinerizando-o-ambiente-de-desenvolvimento-com-docker-parte-1)_.

## A aplicação e a stack utilizada

A aplicação em questão é bastante simples, para não desviar a atenção do foco principal. Trata-se de uma aplicação web que exibe um catálogo de produtos com nome, preço e descrição.

![App](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/app.png)

Os dados ficam salvos num banco de dados Postgres e são acessados através de uma api feita em Node.js. O framework usado foi o [Fastify](https://www.fastify.io/) juntamente com o excelente ORM [Prisma](https://www.prisma.io/).

O frontend foi feito usando React no contexto do framework [Next.js](https://nextjs.org/).

Você pode conferir o repositório do projeto [aqui](https://github.com/Felipe-53/dev-env-with-docker)

Para fazer a ponte entre o backend e o frontend, aqui estamos usando Nginx como reverse-proxy. Seria possível também configurar o Next.js para fazer proxy das requisições destinadas ao backend. Porém, como é bastante desejável usar Nginx em produção, acho interessante usar também em desenvolvimento. Dessa forma, no mínimo, se ganha mais familiaridade com a ferramenta.

## Setup tradicional

Se não fôssemos usar containers, como já explicado na parte 1 desse artigo, precisaríamos ter instalados nas nossas máquinas, no mínimo:

- Node.js
- PostgreSQL
- Nginx

E todas essas dependências precisariam ser configuradas e inicializadas cuidadosamente para que o projeto funcionasse de forma correta.

O processo de conteinerização que vou apresentar em seguida pode parecer complicado à primeira vista. E de fato pode ser desnecessário se o projeto for muito simples ou se você está trabalhando sozinho. Porém eu teria me agradecido se tivesse feito isso com o projeto em que estou trabalhando atualmente, quando eu precisei trocar de máquina por um tempo enquanto a minha passava por manutenção. Mas sem mais demora, vamos ver como isso funciona.

## Conteinerização

Nosso projeto consistirá de quatro conteiners, conforme esquematizado na imagem abaixo:

![Diagrama](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/schema.png)

Esses conteineres serão orquestrados usando o docker-compose, como será mostrado mais adiante. Mas antes disso, vejamos como construir as imagens de cada um desses conteiners.

### Estrutura do projeto

Nesse projeto, usei a seguinte estrutura:

```bash
├── backend
├── dev-env
└── frontend
```

Para fins de demonstração, os três diretórios estão sob um único controle de versão git. Na prática, é muito melhor que **cada projeto tenha seu próprio controle de versão**. Observe também que existe um diretório dedicado exclusivamente à construção do ambiente de desenvolvimento, o `dev-env`. Isso porque, de fato, toda lógica e instruções contidas nele não pertencem nem ao frontend nem ao backend, mas à orquestração do ambiente de desenvolvimento. É nessa pasta que viverá o arquivo `docker-compose.yaml` através do qual será feita a orquestração de todos os conteiners de uma maneira simples e prática. Vejamos construir as imagens para o frontend e backend.

### Dockerfile

Na raíz de ambos os projetos, criamos o arquivo dev.Dockerfile. O prefixo 'dev' serve para diferenciá-lo do Dockerfile de produção, que é diferente (não abordado nesse artigo, provavelmente no futuro escreverei a respeito).

Vamos ver como fica o Dockerfile do backend e a estrutura do projeto.

#### **Backend - folder structure**

```bash
├── dev.Dockerfile
├── package.json
├── package-lock.json
├── prisma
├── src
└── tsconfig.json
```

#### **Backend - dev.Dockerfile**

```Docker
FROM node:lts-alpine

WORKDIR /app

COPY ./prisma ./prisma

COPY package*.json ./

COPY tsconfig.json ./

RUN npm install

RUN npx prisma generate

EXPOSE 3500

# prisma studio
EXPOSE 5555

CMD ["npm", "run", "dev"]
```

A observação mais importante sobre esse arquivo é a de que não estamos copiando nessa imagem o código fonte do projeto. Isso porque a pasta que contém o código fonte `src` será montada no conteiner a partir da pasta `src` presente na nossa máquina.

Estamos falando de [Bind Mounts](https://docs.docker.com/storage/bind-mounts/), um recurso do Docker que permite montar em um container um diretório da nossa própria máquina, de forma que todas as mudanças que fazemos localmente ficam visíveis ao conteiner. É como se déssemos ao conteiner uma porta de acesso a um diretório local. E isso é perfeito para o ambiente de desenvolvimento, pois geralmente usamos ferramentas de _fast refresh_ para poder acompanhar em tempo real as mudanças feitas no código. A montagem é feita no momento da inicialização do container ou pode ser feita também no arquivo `docker-compose.yaml`, como mostraremos mais à frente.

Outra observação se refere a algumas linhas de código que têm o intuito de fazer o uso adequado do ORM Prisma. O comando `npx prisma generate` gera o código necessário para trabalhar com os _Models_ definidos no arquivo `schema.prisma`. Adicionalmente, expomos a `5555` para poder acessar o Prisma Studio, uma interface web que permite a visualização e edição dos dados do banco. Foge do escopo falar mais sobre Prisma, mas posso afirmar que foi a melhor experiência de desenvolvimento que tive com qualquer ORM.

#### **Frontend - folder structure**

```bash
├── dev.Dockerfile
├── next.config.js
├── next-env.d.ts
├── node_modules
├── package.json
├── package-lock.json
├── postcss.config.js
├── public
├── src
├── styles
├── tailwind.config.js
└── tsconfig.json
```

#### **Frontend - dev.Dockerfile**

```Docker
FROM node:16-alpine

WORKDIR /app

COPY *.json ./
COPY *.js ./
COPY *.ts ./

RUN npm install

EXPOSE 3000

CMD [ "npm", "run", "dev" ]
```

O Dockerfile do frontend é ainda mais simples. Mais uma vez, o ponto de destaque é a omissão do fonte (contido na pasta `src`). A explicação é a mesma: essa pasta será montada no container para que possamos tirar vantagem do _fast refresh_ quando estivermos desenvolvendo.

### Banco de Dados e Nginx

#### Banco

A imagem do banco é a imagem oficial do Docker Hub. A única coisa necessária é configurar algumas variáveis de ambientes que determinam o nome do usuário, senha, banco padrão, etc. Como estamos falando de um ambiente de desenvolvimento, não é um problema deixá-las dentro do controle de versionamento.

#### Nginx

A imagem da Nginx tem o detalhe de precisar de um arquivo de configuração específico para o ambiente em questão. A ideia é direcionar todas as requisições prefixadas com `/api` para o backend e o resto para o frontend. Adicionalmente, no caso do frontend, é necessário estabelecer uma conexão Websocket, porque esse é mecanismo que possibilita o _fast refresh_. Basicamente, existe um servidor de desenvolvimento no project Next.js que observa mudanças nos arquivos. Quando há alguma alteração, o servidor envia ao browser essas mudanças via web socket.

Em suma, o arquivo de configuração nginx fica da seguinte forma:

```nginx
server {
  listen 5000;

  location / {
    proxy_pass http://frontend:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
  }

  location /api {
    proxy_pass http://api:3500;
  }
}
```

Outra observação a ser feita aqui é o uso de hostnames diferentes do tradicional `localhost`. Isso porque, como veremos em seguida, o Docker Compose cria um rede interna onde é atribuído a cada serviço o hostname que corresponde ao nome do mesmo.

## Docker Compose - orquestrando os containeres

O setup do ambiente de desenvolvimento encontra seu clímax e seu desfecho com o Docker Compose. Trata-se de uma ferramenta que serve para "amarrar" ou orquestrar conteiners de uma forma simples e prática. Tão simples, na verdade, que o único passo necessário é escrever um arquivo `.yaml` que descreve como os conteineres devem se comportar e interagir entre si.

Cada conteiner é definido como um serviço no arquivo, onde é possível especificar tudo que se define tradicionalmente com as opções do comando `docker run`. Aqui vamos nos concentrar nos seguintes pontos:

- Enrivonment Varibales
- Volumes
- Port Mapping
- Depencies

A melhor forma de abordar esses pontos é mostrar qual o papel deles dentro do projeto. Vamos comentar cada um dentro do contexto do arquivo em si, que segue abaixo:

```yaml
services:
  db:
    image: postgres
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: database
    volumes:
      - db_data:/var/lib/postgresql/data

  api:
    depends_on:
      - db
    build:
      context: ../backend
      dockerfile: dev.Dockerfile
    image: dev-api
    env_file:
      - ../backend/.env
    volumes:
      - type: bind
        source: ../backend/src
        target: /app/src
    ports:
      - 3500:3500
      - 5555:5555 # enable prisma studio access

  frontend:
    depends_on:
      - api
    build:
      context: ../frontend
      dockerfile: dev.Dockerfile
    image: dev-frontend
    volumes:
      - type: bind
        source: ../frontend/src
        target: /app/src
      - type: bind
        source: ../frontend/public
        target: /app/public
      - type: bind
        source: ../frontend/styles
        target: /app/styles

  proxy:
    depends_on:
      - api
      - frontend
    build:
      context: ./
      dockerfile: proxy.Dockerfile
    image: dev-proxy
    ports:
      - 5000:5000
    logging:
      driver: none

volumes:
  db_data:
```

Ao todo, temos quatro serviços, como dito anteriormente.

#### db

A imagem do banco é construída a partir da imagem oficial do Postgres. Aqui definimos algumas variáveis de ambiente sob a chave `environment`. Essas variáveis são usadas para configurar o banco, de forma que possamos acessá-lo a partir da api.

Outro ponto a ser ressaltado é que o Docker Compose cria uma rede interna onde cada serviço ganha um hostname que corresponde ao seu nome, como já foi dito. O ORM prisma usado no backend se conecta ao banco através de URL de conexão. O formato geral desta url é o que segue:

```bash
postgresql://<USERNAME>:<PASSWORD>@<HOSTNAME>:<PORT>/<DATABASE>?schema=<SCHEMA>
```

No contexto do Docker Compose essa url fica, portanto, da seguinte forma:

```text
postgresql://postgres:postgres@db:5432/database?schema=public
```

Por último, definimos um volume para persistir os dados escritos no banco sob a chave `volumes`. Note-se: por padrão os dados de um conteiner são efêmeros.**Docker Volumes** são usados para salvar na máquina hospedeira os dados escritos no conteiner. O que estamos usando aqui é o que se chama de **Named Volumes**. O destino dos dados na máquina hospedeira é determinado pelo Docker e pode ser acessado a partir do nome que damos ao volume, localizando-o com o comando `docker volume ls`. Os arquivos que estamos salvando aqui são os contidos no diretório `/var/lib/postgresql/data` - que é onde o container salva os dados do banco.

#### api

No serviço da api, especificamos sob a chave `build` qual imagem deve ser usada. Apontamos a imagem construída através do Dockerfile que escrevemos na sessão anterior.

O ponto a ser destacado nesse serviço é o Bind Mount feito da máquina local para o container. Como já explicado, é o que permite o fast refresh no contexto do desenvolvimento. Esse também é definido sobre a chave `volumes`, porque Bind Mounts são, afinal, um tipo de volume no Docker. Usamos a sintaxe extensa (verbosa) para que fique claro do que se trata:

```yaml
volumes:
  - type: bind
    source: ../backend/src
    target: /app/src
```

Ressalto também a chave `depends_on` que instrui o Docker Compose sobre a inicialização dos conteiners. Nesse caso estamos dizendo que o serviço `api` deve ser iniciado depois do serviço `db`. Um detalhe importante é que _inicializar_ o banco não quer dizer que o mesmo esteja pronto para receber conexões. Por isso, é necessário implementar uma lógica de conexão no backend. Se tiver interesse nesse ponto, dê uma olhada no [código](https://github.com/Felipe-53/dev-env-with-docker/blob/main/backend/src/startupHandlers.ts#L8).

Por último, fazemos o port mapping da porta 3500 e 5555, para poder acessar a api em isolamento (para fins de testes usando um client como [Insomnia](https://insomnia.rest/) ou [Postman](https://www.postman.com/)) e também para acessar o Prisma Studio.

#### frontend

Já falamos sobre todas as chaves abordadas nesse serviço. A única diferença aqui é que fazemos mais de um Bind Mount, para poder observar mudanças nos diretórios de interesse.

#### proxy

Por fim, temos o serviço `proxy`, que é responsável por direcionar o tráfego para o frontend ou para o backend. Abrimos a porta `5000` para aceitar conexões com o browser. Desabilitamos os logs na chave `logging` para não poluir o terminal.

A configuração é feita de acordo com o arquivo apresentado anteriormente. O Dockerfile é tão simples que não chegou a ser mencionado antes: substituímos o arquivo de configuração padrão por outro contendo as instruções adequadas, apresentadas aqui novamente:

```nginx
server {
  listen 5000;

  location / {
    proxy_pass http://frontend:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
  }

  location /api {
    proxy_pass http://api:3500;
  }
}
```

## Rodando o projeto

Tudo que é preciso para inicializar o projeto é ir na pasta `dev-env` e digitar no terminal:

```bash
docker-compose up
```

A opção `--build` pode ser usada se for necessário reconstruir alguma das imagens. A opção `-d` ou `--detach` pode ser usada para rodar a aplicação em segundo plano (por padrão, roda no terminal em que foi chamada)

O ambiente está agora plenamente configurado e é possível agora desenvolver localmente e ver as mudanças acontecerem em tempo real nos conteiners, graças aos Bind Mounts. A única dependência para reproduzir todo o ambiente de desenvolvimento agora é Docker.

## Conclusão

Pode parecer trabalhoso à primeira vista o setup do ambiente dev com Docker. Mas é um trabalho que se tem uma única vez. Agora tudo que é preciso para construir o ambiente é puxar os repositórios do github e rodar um comando 😍


Conteinerizando o ambiente de desenvolvimento com Docker - Parte 2

_Resolvi dividir esse artigo em dois posts, um de teor mais teórico (este) e outro de mão no código. Dessa forma forma o leitor já familiarizado com os conceitos poderá ir direto ao post que trata do exemplo prático, [aqui](/artigos/conteinerizando-o-ambiente-de-desenvolvimento-com-docker-parte-2)._

## Funciona na minha máquina

Em um mundo ideal, o ambiente de desenvolvimento seria idêntico ao ambiente de produção. Por “ambiente” entende-se todo o aparato de software que faz com que uma aplicação funcione de maneira adequada. Isso inclui desde o sistema operacional que a aplicação habita, ao runtime das linguagens utilizadas, até serviços como banco de dados, web servers, etc. Se fosse possível reproduzir localmente o ambiente de produção, eliminaria-se a possibilidade de bugs relacionados a divergências dessa natureza.

O problema é que enquanto em produção uma aplicação roda em um ambiente controlado, em desenvolvimento o projeto roda na máquina local do desenvolvedor **\***. E é improvável (senão impossível), que o desenvolvedor consiga reproduzir localmente de forma fiel o aparato de software usado em produção.

**\*** _Ou em um **servidor remoto**. Nesse caso, o setup do ambiente só precisa ser feito uma vez. Porém o problema persiste se esse ambiente precisar ser replicado em mais máquinas ou servidores. Portanto, também nesse caso a discussão que se segue continua a fazer sentido._

No meu caso pessoal, pouco tempo depois que comecei a desenvolver, ao tomar ciência de que em produção meu código (backend) seria invariavelmente executado no contexto de um servidor linux, me propus de imediato adotá-lo na minha máquina local. Até hoje uso Ubuntu no meu computador, o que acabou se mostrando uma escolha muito acertada, porque essa familiarização com o OS me ajudou bastante na hora de fazer os primeiros deploys (bastante manuais). Mas isso estava longe de resolver todos os problemas, como deve ficar evidente nas próximas linhas.

Imagine por um momento que estamos falando de um projeto que usa Node.js no backend, Nginx como web server e reverse-proxy e um banco de dados Postgres. Para trabalhar nesse projeto localmente, um colaborador novo precisaria ter todas essas dependências instaladas em sua máquina. Adicionalmente, precisaria verificar se dispõe das versões exatas usadas no projeto em questão. E depois rezar para que não venha a ter nenhum problema de incompatibilidade se estiver usando um OS diferente do de produção. Imagine agora que esse mesmo dev dá manutenção um uma aplicação legada que usa uma versão do banco de dados Postgres incompatível com a do projeto atual. Outro projeto usa MySQL e um outro MongoDB. Outro usa Apache ao invés de Nginx. Node na versão 10 vs. Node na versão 16 (alô [nvm](https://github.com/nvm-sh/nvm#intro)). O que fazer? Ter todas essas dependências localmente? Instalar e desinstalar versões diferentes a depender do que se está trabalhando no momento? Por fim, imagine que se tem dez desenvolvedores trabalhando nesse e em outros projetos, cada projeto dependendo de versões diferentes de software diferentes: em resumo, uma receita para o caos.

## A solução: containers

Containers são uma maneira de “empacotar” toda parafernalha de software necessária para rodar uma aplicação, desde o próprio sistema operacional até os programas e dependências utilizadas. Conteineres dão garantia de rodar sempre da mesma forma, independente de onde estejam, pois reproduzem seu ambiente de forma consistente, desde o nível do OS, conforme instruídos. Ao mesmo tempo, na perspectiva da máquina hospedeira, eles são apenas um processo, de forma que rodar e parar um conteiner é tão simples quanto abrir e fechar um navegador.

Diante dessas características, containers são a solução perfeita para eliminar problemas relacionados a inconsistências nos ambientes de dev vs. prod. Além disso, podem facilitar sobremaneira o trabalho dos devs, porque ao invés de ter que instalar localmente todas as dependências do projeto em que está trabalhando e configurá-las para que funcionem da forma correta, podem simplesmente construir o rodar um conteiner.

## Exemplo prático

Na [segunda parte](/artigos/conteinerizando-o-ambiente-de-desenvolvimento-com-docker-parte-2), mostro na prática como isso funciona com Docker e Docker Compose, conteinerizando uma aplicação web simples com React no frontend, Node.js no backend, um banco de dados Postgres e Nginx como reverse-proxy.


Conteinerizando o ambiente de desenvolvimento com Docker - Parte 1

A arquitetura de infraestrutura "serverless" é extremamente poderosa e conveniente, mas não está livre de seus próprios desafios.

Enquanto que um dos maiores benefícios dessa arquitetura é poder reduzir a 0 os custos na ausência de requisições (você não tem um servidor físico onde sua aplicação é hospedada, que ficaria ocioso nessas circunstâncias), por outro lado cria-se um problema conhecido como "cold start".

Cold start no contexto serverless tem a haver com a latência relacionada a inicializar um serviço pela primeira vez depois de um certo tempo sem demanda. Esse problema é inerente a esse tipo de arquitetura e existem muitas formas de minimizá-lo.

Um ponto que tem grande influência para o _nível_ de penalidade atribuído ao cold start tem a ver com as dependências usadas no projeto. Quanto maiores e numerosas, maior sua base de código e mais tempo para carregá-las e inicializadas.

O Prisma é um dos ORMs mais avançados do ecossistema Node.js. A experiência de desenvolvedor é a melhor que já tive em qualquer linguagem, e o time por trás do projeto está constantemente melhorando a ferramenta, trazendo novas features e expandindo suporte para vários de bancos de dados.

Entretanto, o Prisma até esse ponto era uma dependência que tinha um custo muito alto em termos de performance para se trazer para o ambiente serverless. Grande e pesado, o ORM trazia uma bagagem grande consigo, inclusive no runtime.

Não mais! Ou pelo menos podemos dizer que a penalidade de trazer o Prisma para ambientes serverless diminuiu significativamente. Os engenheiros do projeto reduziram em 9x os cold start nos benchmarks feitos com AWS Lambda.

Para alguém que usa esse stack em produção, posso afirmar que isso é grande. Parabéns ao time do Prisma 👏

Para saber os detalhes, confere o artigo no blog oficial do projeto 👇👇

https://www.prisma.io/blog/prisma-and-serverless-73hbgKnZ6t


Prisma ORM em ambientes Serverless

Esse post é uma referência para configurar um ambiente de desenvolvimento Node.js com TypeScript em 2023 o mais rápido possível. Pronto? Vamos lá!

Assumindo que você criou um novo diretório vazio para o projeto e que você está nele:

### 1. Inicializando um novo projeto

```bash
npm init -y
```

### 2. Instalando as dependências

```bash
npm i -D typescript ts-node-dev @types/node

```

- A biblioteca `typescript` nos dará o compilador da linguagem `tsc`

- `ts-node-dev` é usado para executar arquivos TypeScript diretamente, sem emitir o javascript resultante (se quiser saber mais, continue lendo), observando nossos aquivos e reinicializando nosso script quando modificações são detectadas

- Por fim, a lib @types/node é necessária para tipar as APIs do Node.js (`process`, `fs`, `__dirname`, `__filename`, etc)

### 3. Criando o arquivo `tsconfig.json`

```bash
npx tsc --init
```

##### Opcional: mudando a versão de saída do JavaScript

No `tsconfig.json`é possível apontar uma versão de saída para o JavaScript. Na chave `"target"`, use: `"ES2022"`. Isso vai fazer com que tenhamos uma versão moderna de saída para o JavaScript transpilado, o que fará com que o Node possa fazer uso de recursos recentes da linguagem, otimizando o código de saída, que é o que será efetivamente executado.

### 4. Criando o arquivo de entrada do projeto

```bash
touch index.ts
```

Um singelo "Hello, TypeScript" no `index.ts`:

```typescript
console.log("Hello, TypeScript!)
```

### 5. Configurando um script de desenvolvimento

No arquivo `package.json`, adicione o seguinte script:

```json
...

"scripts": {
    "dev": "ts-node-dev --respawn index.ts"
},

...

```

A mágica na verdade está na biblioteca `ts-node`, que é uma lib que faz uma compilação **JIT** (_just in time_) do TypeScript e passa o código resultante para o Node. Isso faz com que possamos rodar TypeScript diretamente no Node, sem emitir os arquivos javascript resultantes. O `ts-node-dev` é uma _wrapper_ em torno do `ts-node` que adiciona o recurso de observar nossos arquivos e reiniciar nosso script quando houver modificações. Isso nos dá uma experiência de desolvimento de primeira classe.

### 6. Rodando o script

```bash
npm run dev
```

Você deve ver no seu terminal algo como:

```bash
> ts-node-dev --respawn index.ts

[INFO] 14:02:46 ts-node-dev ver. 2.0.0 (using ts-node ver. 10.9.1, typescript ver. 4.9.5)
Hello, TypeScript!
```

Pronto! Agora você tem um ambiente de desenvolvimento com Node e TypeScript com _hot reloading_ configurado que irá reinicializar sua aplicação toda vez que houver mudança no código.

É isto. Happy coding!


O mínimo que você precisa para usar TypeScript no Node.js o mais rápido possível

## Uma rápida introdução

Deno é a mais nova criança do bairro. Concebido com o propósito de ser uma plataforma segura, eficiente e universal do JavaScript/TypeScript , o Deno veio para suplantar várias limitações existentes no ecossistema Node que, supostamente, seriam incorrigíveis. Na verdade, o Deno é um projeto do mesmo criador do Node, o [Ryan Dahl](https://en.wikipedia.org/wiki/Ryan_Dahl). Segundo a definição do site oficial:

> Deno (/ˈdiːnoʊ/, pronounced dee-no) is a JavaScript, TypeScript, and WebAssembly runtime with secure defaults and a great developer experience.
> It's built on V8, Rust, and Tokio.

Construí meu último projeto (meu blog pessoal) em cima dele e, posso garantir: o hype é real.

Hoje eu vou falar um pouco sobre como funciona o module system na plataforma.

## Deno’s Module System

### ESM

Ao contrário do Node, Deno usa [ECMAScript Modules](https://www.felipebarbosa.dev/artigos/um-panorama-do-esm-no-nodejs) por padrão, em detrimento do CommonJS, adotado antes que a linguagem tivesse um sistema de módulos definido.

Isso é maravilhoso, porque a comunidade ganha uma maneira universal de lidar com imports na linguagem (browser e server).

### Ausência de gerenciador de pacote centralizado

O Deno não se baseia no npm por padrão para gerenciar módulos. Ao invés disso, as dependências de um projeto são todas estabelecidas nos imports pelo próprio desenvolvedor em forma de URLs.

### URLs

Para usar uma biblioteca externa, você simplesmente importa a URL da biblioteca.

```typescript
import {
  add,
  multiply,
} from "https://x.nest.land/ramda@0.27.0/source/index.js";

function totalCost(outbound: number, inbound: number, tax: number): number {
  return multiply(add(outbound, inbound), tax);
}

console.log(totalCost(19, 31, 1.2));
console.log(totalCost(45, 27, 1.15));
```

Isso significa que você pode, por exemplo, distribuir pacotes e bibliotecas hospedando-as no próprio github!

### Como gerenciar?

Você pode estar se perguntando como se gerencia as dependências sem um `package.json`. Em primeiro lugar, as versões específicas das dependências podem ser especificadas na própria URL. Em segundo lugar, a maneira recomendada de lidar com isso é criando um arquivo chamado `deps.ts` central onde você importa todas as dependências do projetos e as re-exporta para serem utilizadas em outras partes do código. Na prática é quase equivalente a ter um `package.json` especificando as dependências e suas versões.

## Conclusão

Vale muito a pena experimentar o Deno no seu próximo projeto. Acho algo realmente promissor e vejo nele o futuro do server-side (e universal) JavaScript. A documentação é maravilhosa, confere lá:

[deno.land](https://deno.land/)


Deno's Module System 🦕

Compartilhando aqui um excelente recurso para se aprofundar ou iniciar sua jornada na nuvem.

AWS Skills Builder é a plataforma oficial de treinamento e certificação da AWS. Lá você encontra diversos cursos gratuitos e de **ótima** qualidade. Eu não conseguiria enfatizar o suficiente a qualidade do conteúdo, das animações, gráficos. Realmente o time por trás disso fez um trabalho incrível (o time de design e animação merece um aumento). Abaixo, um fragmento da animação da explicação sobre load balancers: simplesmente sensacional!

![load-balancer](https://tech-blog-assets.s3.sa-east-1.amazonaws.com/tech-notes-assets/aws-load-balancer.png)

Recomendo demais! Link abaixo.

[https://explore.skillbuilder.aws](https://explore.skillbuilder.aws)


AWS Skill Builder

Não é novidade que eu sou um grande fã de Serveless, FaaS e do serviço da AWS, Lambda. Já felei sobre isso nesse [post](https://www.felipebarbosatech.com.br/artigos/como-fazer-deploy-de-um-bot-do-telegram-com-aws-lambda#serveless-functions). Também não é novidade que eu sou um verdadeiro entusiasta das tecnologias que circundam o ecossistema dos containers e do Docker. Na verdade meu primeiro artigo aqui no blog foi exatamente sobre [isso](https://www.felipebarbosatech.com.br/artigos/conteinerizando-o-ambiente-de-desenvolvimento-com-docker-parte-1). O que eu talvez não tenha falado ainda é que é possível unir o que há de melhor dos dois mundos.

No final do ano de 2020, a AWS fez um anúncio de grande importância para o mundo da tecnologia: funções Lambda agora poderiam ser criadas a partir de imagens de container! As implicações disso são gigantes.

### O jeito tradicional

Uma das grandes limitações do Lambda no passado dizia respeito a restrições sobre como as funções deveriam ser "subidas" para a AWS. O jeito tradicional de se fazer isso era comprimir o projeto em um arquivo zip que poderia ter, no máximo, 50 MB!

Além da restrição do tamanho, tinha-se também a restrição do runtime: a plataforma oferecia apenas algumas opções das linguagens mais populares - e se você precisasse usar qualquer aplicação ou recursos de terceiros dentro do SO você estava basicamente sem sorte.

### Container Image Support

O que a AWS trouxe para o serviço foi a possibilidade de "empacotar" nossa função em uma imagem de container. Isso acaba com todas as restrições mencionadas anteriormente. É possível trazer para a função quaisquer serviços ou aplicações externos suportadas pelo SO e construí-la num ambiente sob o qual o desenvolvedor tem total controle.

Isso é simplesmente fantástico e revolucionário. Na verdade, quando eu pensei em como faria o deploy da [API de gerenciamento de conteúdo desse Blog](https://github.com/Felipe-53/tech-blog-cms-api), não tive dúvidas de como iria fazer isso. Em resumo:

Lamba + Docker = ❤️


Artigos