Polling versus webhook is de basiskeuze achter hoe een automatisering ontdekt dat er iets is gebeurd. Bij polling vraagt jouw systeem de bron op een schema: ‘al iets nieuws?’. Bij een webhook stuurt de bron een bericht zodra de gebeurtenis plaatsvindt, zodat jouw systeem meteen reageert.
Een simpele manier om het voor je te zien: polling is elk uur in je brievenbus kijken of er een pakket is bezorgd. Een webhook is de koerier die op je deurbel drukt op het moment dat hij het aflevert. De deurbel is sneller en je kijkt nooit voor niets, maar werkt alleen als de koerier ook echt een bel heeft om op te drukken. Biedt het bronsysteem geen webhooks, dan is polling je enige optie.
De afweging gaat verder dan snelheid. Polling verspilt het grootste deel van zijn verzoeken, want 99 van de 100 checks leveren “niets nieuws” op, en elke minuut een API aanroepen kan je rate limit opvreten of geld kosten per call. Een webhook gaat alleen af als er echt nieuws is, dus die schaalt beter. Maar hij vraagt een publiek adres dat altijd bereikbaar is, en ligt je server twee minuten plat wanneer de webhook binnenkomt, dan is die gebeurtenis simpelweg weg, tenzij de bron opnieuw probeert.
In de praktijk is de vuistregel helder. Realtime nodig en de bron ondersteunt het? Gebruik een webhook. Kan de bron niet pushen, of is een paar minuten vertraging prima? Dan is polling simpeler en prima betrouwbaar. Stripe, GitHub en Shopify sturen webhooks, terwijl veel oudere interne systemen je alleen laten pollen. Veel echte opzetten gebruiken allebei: een webhook voor de snelheid met een periodieke polling als vangnet voor het geval een seintje ooit gemist wordt.
Bij TopDevs kiezen we standaard voor webhooks vanwege de snelheid en vallen we terug op polling als een systeem niet kan pushen, vaak combineren we de twee zodat er niets tussendoor glipt.
