AWS Serverless: Padrões Serverless Implementados (Parte 1 de 2)

Eu acho que a melhor maneira de aprender algo é praticá-lo e tentar explicá-lo, então é isso que vou fazer na próxima série de artigos. Essas postagens serão baseadas no incrível artigo de Jeremy Daly sobre padrões serverless. Não vou copiar as palavras de Jeremy aqui; portanto, para cada padrão, vá ao artigo acima para ler sua descrição. Vou fornecer uma implementação técnica e mencionarei mais recursos que achei interessantes. Vamos começar!

Configuração Comum

Todos os projetos terão uma configuração comum, o que é bastante simples. Primeiro, inicialize um projeto Node.js:

Em seguida, instale o Serverless Framework como uma dependência de desenvolvedor:

E, finalmente, crie um script para implantar o projeto:

(Supondo que você tenha um perfil local chamado serverless-local)

Padrão 01 — O Serviço Web Simples

Você pode ler a explicação aqui.

Para implementar esse padrão, precisamos criar um serviço com uma tabela do DynamoDB e, pelo menos, uma função que obtenha ou defina dados dela. Então, a aparência do serverless.yml será assim:

Precisamos instalar o plugin serverless-iam-roles-per-function. Estamos criando uma tabela DyanamoDB e passando o nome para as funções via variável de ambiente. Em cada função, estamos apenas dando as permissões necessárias.

Vamos dar uma olhada na implementação da função PutItem:

E, finalmente, vamos dar uma olhada na implementação da função GetItem:

Você pode conferir a solução completa aqui.

Padrão 02 — Webhook Escalável

Você pode ler a explicação aqui.

Nesse padrão, vamos introduzir uma fila SQS entre dois serviços e essa fila terá uma fila de mensagens não entregues caso encontremos algum erro. Então, vamos começar com o arquivo serverless.yml:

Este arquivo é um pouco mais complicado que o anterior. As partes interessantes estão na definição da fila, onde estamos definindo as propriedades dela. Vamos explicar agora quais são esses parâmetros, mas eu recomendo fortemente que você leia este artigo de Jeremy sobre filas SQS e leia todos os comentários também, pois tem informações interessantes por lá. Você também pode dar uma olhada neste artigo, onde o autor explica como o tratamento de erros no SQS funciona. E, finalmente, você pode ir para a documentação oficial.

O tempo limite de visibilidade é o tempo em que a mensagem permanece na fila sem que outros consumidores possam receber e processar a mensagem, aguardando a confirmação (ou o erro) do consumidor original. Se, após esse período, a fila não receber a solicitação de exclusão do consumidor original, a fila disponibilizará a mensagem para o próximo consumidor.

O período de retenção de mensagens é o momento em que uma mensagem é colocada em uma fila antes de ser excluída pelo sistema, se ninguém a consumir. O máximo é 14 dias.

A política de redrive é onde especificamos o que acontece quando uma mensagem não pode ser processada pelo consumidor. No nosso caso, estamos dizendo que gostaríamos de especificar um DLQ (Dead Letter Queue) e que uma mensagem será enviada para o DLQ após três tentativas falhas de processamento.

O código de enviar mensagens é o mesmo (ou muito semelhante) que Jeremy tem em seu post sobre SQS:

E o código do worker e do DLQReader são basicamente os mesmos:

Você pode conferir a solução completa aqui.

Finalizando

Neste artigo, vimos a implementação de alguns padrões do excelente artigo de Jeremy Daly. Continuaremos com isso no artigo seguinte.

Espero que tenha te ajudado!!

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store