Webhooks vs. polling

När vi bygger webbappar har vi ofta flera tjänster. I de allra flesta fall består de av många olika webbtjänster som arbetar tillsammans. I den här typen av webbapp som består av flera tjänster, hur man överför data är något som varje utvecklare behöver överväga.

När det gäller att lösa detta problem har två tillvägagångssätt blivit mainstream: webhooks och polling. Varje metod ger ett unikt sätt att hämta och leverera data från en tjänst till en annan. Att välja en framför den andra kan ha stor inverkan på din applikations effektivitet, realtidsförmågor och övergripande användarupplevelse. Den här artikeln kommer att jämföra webhooks vs. polling, analysera fördelarna och nackdelarna med varje tillvägagångssätt, och diskutera när man ska använda vilken.

Vad är polling?#

Polling (ofta kallat API-polling) är processen där en klient begär specifik data med jämna mellanrum (låt oss säga var x sekund), och servern svarar med den begärda datan.

Tänk på det som att fråga, "Finns det någon ny data?" med jämna mellanrum. Polling kan implementeras via HTTP-förfrågningar, där klienten skickar en GET-förfrågan till servern och servern svarar med den begärda datan.

Föreställ dig att John byggde en AI-dokumentationsprodukt med namnet Doc.AI och använder Logto för användaridentitetshantering.

Frank är en användare som registrerade sig med Johns produkt och skapade sitt eget personliga konto. En dag går Frank med i ett arbetsutrymme som skapats av hans vän David. I det ögonblicket vill John skicka ett e-postmeddelande till Frank för att be honom slå på Multi-Factor Authentication (MFA) för att förbättra hans kontosäkerhet innan John ger honom tillgång till ytterligare känsliga resurser.

Johns produktback-end behöver ständigt polla relevanta API:er för att veta när Frank ansluter sig till Davids arbetsutrymme.

Vad är webhook?#

En webhook (dvs "HTTP callback") är en mekanism för realtidsdatakommunikation, varvid en server kommer att skicka data till en klient när en händelse inträffar. Istället för att en klient begär data, skickar en webhook ut det till klienten varje gång det finns en uppdatering.

Tänk på det som en inkorg för din applikation. När vissa händelser händer - till exempel, en ny användare registrerar sig eller en betalning görs - kommer en webhook att lägga ett meddelande i inkorgen för att låta din applikation veta vad som pågår.

Låt oss fortsätta med vårt Doc.AI-exempel som vi använde tidigare för att förklara polling. Här är hur sekvensdiagrammet kommer att se ut om vi använder webhooks för att ta reda på om Frank har anslutit sig till Davids arbetsutrymme:

Viktiga skillnader#

• Begärans ursprung Polling initieras av klienten (i vårt exempel är Doc.AI klienten och Logto är servern) och webhook utlöses av händelsen och startas av servern.
• Resursförbrukning Polling är slöseri med datorkapacitet eftersom den skickar förfrågningar med jämna mellanrum, vilket resulterar i låg effektivitet av datorkapacitet. Å andra sidan initieras webhook av servern "på begäran". Jämfört med polling konsumerar både klienten och servern mycket mindre resurser.
• Timing Polling initieras av klienten, så klienten kan kontrollera tidpunkten för datainsamling; Däremot initieras webhook av servern, och klienten kan bara ta emot och bearbeta data. Men tack vare de olika mekanismerna i de två kan webhook uppnå realtidsdatasykronisering, vilket inte kan uppnås med polling.

Vilken ska jag välja?#

Baserat på mekanismerna för polling och webhooks är den vanliga praxis att välja polling endast när datan ofta uppdateras och kravet på realtidsdata inte är strikt. I andra fall skulle webhooks vara ett bättre val.

Men när du väljer att använda webhooks behöver utvecklare uppmärksamma följande bekymmer:

1. Om systemet är starkt beroende av den förvärvade datan är det nödvändigt att överväga att ha en backup-plan för att förvärva data när webhooks misslyckas och data inte kan synkroniseras, inklusive men inte begränsat till polling eller kräva att webhooks har en återutsändningsmekanism, etc.
2. På klientens slutsida som tar emot webhooks, bör API-hemlighet och innehållssignaturverifiering osv. tillämpas för att förhindra hackare från att attackera klienten genom att förfalska webhooks.
3. Eftersom webhooks kan skicka dubbla förfrågningar, krävs motsvarande bearbetning vid denna tidpunkt för att förhindra dataduplicering och inkonsekvens.

Logto, som en enormt populär användaridentifieringslösning, erbjuder rika webhook-scener och utmärkt säkerhet. Genom att använda Logto som ditt produkts identitetssystem kan det enkelt integreras och passa i olika applikationsscener.