Webhooki vs. odpytywanie

Kiedy budujemy aplikacje internetowe, często korzystamy z wielu usług. W zdecydowanej większości przypadków składają się one z wielu różnych usług internetowych współpracujących ze sobą. W tego typu aplikacji internetowej, która składa się z wielu usług, sposób przesyłania danych to coś, co każdy deweloper musi rozważyć.

Jeśli chodzi o rozwiązanie tego problemu, dwa podejścia stały się głównym nurtem: webhooki i odpytywanie. Każda metoda zapewnia unikalny sposób pobierania i dostarczania danych z jednej usługi do drugiej. Wybór jednej z nich może mieć duży wpływ na efektywność Twojej aplikacji, jej możliwości w czasie rzeczywistym oraz ogólne doświadczenie użytkownika. Ten artykuł porówna webhooki i odpytywanie, przeanalizuje zalety i wady każdego podejścia oraz omówi, kiedy należy używać którego z nich.

Co to jest odpytywanie?#

Odpytanie (często określane jako odpytywanie API) jest procesem, w którym klient żąda określonych danych w regularnych odstępach czasu (powiedzmy, co x sekund), a serwer odpowiada na żądanie danymi.

Można to porównać do pytania: „Czy są jakieś nowe dane?” w regularnych odstępach czasu. Odpytanie można zrealizować poprzez żądania HTTP, gdzie klient wysyła żądanie GET do serwera, a serwer odpowiada przekazaniem żądanych danych.

Wyobraź sobie, że John zbudował produkt AI o nazwie Doc.AI i używa Logto do zarządzania tożsamościami użytkowników.

Frank to użytkownik, który zarejestrował się w produkcie Johna i stworzył swoje własne konto osobiste. Pewnego dnia Frank dołączył do przestrzeni roboczej utworzonej przez jego przyjaciela Davida. W tym momencie John chce wysłać do Franka e-mail z prośbą o włączenie uwierzytelniania wieloskładnikowego (MFA) w celu zwiększenia bezpieczeństwa jego konta, zanim John przyzna mu dostęp do dodatkowych wrażliwych zasobów.

Backend produktu Johna musi ciągle odpytywać odpowiednie API, aby wiedzieć, kiedy Frank dołączy do przestrzeni roboczej Davida.

Co to jest webhook?#

Webhook (czyli "callback HTTP") jest mechanizmem komunikacji danych w czasie rzeczywistym, w którym serwer wysyła dane do klienta, gdy wystąpi zdarzenie. Zamiast tego, by klient żądał danych, webhook przesyła je do klienta za każdym razem, gdy następuje aktualizacja.

Można to porównać do skrzynki odbiorczej dla Twojej aplikacji. Kiedy pewne wydarzenia mają miejsce — na przykład nowy użytkownik się rejestruje albo dokonana zostaje płatność — webhook wysyła komunikat do skrzynki, aby poinformować Twoją aplikację o tym, co się dzieje.

Kontynuując nasz przykład dotyczący Doc.AI, który użyliśmy wcześniej, aby wyjaśnić odpytywanie, oto jak wyglądałby diagram sekwencji, gdybyśmy używali webhooków do sprawdzenia, czy Frank dołączył do przestrzeni roboczej Davida:

Ważne różnice#

• Pochodzenie żądania Odpytanie jest inicjowane przez klienta (w naszym przykładzie, klientem jest Doc.AI a serwerem Logto), a webhook jest wyzwalany przez zdarzenie i rozpoczynany przez serwer.
• Zużycie zasobów Odpytanie jest marnotrawieniem zasobów obliczeniowych, ponieważ wysyła żądania w regularnych odstępach czasu, co skutkuje niską efektywnością zasobów obliczeniowych. Z drugiej strony, webhook jest inicjowany przez serwer „na żądanie”. W porównaniu do odpytywania, zarówno klient, jak i serwer zużywają znacznie mniej zasobów.
• Czas Odpytanie jest inicjowane przez klienta, więc klient może kontrolować czas pozyskiwania danych; jednak webhook jest inicjowany przez serwer i klient może jedynie odbierać i przetwarzać dane. Jednak ze względu na różne mechanizmy obu mechanizm webhooków może osiągnąć synchronizację danych w czasie rzeczywistym, czego nie można osiągnąć za pomocą odpytywania.

Który wybrać?#

Na podstawie mechanizmów odpytywania i webhooków, praktyką jest wybieranie odpytywania tylko wtedy, gdy dane są często aktualizowane, a wymaganie dotyczące czasu rzeczywistego dla danych nie jest surowe. W innych przypadkach lepszym wyborem będą webhooki.

Jednakże, wybierając webhooki, deweloperzy muszą zwrócić uwagę na następujące kwestie:

1. Jeśli system jest mocno zależny od pozyskanych danych, konieczne jest rozważenie posiadania planu awaryjnego na wypadek awarii webhooków i braku możliwości synchronizacji danych, w tym, ale nie tylko, wykorzystywanie odpytywania lub wymaganie, aby webhook posiadał mechanizm ponownego wysyłania danych.
2. W punkcie końcowym klienta odbierającym webhooki powinno się zastosować weryfikację sekretu API i sygnatury treści, itp., aby zapobiec atakom na klienta przez hakerów, którzy mogą podszyć się pod webhook.
3. Ponieważ webhook może wysyłać zduplikowane żądania, należy wtedy zastosować odpowiednie przetworzenie, aby zapobiec duplikacji danych i niespójności.

Logto, jako niezwykle popularne rozwiązanie identyfikacji użytkowników, oferuje bogate sceny webhooków i doskonałe zabezpieczenia. Korzystanie z Logto jako systemu identyfikacji użytkowników dla Twoich produktów, może być łatwo zintegrowane i dopasowane do różnych scenariuszy aplikacji.