Webhooks sind eine leichtgewichtige, offene und effektive Methode, um mit Ereignissen zu arbeiten, die von Systemen von Drittanbietern generiert werden, in die Sie sich integrieren möchten.
Eine der Integrationsmöglichkeiten, die Sie als Entwickler bei der Integration in Marketplacer haben, ist das Abonnieren von Webhooks und das Abhören von Ereignissen, einschließlich, aber nicht beschränkt auf:
- Produktentwicklung
- Aktualisierungen bestellen
- Benachrichtigungen über Sendungen
Trotz der Vorteile, die die Verwendung von Webhooks für die Integration mit sich bringt, besteht ein Nachteil darin, dass sie nicht direkt an Ihren lokalen Entwicklungsrechner weitergeleitet werden können.
In diesem Artikel werden 3 Möglichkeiten erörtert, die es Ihnen ermöglichen, innerhalb dieser (verständlichen) Beschränkung zu arbeiten.
Eine typische Webhook-Einrichtung
Nur um das Problem ein wenig weiter zu klären, wenn Sie einen Webhook auf einem System eines Drittanbieters einrichten, geben Sie normalerweise Informationen über:
- Das "Ereignis", das Sie erhalten möchten, z. B. neuer Auftrag angelegt
- Die zu sendenden Daten, z. B. Bestellnummer, Lieferadresse, Bestellbetrag usw.
- Wohin die Daten gesendet werden sollen (das Ziel des HTTP-Endpunkts)
Es ist dieser letzte Punkt, an dem Sie als Entwickler, der mit diesen Ereignissen auf Ihrem lokalen Rechner arbeiten möchte, ein wenig ins Stocken geraten können - welches Ziel konfigurieren Sie, damit die Ereignisse an localhost geliefert werden?
Obwohl es keinen wirklichen Webhook-Standard gibt, werden Webhooks in der Regel als HTTP-POST-Anfragen mit einem JSON-Textkörper implementiert, der an das konsumierende System (in diesem Fall Ihr lokaler Rechner) gesendet wird.
Wenn ich zum Beispiel versuche, einen Webhook auf Marketplacer zu konfigurieren, um Rechnungsereignisse an einen Localhost-Endpunkt zu senden, erhalte ich folgende Antwort:
Und während Sie einen etwas anderen Fehler auf anderen Plattformen erhalten können, bleibt das grundlegende Problem, die 3rd-Party-Plattform kann keine Webhook-Ereignisse an localhost weiterleiten...
Der Rest dieses Artikels beschreibt, wie Sie mit dieser Einschränkung arbeiten können.
1. Täuschen Sie es vor
Das ist zwar ein bisschen geschummelt, aber es kann überraschend nützlich sein...
Um diesen Ansatz zu verwenden, müssen Sie lediglich einen HTTP-API-Client wie Postman oder Insomnia verwenden und direkte HTTP-POST-Anfragen an Ihren Localhost-Entwicklungsendpunkt stellen, um eine echte Webhook-Anfrage zu "faken". (Clients wie Postman und Insomnia, die lokal auf Ihrem Entwicklungsrechner laufen, können Anfragen an localhost-Ziele stellen).
Um diese "gefälschte" Anfrage so realistisch wie möglich zu gestalten, müssen Sie sicherstellen, dass Sie sie so nah wie möglich an den Original-Webhook aus dem Quellsystem replizieren. Dazu müssen Sie Folgendes tun:
- Erzeugen Sie eine echte Webhook-Anfrage
- Empfangen Sie die Webhook-Anfrage irgendwo (z. B. webhook.site)
- Untersuchen Sie die Nutzdaten und Kopfzeilen
- Replizieren Sie diesen Body und die Header mit Ihrem HTTP-Client (z. B. Postman)
Auch wenn diese Methode als etwas übertrieben angesehen werden kann, kann sie sich in der Anfangsphase der Entwicklung als sehr nützlich erweisen, selbst wenn Sie andere Methoden zur Verfügung haben.
Einige der Gründe dafür sind:
- Sie müssen nicht erst einen Webhook auf dem Quellsystem auslösen, was manchmal zeitaufwendig sein kann.
- Sie können die Header und den Body Payload direkt manipulieren, ohne ein Webhook-Ereignis erzeugen zu müssen...
Während diese Option in den frühen (und möglicherweise späteren) Phasen der Entwicklung nützlich ist, bietet sie Ihnen keine echte End-to-End-Integration. In diesem Fall müssen Sie eine der anderen Optionen in Betracht ziehen...
2. Verwenden Sie eine Ingress-App
Die zweite Methode erfordert die Verwendung einer Ingress- oder Tunneling-App, von denen Ngrok die bekannteste ist.
Ngrok (und ähnliche Anwendungen wie Localtunnel) bieten Ihnen eine routbare URL, die auf einen Localhost-Endpunkt auf Ihrem Entwicklungsrechner verweist. Das bedeutet, dass Sie dem System, das Webhooks generiert (z. B. Marketplacer), die routbare URL zur Verfügung stellen können, und diese Webhooks werden schließlich ihren Weg zu Ihrem lokalen Rechner und insbesondere zu der von Ihnen erstellten App finden.
Die Vorteile dieser Lösung sind:
- Sehr einfach einzurichten (Ngrok und Localtunnel sind es sowieso)
- Ngrok bietet einen anständigen kostenlosen Plan
- Sie erhalten "echte" Webhooks für Ihre Anwendung
Einer der potenziellen Nachteile dieses Ansatzes sind natürlich die Sicherheitsbedenken, die Sie bei der Öffnung eines Tunnels von Ihrem lokalen Rechner zu einem im Grunde öffentlichen Endpunkt haben könnten. Abhängig von der Branche, in der Sie arbeiten, oder von der Organisation, für die Sie tätig sind, kann es sein, dass die Verwendung von Produkten wie Ngrok angesichts der Bedenken hinsichtlich potenzieller Sicherheitsbedrohungen für Sie gar nicht in Frage kommt.
Eine detailliertere Anleitung zur Einrichtung von Ngrok finden Sie in unserem Begleitartikel auf Medium.
Wenn die Sicherheitsbedenken, die mit dieser Methode verbunden sind, Sie davon abhalten, dann gibt es einen anderen Ansatz, den Sie wählen können...
3. Verwenden Sie einen Proxy
Es gibt einige Variationen dieses Musters, aber im Wesentlichen beruht es darauf, dass Sie irgendwo Zugang zu einem routbaren Endpunkt (dem "Proxy") haben, der den Webhook-Datenverkehr vom Quellsystem empfängt (und speichert). Anschließend müssen Sie die gespeicherten Webhook-Nachrichten auf Ihrem lokalen Rechner abrufen und sie schließlich an Ihre lokale Anwendung weiterleiten.
Wie Sie sich vorstellen können, gibt es eine Reihe von Möglichkeiten, wie dies erreicht werden kann, aber ich verwende die folgende Architektur:
Dieser Ansatz stützt sich auf 3 Komponenten:
- Eine Azure HTTP-Funktion
- Ein Azure Service Bus
- Service-Bus-Teilnehmer
Im Folgenden gehen wir näher auf diese ein.
Azure HTTP-Funktion
Dieser fungiert als routbarer HTTP-Endpunkt, der verwendet werden kann, um Webhooks direkt vom Quellsystem, in diesem Fall Marketplacer, zu empfangen. Wenn die Azure-Funktion ein Webhook-Ereignis empfängt, leitet sie es sofort an den Service Bus weiter.
Azure Service Bus
Der Azure Service Bus fungiert als beides:
- Der persistente (oder semi-persistente) Speicher für die Webhook-Nachrichten
- Die Methode der Zustellung dieser Nachrichten an einen (lokalen) Teilnehmer
Was die Persistenz der Nachrichten anbelangt, so bietet der Service Bus dies nur für einen relativ kurzen Zeitraum (Standardwert ist 14 Tage).
Service-Bus-Teilnehmer
Dies kann eine beliebige Anwendung sein, die unseren Azure Service Bus abonnieren und die Nachrichten daraus lesen kann. In diesem speziellen Fall ist diese Anwendung eine .NET-Konsolenanwendung, die jedes Mal ausgelöst wird, wenn eine Nachricht in das entsprechende Thema des Service Busses gestellt wird. Dieser Agent leitet diese Nachrichten dann an den Localhost-Endpunkt weiter, für den er konfiguriert wurde.
Dieser Ansatz mag so aussehen, als würde man mit einem Vorschlaghammer eine Nuss knacken, aber er funktioniert und hat die folgenden Vorteile:
- Entspricht eher dem, was man in einer Produktionsumgebung eines Unternehmens vorfindet
- Die Verwendung eines Service-Busses bringt alle damit verbundenen Vorteile mit sich, einschließlich, aber nicht beschränkt auf: Sicherheit, Routing, Nachrichtenpersistenz und ereignisgesteuerte Bereitstellung.
Die Nachteile dieses Ansatzes sind:
- Komplexität. Es gibt ein paar bewegliche Teile, was die Konfiguration, Überwachung und Fehlersuche schwieriger macht als bei Ngrok
- Kosten. Auch wenn die tatsächlichen Kosten für diese Lösung mit einigen hundert oder sogar einigen tausend Webhooks minimal wären, so sind damit dennoch potenzielle Kosten verbunden.
Zusammenfassend
0Alle 3 Optionen sind praktikabel, um die lokale Entwicklung mit Webhooks in Gang zu bringen, und wie bei den meisten Dingen im Leben werden Sie diejenige wählen, die Ihren eigenen Anforderungen entspricht. In Bezug auf Einfachheit und Effektivität ist die Ingress-Option in einem lokalen Entwicklungskontext jedoch kaum zu schlagen.
