Webhooks vs. polling

Wanneer we webapps bouwen, hebben we vaak meerdere services. In de overgrote meerderheid van de gevallen bestaan ze uit veel verschillende webservices die samenwerken. In dit type webapp dat bestaat uit meerdere services, moet elke ontwikkelaar nadenken over hoe gegevens worden verzonden.

Als het gaat om het oplossen van dit probleem, zijn er twee benaderingen mainstream geworden: webhooks en polling. Elke methode biedt een unieke manier om gegevens van de ene service naar de andere op te halen en te leveren. Het kiezen van de ene boven de andere kan een grote impact hebben op de efficiëntie, realtime mogelijkheden en algehele gebruikerservaring van je applicatie. Dit artikel vergelijkt webhooks met polling, analyseert de voor- en nadelen van elke benadering en bespreekt wanneer welke te gebruiken.

Wat is polling?#

Polling (vaak API-polling genoemd) is het proces waarbij een client op regelmatige tijdstippen specifieke gegevens opvraagt (laten we zeggen, elke x seconden), en de server reageert met de gevraagde gegevens.

Zie het als het regelmatig vragen: “Zijn er nieuwe gegevens?” Polling kan worden geïmplementeerd via HTTP-verzoeken, waarbij de client een GET-verzoek naar de server stuurt en de server reageert met de gevraagde gegevens.

Stel je voor dat John een AI-documentatieproduct genaamd Doc.AI heeft gebouwd en Logto gebruikt voor gebruikersidentiteitsbeheer.

Frank is een gebruiker die zich heeft aangemeld bij het product van John en zijn eigen persoonlijke account heeft aangemaakt. Op een dag voegt Frank zich bij een werkruimte die door zijn vriend David is gemaakt. Op dat moment wil John Frank een e-mail sturen om hem te vragen Multi-Factor Authenticatie (MFA) in te schakelen om zijn accountbeveiliging te verbeteren voordat John hem toegang geeft tot extra gevoelige bronnen.

De backend van het product van John moet constant relevante API's peilen om te weten wanneer Frank zich bij de werkruimte van David voegt.

Wat is een webhook?#

Een webhook (d.w.z. "HTTP-callback") is een mechanisme voor realtime gegevenscommunicatie, waarbij een server gegevens naar een client stuurt wanneer een gebeurtenis plaatsvindt. In plaats van dat een client gegevens opvraagt, stuurt een webhook deze naar de client elke keer dat er een update is.

Zie het als een inbox voor je applicatie. Wanneer bepaalde gebeurtenissen plaatsvinden - bijvoorbeeld wanneer een nieuwe gebruiker zich aanmeldt of een betaling wordt gedaan - zal een webhook een bericht in de inbox plaatsen om je applicatie te laten weten wat er gaande is.

Laten we verdergaan met ons Doc.AI-voorbeeld dat we eerder gebruikten om polling uit te leggen. Hier is hoe het sequentiediagram eruit zou zien als we webhooks gebruiken om te weten of Frank zich bij de werkruimte van David heeft gevoegd:

Belangrijke verschillen#

• Oorsprong van verzoek Polling wordt geïnitieerd door de client (in ons voorbeeld is Doc.AI de client en Logto de server) en webhook wordt door een gebeurtenis getriggerd en gestart door de server.
• Verbruik van middelen Polling is een verspilling van computationele middelen omdat het met regelmatige tussenpozen verzoeken verzendt, wat resulteert in een lage efficiëntie van computationele middelen. Aan de andere kant wordt de webhook "on demand" door de server geïnitieerd. Vergeleken met polling verbruiken zowel de client als de server veel minder middelen.
• Timing Polling is client-geïnitieerd, dus de client kan de timing van het gegevens verkrijgen regelen; echter, webhook is server-geïnitieerd, en de client kan alleen gegevens ontvangen en verwerken. Vanwege de verschillende mechanismen van de twee kan webhook echter realtime gegevenssynchronisatie bereiken, wat niet door polling kan worden bereikt.

Welke moet ik kiezen?#

Op basis van de mechanismen van polling en webhooks is de gangbare praktijk om polling alleen te kiezen wanneer de gegevens vaak worden bijgewerkt en de realtime vereiste voor gegevens niet streng is. In andere gevallen zouden webhooks een betere keuze zijn.

Echter, bij het kiezen om webhooks te gebruiken, moeten ontwikkelaars aandacht besteden aan de volgende overwegingen:

1. Als het systeem sterk afhankelijk is van de verkregen gegevens, is het noodzakelijk om een back-upplan te overwegen om gegevens te verkrijgen wanneer de webhook mislukt en gegevens niet kunnen worden gesynchroniseerd, inclusief maar niet beperkt tot polling of vereisen dat de webhook een herzendmechanisme heeft, enz.
2. In de clientzijde-eindpunt die webhooks ontvangt, moeten API-secrets en inhoudshandtekeningverificatie, enz. worden toegepast om te voorkomen dat hackers de client aanvallen door de webhook te vervalsen.
3. Aangezien de webhook mogelijk dubbele verzoeken verzendt, is op dit moment corresponderende verwerking vereist om gegevensduplicatie en -inconsistentie te voorkomen.

Logto, als een enorm populaire gebruikersidentificatie-oplossing, biedt rijke webhookscènes en uitstekende beveiliging. Door Logto te gebruiken als je productenidentiteitssysteem, kan het gemakkelijk worden geïntegreerd en passen bij verschillende toepassingsscènes.