Criando e Consumindo Webhooks de Pássaros

O processamento real e o armazenamento dos dados serão realizados por uma função lambda que é invocada pelo nosso balanceador de carga da aplicação (ALB). 

O primeiro passo é criar sua função lambda navegando até o serviço Lambda na AWS e clicando em “Criar Função.” Você será solicitado a atribuir um nome à sua função lambda e selecionar em qual linguagem de programação deseja escrever sua função. Para este exemplo, usamos Python como a linguagem de execução.

Agora precisamos desenvolver nossa função lambda. Por um momento, vamos supor que nosso balanceador de carga da aplicação foi configurado e está encaminhando o payload do webhook para a nossa função lambda – a lambda receberá um payload incluindo todos os cabeçalhos e o corpo. O payload é passado para nossa função lambda usando o objeto “event” como um dicionário. Você pode fazer referência aos cabeçalhos e ao corpo do payload de forma independente acessando os objetos “headers” e “body” dentro do payload. Neste exemplo, vamos simplesmente ler o cabeçalho “x-messagesystems-batch-id”, onde o ID do lote é um valor único criado pela Bird para o lote do webhook, e usá-lo como o nome do arquivo ao armazenar o corpo como um arquivo plano no S3; no entanto, você pode querer adicionar funcionalidades adicionais, como verificações de autenticação ou tratamento de erros, conforme necessário.

Ao armazenar o payload em um arquivo plano no S3, precisaremos definir o nome do bucket S3, a localização e o nome do arquivo onde os dados do payload serão armazenados. Em nossa função lambda de exemplo, fazemos isso dentro da função “store_batch”. Neste exemplo, vamos armazenar todo o lote como um único arquivo, o que ajuda a garantir que os dados sejam coletados e armazenados antes que a conexão HTTP entre a Bird e seu endpoint expire. Embora você possa ajustar as configurações de tempo limite da conexão em seu balanceador de carga, não há garantias de que a conexão não ficará sem resposta do lado da transmissão (neste caso, a Bird) ou de que a conexão não será encerrada antes que sua função lambda termine de executar. É uma boa prática manter sua função consumidora o mais eficiente possível e reservar atividades de processamento de dados para processos posteriores sempre que possível – como converter o payload em formato JSON em um arquivo CSV, ou carregar os dados do evento em um banco de dados.

É importante notar que você pode precisar atualizar as permissões para sua função lambda. Seu papel de execução precisará de permissões PutObject e GetObject para o S3. É uma boa prática aplicar o princípio do menor privilégio, então recomendo definir essas permissões apenas para o bucket S3 onde os payloads do webhook serão armazenados.

Um exemplo de nossa função lambda consumidora pode ser encontrado aqui.

Como uma nota rápida sobre o ID do lote:  a Bird irá agrupar eventos em um único payload, onde cada lote pode conter de 1 a 350 ou mais registros de eventos.  O lote receberá um ID único, que pode ser usado para visualizar o status do lote aproveitando a API de Webhooks de Eventos ou dentro da sua conta da Bird, clicando em um fluxo de webhook e selecionando “Status do Lote.” No caso de um payload de webhook não puder ser entregue, como durante um tempo limite de conexão, a Bird irá automaticamente tentar novamente o lote usando o mesmo ID do lote. Isso pode acontecer quando sua função lambda está sendo executada próximo ao tempo máximo de ida e volta de 10 segundos e é um motivo para otimizar a função consumidora para reduzir o tempo de execução.

Para lidar com todas as atividades de processamento de dados, recomendo criar uma função lambda separada que execute sempre que um novo arquivo for criado no bucket S3 – assim, o processamento dos dados é realizado de forma assíncrona à transmissão dos dados, e não há risco de perda de dados devido a uma conexão encerrada. Eu discuto a função lambda de processamento em uma seção posterior.