Os webhooks são uma forma leve, aberta e eficaz de trabalhar com eventos gerados por sistemas de terceiros com os quais poderá querer integrar-se.
De facto, uma das opções de integração que tem enquanto programador que se integra na Marketplacer é subscrever webhooks e ouvir eventos, incluindo, mas não se limitando a:
- Criação de produtos
- Actualizações de encomendas
- Avisos de expedição
No entanto, apesar dos benefícios da utilização de webhooks para integração, uma desvantagem que encontrará é a sua incapacidade de serem encaminhados diretamente para a sua máquina de desenvolvimento local.
Neste artigo, discutimos 3 formas que lhe permitem trabalhar dentro dessa restrição (compreensível).
Uma configuração típica de Webhook
Só para clarificar um pouco mais a questão, ao configurar um webhook num sistema de terceiros, normalmente fornece informações sobre:
- O "evento" que pretende receber, por exemplo, nova encomenda criada
- Os dados a enviar, por exemplo, a identificação da encomenda, o endereço de entrega, o montante da encomenda, etc.
- Para onde pretende que os dados sejam enviados (o destino do ponto de extremidade HTTP)
É neste último ponto que se pode ficar um pouco desorientado como programador que pretende trabalhar com estes eventos na sua máquina local - que destino configurar para que os eventos sejam entregues no localhost?
Embora não exista realmente um padrão de webhook, a maior parte dos webhooks são normalmente implementados como pedidos HTTP POST com uma carga útil de corpo JSON enviada para o sistema consumidor (neste caso, a sua máquina local).
Por exemplo, se eu tentar configurar um webhook na Marketplacer para enviar eventos de faturação para um ponto de extremidade local, obteria a seguinte resposta:
E embora possa obter um erro ligeiramente diferente noutras plataformas, o problema fundamental mantém-se: a plataforma de terceiros não pode encaminhar eventos de webhook para o localhost...
O resto deste artigo aborda a forma como pode trabalhar com este constrangimento.
1. Fingir
Esta é uma pequena batota, mas pode ser surpreendentemente útil...
Para utilizar esta abordagem, tudo o que tem de fazer é utilizar um cliente de API HTTP como o Postman ou o Insomnia e simplesmente fazer pedidos HTTP POST diretos para o seu ponto final de desenvolvimento localhost, essencialmente "fingindo" um pedido real de webhook. (Clientes como o Postman e o Insomnia, executados localmente na sua máquina de desenvolvimento, podem fazer pedidos para destinos do localhost).
Para tornar este pedido "falso" o mais realista possível, é necessário garantir que o replica o mais próximo possível do webhook original do sistema de origem. Para fazer isso, você precisará:
- Gerar um pedido real de webhook
- Receber esse pedido de webhook algures (por exemplo, webhook.site)
- Examinar a carga útil do corpo e os cabeçalhos
- Replicar esse corpo e cabeçalhos com o seu cliente HTTP (por exemplo, Postman)
Embora este método possa ser considerado um pouco trapaça, pode revelar-se muito útil nas fases iniciais do desenvolvimento, mesmo que tenha outros métodos à sua disposição.
Algumas das razões para tal são:
- Não é necessário ativar um webhook no sistema de origem, o que por vezes pode ser moroso.
- Pode manipular facilmente os cabeçalhos e o corpo da carga diretamente, mais uma vez sem ter de gerar um evento webhook real...
Embora esta opção seja útil nas fases iniciais (e possivelmente posteriores) do desenvolvimento, não lhe proporciona uma verdadeira experiência de integração de ponta a ponta. Nesse caso, terá de considerar uma das outras opções...
2. Utilizar uma aplicação de entrada
O segundo método requer a utilização de uma aplicação de entrada ou de tunelamento, sendo a mais conhecida a Ngrok.
O Ngrok (e aplicações semelhantes, como o Localtunnel), fornece-lhe um url encaminhável que mapeia até um ponto final localhost na sua máquina de desenvolvimento. Isto significa que pode fornecer o url encaminhável ao sistema que gera webhooks (por exemplo, Marketplacer), e esses webhooks acabarão por chegar ao seu computador local e, mais especificamente, à aplicação que está a construir.
As vantagens desta solução são:
- Muito fácil de configurar (o Ngrok e o Localtunnel também o são)
- Ngrok oferece um plano gratuito decente
- Recebe webhooks "reais" na sua aplicação
Uma das potenciais desvantagens desta abordagem são, obviamente, as considerações de segurança que pode ter ao abrir um túnel a partir da sua máquina local para o que é essencialmente um ponto final público. Dependendo do sector em que trabalha, ou da organização para a qual trabalha, utilizar algo como o Ngrok pode nem sequer ser uma opção disponível, dadas as dúvidas sobre potenciais ameaças à segurança.
Para obter um guia mais detalhado sobre a configuração do Ngrok, consulte o nosso artigo complementar no Medium.
Se as preocupações de segurança que rodeiam este método o impedem de o utilizar, então há outra abordagem que pode adotar...
3. Utilizar um proxy
Existem algumas variações deste padrão, mas depende essencialmente do facto de ter acesso a um ponto final encaminhável algures (o "proxy") que recebe (e armazena) o tráfego do webhook do sistema de origem. Em seguida, é necessário recuperar as mensagens de webhook armazenadas para a máquina local e, finalmente, encaminhá-las para a aplicação local.
Como pode imaginar, há várias formas de o conseguir, mas eu utilizo a seguinte arquitetura:
Esta abordagem assenta em 3 componentes:
- Uma Função HTTP do Azure
- Um barramento de serviço do Azure
- Assinante do barramento de serviços
Falamos um pouco mais sobre isso a seguir.
Função HTTP do Azure
Este actua como um ponto final HTTP encaminhável que pode ser utilizado para receber diretamente webhooks do sistema de origem, neste caso a Marketplacer. Quando a Função do Azure recebe um evento de webhook, coloca-o imediatamente no Service Bus.
Barramento de serviço do Azure
O Azure Service Bus actua como ambos:
- O armazenamento persistente (ou semi-persistente) para as mensagens do webhook
- O método de entrega dessas mensagens a um assinante (local)
Relativamente à persistência das mensagens, o Service Bus fornece-a, mas apenas por um período de tempo relativamente curto (por defeito, 14 dias).
Subscritor do barramento de serviços
Esta pode ser qualquer aplicação que possa subscrever o nosso Barramento de Serviços do Azure e ler as mensagens do mesmo. Neste caso específico, esta aplicação é uma aplicação de consola .NET que é activada sempre que uma mensagem é colocada no tópico relevante do Service Bus. Esse agente encaminha essas mensagens para qualquer ponto de extremidade do host local para o qual foi configurado.
Esta abordagem pode parecer como usar uma marreta para partir uma noz, mas funciona e tem as seguintes vantagens:
- Corresponde a algo mais próximo do que é provável ver num ambiente de produção empresarial
- A utilização de um barramento de serviços traz consigo todas as vantagens inerentes, incluindo, mas não se limitando a: segurança, encaminhamento, persistência de mensagens e entrega orientada por eventos.
As desvantagens desta abordagem são:
- Complexidade. Existem algumas partes móveis, o que torna tudo mais difícil de configurar, monitorizar e detetar falhas do que utilizar algo como o Ngrok
- Custo. Embora o custo real desta solução, com algumas centenas ou mesmo alguns milhares de webhooks, seja mínimo, não deixa de ter um custo potencial associado.
Em conclusão
0Todas as três opções são viáveis para iniciar o desenvolvimento com webhooks localmente e, como a maioria das coisas na vida, você escolherá aquela que atende às suas necessidades. No entanto, por pura simplicidade e eficácia, a opção ingress é difícil de superar num contexto de desenvolvimento local.
