Zawsze chciałem porozmawiać w czasie rzeczywistym.

Zrobiłem to lata temu w PHP + Ajax + Mysql i zepsułem mój serwer. Potem spróbowałem z Flash + plik tekstowy. Poddałem się i nie próbowałem od 10 lat. Ale ostatnio słyszałem o webhookach i websockets. I obaj wydają się być sposobem na to, ale tak naprawdę nie rozumiem różnicy. Każdy może wyjaśnić?

Webhooki

Webhooki służą do komunikacji między serwerami. Działają przez jeden serwer, który mówi innemu serwerowi, że chce, aby dane były wysyłane do określonego adresu URL, gdy coś się dzieje.

W tym artykule omówiono niektóre zastosowania elementów webhook w popularnych usługach. Ta organizacja dużo mówi o używaniu ich w kontekście RESTful API.

Websockets

Gniazda sieciowe służą (zwykle) do komunikacji między serwerem a przeglądarką. Serwer obsługuje serwer WebSocket, a klienci mogą otwierać połączenie z tym serwerem. Jest to popularne obecnie głównie dlatego, że jest szybsze i mniej pochłaniające zasoby niż starsze sposoby rozwiązywania problemu, takie jak długie odpytywanie / COMET .

Możliwe jest połączenie 2 serwerów za pomocą gniazd sieciowych , ale zwykle nie do tego są one używane.

Zamieszanie

Chociaż jeden z nich jest (wyłącznie) serwerem-serwerem, a drugi (głównie) serwerem-przeglądarką, technologie te są często omawiane w tych samych miejscach, prawie tak, jakby rozwiązują te same problemy. Jeśli spojrzysz w górę łańcucha wystarczająco wysoko, zobaczysz, że oba rozwiązania rozwiązują problem komunikacji „w czasie rzeczywistym”, ale rozwiązują różne aspekty tego problemu na bardzo różne sposoby .

Jedną z sytuacji, w której może wystąpić bezpośrednie porównanie, jest tworzenie interfejsu API, który będzie używany przez serwer innej firmy. W tej sytuacji, można zapewnić API webhook lub websocket API . Oba pozwalają stronie trzeciej na szybkie pobieranie aktualizacji:

• Jeśli wybierzesz webhooki, ta strona trzecia nadal będzie musiała wymyślić sposób na przekazanie zmian, o których mówisz, do przeglądarek klienta.
• Jeśli udostępniasz interfejs API sieci Web, strona trzecia może po prostu skonfigurować swoją witrynę, aby każdy z jej użytkowników łączył się bezpośrednio z interfejsem API sieci Web, a ich serwery musiały wykonywać mniej pracy.

Oto dodatkowe informacje dotyczące wyboru między elementami webhook a websockets.

Komunikacja serwer-serwer za pośrednictwem gniazd sieciowych stała się popularna dzięki nowej generacji aplikacji chatbotów. Obecnie wiele chatbotów działa za pośrednictwem gniazd sieciowych, a ich podstawową zaletą jest to, że nie wymagają publicznego adresu URL dla wewnętrznych, prywatnych botów. W tym środowisku poniżej znajdują się wskazówki, kiedy należy rozważyć użycie elementów webhook, a nie websockets.

Websockets

• Jeśli Twoja aplikacja jest aplikacją przeglądarki, użyj gniazd sieci Web, ponieważ aplikacja nie może odbierać elementów webhook.
• Jeśli Twoja aplikacja jest aplikacją serwera odbierającą wiadomości z usługi przez Internet i nie chcesz otwierać zapory, rozważ użycie gniazd sieciowych. Niektóre firmy wymagają przeglądu bezpieczeństwa informacji przed otwarciem takich połączeń.

Webhooki

• Jeśli aplikacja serwera wymaga wielu subskrypcji, bądź przygotowany na obsługę liczby otwartych połączeń WebSocket z Twoim serwerem ( zobacz ten artykuł na temat 1 mln połączeń WebSocket) lub przełącz się na webhooki. Niektóre popularne chatboty przeszły z gniazd sieciowych do webhooków, aby poprawić skalowalność.
• Jeśli Twoja aplikacja serwerowa działa jako funkcja chmury w (AWS Lambda, Google Cloud Functions itp.), Użyj webhooków, ponieważ Twoja aplikacja nie będzie utrzymywać otwartego połączenia websocket.
• Jeśli Twoja aplikacja serwerowa działa na darmowej warstwie Heroku, użyj webhooków, ponieważ Dyno pójdzie spać i musi spać przez 6 godzin dziennie, chyba że ręcznie poinstruujesz serwer, aby spał.