Webhookit vs. polling

Kun rakennamme verkkosovelluksia, meillä on usein useita palveluita. Useimmissa tapauksissa ne koostuvat monista eri verkkopalveluista, jotka toimivat yhdessä. Tässä tyyppisessä verkkosovelluksessa, joka koostuu useista palveluista, tietojen välittäminen on asia, jonka jokaisen kehittäjän on harkittava.

Tämän ongelman ratkaisemiseksi kaksi lähestymistapaa on noussut valtavirtaan: webhookit ja polling. Jokainen menetelmä tarjoaa ainutlaatuisen tavan hakea ja toimittaa tietoja yhdestä palvelusta toiseen. Valinta yhden menetelmän yli toisen voi vaikuttaa merkittävästi sovelluksesi tehokkuuteen, reaaliaikaisiin ominaisuuksiin ja kokonaisvaltaiseen käyttökokemukseen. Tässä artikkelissa verrataan webhookeja ja pollingia, analysoidaan kunkin lähestymistavan etuja ja haittoja sekä keskustellaan siitä, milloin käyttää mitäkin.

Mitä on polling?#

Polling (usein viitataan API-pollingiksi) on prosessi, jossa asiakas pyytää tiettyjä tietoja säännöllisin väliajoin (sanotaan vaikka, joka x sekunti), ja palvelin vastaa pyydetyillä tiedoilla.

Ajattele sitä kysymisenä: “Onko uusia tietoja?” säännöllisin väliajoin. Polling voidaan toteuttaa HTTP-pyyntöjen kautta, joissa asiakas lähettää GET-pyynnön palvelimelle ja palvelin vastaa pyydetyillä tiedoilla.

Kuvittele, että John rakensi AI-dokumentointituotteen nimeltä Doc.AI ja käyttää Logtoa käyttäjäidentiteetin hallintaan.

Frank on käyttäjä, joka rekisteröityi Johnin tuotteeseen ja loi henkilökohtaisen tilinsä. Eräänä päivänä Frank liittyy kaverinsa Davidin luomaan työtilaan. Tuolloin John haluaa lähettää sähköpostia Frankille pyytääkseen häntä ottamaan käyttöön monivaiheisen tunnistautumisen (MFA) parantaakseen tilinsä turvallisuutta ennen kuin John antaa hänelle pääsyn lisäherkkiin resursseihin.

Johnin tuotteen taustajärjestelmän on jatkuvasti pollattava asiaankuuluvia API:ita saadakseen tietää, milloin Frank liittyy Davidin työtilaan.

Mitä on webhook?#

Webhook (ts. "HTTP callback") on reaaliaikaisen datakommunikaation mekanismi, jossa palvelin lähettää tietoja asiakkaalle, kun tapahtuma tapahtuu. Sen sijaan, että asiakas pyytäisi tietoja, webhook työntää niitä ulos asiakkaalle aina, kun on päivitys.

Ajattele sitä sovelluksesi postilaatikkona. Kun tietyt tapahtumat tapahtuvat - esimerkiksi uusi käyttäjä rekisteröityy tai maksu tehdään - webhook pudottaa viestin postilaatikkoon kertoakseen sovelluksellesi, mitä tapahtuu.

Jatketaan aikaisemmin esitettyä Doc.AI-esimerkkiä selittääksemme pollingia. Tässä on, miltä sekvenssikaavio näyttää, jos käytämme webhookeja saadaksemme tietää, onko Frank liittynyt Davidin työtilaan:

Tärkeitä eroja#

• Pyynnön alkuperä Polling aloitetaan asiakkaan toimesta (esimerkissämme Doc.AI on asiakas ja Logto on palvelin) ja webhook käynnistyy tapahtumasta ja aloitetaan palvelimelta.
• Resurssien kulutus Polling on laskennallisten resurssien tuhlausta, koska se lähettää pyyntöjä säännöllisin väliajoin, mikä johtaa alhaiseen laskentaresurssien tehokkuuteen. Toisaalta webhook käynnistyy palvelimelta "kysyttäessä". Verrattuna pollingiin, sekä asiakas että palvelin kuluttavat paljon vähemmän resursseja.
• Ajoitus Polling on asiakkaan aloitteista, joten asiakas voi hallita tietohuollon ajoitusta; kuitenkin webhook käynnistyy palvelimelta, ja asiakas voi vain vastaanottaa ja käsitellä tietoja. Kuitenkin näiden kahden eri mekaniikan vuoksi webhook voi saavuttaa reaaliaikaisen tiedonsynkronoinnin, mitä polling ei voi.

Kumpi minun pitäisi valita?#

Pollingin ja webhookien mekanismeihin perustuen yleinen käytäntö on valita polling vain silloin, kun tiedot päivittyvät usein ja tiedoille ei ole tiukkaa reaaliaikaisuutta. Muissa tapauksissa webhookit olisivat parempi valinta.

Kuitenkin valittaessa käyttääkö webhookeja, kehittäjien on otettava huomioon seuraavat asiat:

1. Jos järjestelmä on voimakkaasti riippuvainen hankituista tiedoista, on harkittava varasuunnitelman olemassaoloa tietojen hankkimiseksi, kun webhook epäonnistuu ja tietoja ei voida synkronoida, sisältäen mutta ei rajoittuen pollingiin tai vaatien webhookilla olevan uudelleenlähetysmekanismin jne.
2. Asiakkaan puolen päätepisteelle, joka vastaanottaa webhookeja, API-salaisuuden ja sisällön allekirjoituksen vahvistus jne. tulisi soveltaa estämään hakkerit hyökkäämästä asiakasta vastaan väärentämällä webhookin.
3. Koska webhook voi lähettää päällekkäisiä pyyntöjä, vastaava käsittely on tarpeen estämään tietojen monistuminen ja epäjohdonmukaisuus.

Logto, erittäin suosittu käyttäjäntunnistamisratkaisu, tarjoaa runsaasti webhook-skenaarioita ja erinomaisen turvallisuuden. Käyttämällä Logtoa tuotteesi tunnistusjärjestelmänä, se voidaan helposti integroida ja sovittaa erilaisiin sovellustilanteisiin.