Les webhooks sont un moyen léger, ouvert et efficace de travailler avec des événements générés par des systèmes tiers que vous souhaitez intégrer.
En effet, l'une des options d'intégration dont vous disposez en tant que développeur intégrant Marketplacer est de souscrire à des webhooks et d'écouter les événements, y compris, mais sans s'y limiter :
- Création de produits
- Mise à jour des commandes
- Notifications d'expédition
Cependant, malgré les avantages de l'utilisation des webhooks pour l'intégration, l'un des inconvénients que vous rencontrerez est leur incapacité à être acheminés directement vers votre machine de développement locale.
Dans cet article, nous examinons trois façons de travailler en tenant compte de cette contrainte (compréhensible).
Une configuration typique de Webhook
Pour clarifier un peu plus le problème, lorsque vous configurez un webhook sur un système tiers, vous fournissez généralement des informations sur :
- L'"événement" que vous souhaitez recevoir, par exemple la création d'une nouvelle commande
- Les données à envoyer, par exemple l'identifiant de la commande, l'adresse de livraison, le montant de la commande, etc.
- L'endroit où vous souhaitez que les données soient envoyées (la destination du point final HTTP)
C'est sur ce dernier point que vous pouvez vous retrouver un peu perdu en tant que développeur souhaitant travailler avec ces événements sur votre machine locale - quelle destination devez-vous configurer pour que les événements soient livrés à l'hôte local ?
Bien qu'il n'existe pas vraiment de norme pour les webhooks, ceux-ci sont généralement mis en œuvre sous la forme de requêtes HTTP POST avec un corps JSON envoyé au système consommateur (dans ce cas, votre machine locale).
Par exemple, si j'essaie de configurer un webhook sur Marketplacer pour envoyer des événements Invoice à un point d'extrémité local, j'obtiendrai la réponse suivante :
Et bien que vous puissiez obtenir une erreur légèrement différente sur d'autres plateformes, le problème fondamental demeure, la plateforme tierce ne peut pas acheminer les événements webhook vers localhost...
Le reste de l'article traite de la manière dont vous pouvez travailler en tenant compte de cette contrainte.
1. Faire semblant
Il s'agit d'une sorte de tricherie, mais elle peut s'avérer étonnamment utile...
Pour utiliser cette approche, il vous suffit d'utiliser un client API HTTP tel que Postman ou Insomnia et d'effectuer des requêtes HTTP POST directes vers votre point de terminaison de développement localhost, en "simulant" une véritable requête webhook. (Les clients tels que Postman et Insomnia fonctionnant localement sur votre machine de développement peuvent effectuer des requêtes vers des destinations localhost).
Afin de rendre cette "fausse" requête aussi réaliste que possible, vous devrez vous assurer de la reproduire aussi près que possible du webhook original du système source. Pour ce faire, vous devrez
- Générer une vraie demande de webhook
- Recevoir cette demande de webhook quelque part (par exemple, webhook.site)
- Examiner la charge utile du corps et les en-têtes
- Reproduisez ce corps et ces en-têtes avec votre client HTTP (par exemple, Postman).
Bien que cette méthode puisse être considérée comme une sorte de tricherie, elle peut s'avérer très utile aux premiers stades du développement, même si vous disposez d'autres méthodes.
Les raisons en sont notamment les suivantes :
- Il n'est pas nécessaire de déclencher un webhook sur le système source, ce qui peut parfois prendre du temps.
- Vous pouvez facilement manipuler les en-têtes et le corps du message directement, sans avoir à générer un événement webhook...
Bien que cette option soit utile aux premiers stades (et éventuellement aux stades ultérieurs) du développement, elle ne vous offre pas une véritable expérience d'intégration de bout en bout. Dans ce cas, vous devez envisager l'une des autres options...
2. Utiliser une application d'entrée
La deuxième méthode nécessite l'utilisation d'une application d'entrée ou de tunnel, la plus connue étant Ngrok.
Ngrok (et les applications similaires telles que Localtunnel), vous fournit une url routable qui correspond à un point de terminaison localhost sur votre machine de développement. Cela signifie que vous pouvez fournir l'URL routable au système générant des webhooks (par exemple Marketplacer), et que ces webhooks finiront par arriver sur votre machine locale, et plus précisément sur l'application que vous êtes en train de construire.
Les avantages de cette solution sont les suivants :
- Très facile à mettre en place (Ngrok & Localtunnel le sont de toute façon)
- Ngrok propose un plan gratuit décent
- Vous obtenez de "vrais" webhooks livrés à votre application
L'un des inconvénients potentiels de cette approche est bien sûr les considérations de sécurité que vous pouvez avoir en ouvrant un tunnel depuis votre machine locale vers ce qui est essentiellement un point d'extrémité public. Selon le secteur dans lequel vous travaillez, ou l'organisation pour laquelle vous travaillez, l'utilisation de quelque chose comme Ngrok peut même ne pas être une option disponible pour vous étant donné les doutes sur les menaces de sécurité potentielles.
Pour un guide plus détaillé sur la mise en place de Ngrok, veuillez vous référer à notre article complémentaire sur Medium.
Si les problèmes de sécurité liés à cette méthode vous empêchent de l'utiliser, il existe une autre approche...
3. Utiliser un proxy
Il existe quelques variantes de ce modèle, mais il repose essentiellement sur l'accès à un point d'extrémité routable quelque part (le "proxy") qui reçoit (et stocke) le trafic webhook du système source. Vous devez ensuite récupérer les messages webhook stockés sur votre machine locale, et enfin les acheminer vers votre application locale.
Comme vous pouvez l'imaginer, il y a plusieurs façons de procéder, mais j'utilise l'architecture suivante :
Cette approche repose sur trois éléments :
- Une fonction HTTP Azure
- Un bus de service Azure
- Abonné au bus de service
Nous en parlons plus en détail ci-dessous.
Fonction HTTP Azure
Il s'agit d'un point d'extrémité HTTP routable qui peut être utilisé pour recevoir directement des webhooks du système source, dans ce cas Marketplacer. Lorsque la fonction Azure reçoit un événement webhook, elle le place immédiatement dans le bus de services.
Azure Service Bus
L'Azure Service Bus joue ces deux rôles :
- Le magasin persistant (ou semi-persistant) pour les messages du webhook
- La méthode de distribution de ces messages à un abonné (local)
En ce qui concerne la persistance des messages, le bus de service la fournit, mais seulement pour une période relativement courte (14 jours par défaut).
Abonné au bus de service
Il peut s'agir de n'importe quelle application qui peut s'abonner à notre bus de service Azure et lire les messages qu'il contient. Dans ce cas particulier, il s'agit d'une application console .NET qui se déclenche chaque fois qu'un message est placé sur le sujet correspondant du bus de services. Cet agent transmet ensuite ces messages au point de terminaison localhost pour lequel il a été configuré.
Cette approche peut sembler comparable à l'utilisation d'un marteau de forgeron pour casser une noix, mais elle fonctionne et présente les avantages suivants :
- Correspond à une situation plus proche de celle que l'on peut rencontrer dans un environnement de production d'entreprise.
- L'utilisation d'un bus de services comporte tous les avantages inhérents, y compris, mais sans s'y limiter, la sécurité, le routage, la persistance des messages et la livraison en fonction des événements.
Les inconvénients de cette approche sont les suivants :
- Complexité. Il y a plusieurs pièces mobiles, ce qui rend l'ensemble plus difficile à configurer, à surveiller et à détecter les erreurs que si l'on utilisait quelque chose comme Ngrok
- Coût. Bien que le coût réel de cette solution avec quelques centaines ou même quelques milliers de webhooks soit minime, elle s'accompagne toujours d'un coût potentiel.
En conclusion
0Les trois options sont viables pour vous permettre de développer localement des webhooks et, comme pour la plupart des choses dans la vie, vous choisirez celle qui répond à vos besoins. Cependant, en termes de simplicité et d'efficacité, l'option ingress est difficile à battre dans un contexte de développement local.
