Pusher — co to jest, platforma real-time i integracja w aplikacjach

Czym jest Pusher?

Pusher — chmurowa usługa do dwukierunkowej komunikacji w czasie rzeczywistym, założona w 2011 roku. Zapewnia gotową infrastrukturę do wysyłania i odbierania komunikatów w czasie rzeczywistym bez konieczności zarządzania własnym serwerem WebSocket. Pusher jest używany do budowy czatów, powiadomień na żywo, wspólnego edytowania i tablic wyników w grach.

W przeciwieństwie do bibliotek takich jak Socket.IO, które wymagają wdrożenia i utrzymania własnego serwera, Pusher działa w modelu SaaS (Software as a Service). Programista rejestruje się, otrzymuje klucze (app_id, key, secret) i używa REST API Pusher do publikowania zdarzeń. Infrastruktura serwerowa jest w pełni zarządzana przez platformę Pusher.

Według danych oficjalnego bloga Pusher (2025), platforma obsługuje ponad 250 000 aktywnych projektów na całym świecie. Wśród znanych klientów są GitHub (powiadomienia w czasie rzeczywistym), Trello (synchronizacja tablic) i Intercom (czat wsparcia). Pusher wspiera centra danych w USA, Europie i Azji w celu minimalizacji opóźnień.

Historia rozwoju Pusher

Pusher został uruchomiony w 2011 roku jako jedna z pierwszych hosted-usług dla WebSocket. W 2014 roku firma przedstawiła Pusher Channels — obecną architekturę z obsługą kanałów private i presence. W 2017 roku dodano obsługę webhook dla zdarzeń po stronie serwera. W 2022 roku Pusher uruchomił Pusher Beams — usługę powiadomień push dla platform mobilnych.

Architektura Pusher różni się od self-hosted rozwiązań tym, że całe przetwarzanie subskrypcji, zarządzanie połączeniami i routing zdarzeń odbywa się po stronie Pusher Cloud. Programista zarządza tylko autoryzacją kanałów private przez swój backend.

Jak działa Pusher

Architektura Pusher opiera się na modelu Publisher-Subscriber. Aplikacje serwerowe publikują zdarzenia przez REST API Pusher, a aplikacje klienckie otrzymują je przez stałe połączenie WebSocket. Pusher działa jako pośrednik między wydawcami a subskrybentami.

Gdy serwer wysyła zdarzenie przez żądanie POST do API Pusher, platforma określa docelowy kanał i rozsyła komunikat do wszystkich klientów subskrybujących ten kanał. Klienci otrzymują zdarzenie przez już otwarte połączenie WebSocket, co zapewnia opóźnienie 50–100 ms w zależności od lokalizacji geograficznej.

Każdy klient nawiązuje połączenie przez Pusher Client SDK, który automatycznie wybiera transport (WebSocket — priorytet, HTTP long-polling — fallback). SDK zarządza ponownym łączeniem, serializacją danych i obsługą błędów bez udziału programisty. Według danych dokumentacji technicznej Pusher (2025), czas ponownego połączenia po przerwaniu sieci wynosi mniej niż 1 sekundę.

Komponenty Pusher

System składa się z trzech komponentów: Pusher Server API (punkty końcowe REST do publikowania zdarzeń), Pusher Client SDK (biblioteki do subskrypcji zdarzeń) i Pusher WebHook (powiadomienia serwera o zdarzeniach połączenia/rozłączenia). Wszystkie komponenty działają asynchronicznie i niezależnie.

Typy kanałów Pusher

Pusher Channels obsługuje trzy typy kanałów, z których każdy jest przeznaczony do różnych scenariuszy użycia. Wybór typu kanału określa poziom dostępu, mechanizm autoryzacji i dostępne możliwości.

Kanały Public są dostępne dla wszystkich klientów bez autoryzacji i nadają się do danych rozgłoszeniowych. Kanały Private wymagają autoryzacji przez serwer programisty: klient wysyła żądanie do swojego backendu z socket_id i channel_name, serwer podpisuje żądanie tajnym kluczem Pusher i zwraca token auth. Kanały Presence dodatkowo przekazują informację o użytkowniku (user_id, user_info) i pozwalają śledzić, kto jest aktualnie online.

Według danych dokumentacji Pusher (2025), maksymalna liczba jednocześnie podłączonych klientów na jeden kanał wynosi 10 000 dla kanałów public i private. Dla kanałów presence limit wynosi 10 000 użytkowników na kanał z obsługą do 100 000 użytkowników na aplikację.

Zdarzenia i triggery Pusher

Model zdarzeń Pusher opiera się na nazwanych zdarzeniach, które są publikowane w kanale. Każde zdarzenie ma nazwę (maksymalnie 200 znaków), dane w formacie JSON i opcjonalny socket_id do wykluczenia ponownego wysłania do inicjatora zdarzenia.

Triggery — to żądania HTTP POST do API Pusher, które publikują zdarzenie w kanale. Format żądania: POST /apps/{app_id}/events z ciałem zawierającym channel, name i data. Pusher Server API obsługuje triggery z dowolnego środowiska serwerowego przez oficjalne biblioteki (PHP, Ruby, Python, Go, Java, Node.js).

Pusher obsługuje batch-triggery — publikację jednego zdarzenia w wielu kanałach jednym żądaniem. Jest to bardziej wydajne niż sekwencyjne wywołania i gwarantuje atomowość dostarczenia. Według danych testów wydajności Pusher (2024), batch-trigger na 100 kanałów zajmuje 30–50 ms, podczas gdy sekwencyjne wywołania — 2–5 sekund.

Integracja Webhook

Pusher WebHook pozwala twojemu serwerowi otrzymywać powiadomienia o zdarzeniach infrastruktury: podłączenie klienta, rozłączenie, wystąpienie błędu. Żądania Webhook są podpisywane HMAC-SHA256 w celu weryfikacji. Jest to kluczowe dla logowania, analityki i synchronizacji stanu.

Jak zintegrować Pusher w projekcie

Integracja Pusher składa się z dwóch części: serwerowej (publikacja zdarzeń) i klienckiej (subskrypcja zdarzeń). Rozważmy przykład na Node.js dla części serwerowej i JavaScript dla klienckiej. Na początek należy utworzyć aplikację w panelu Pusher i uzyskać dane uwierzytelniające.

Według danych dokumentacji Pusher (2025), podstawowy plan (Sandbox) obejmuje do 100 równoczesnych połączeń i 200 000 komunikatów dziennie — wystarczająco do rozwoju i testowania. Plany produkcyjne zaczynają się od $49 miesięcznie za 1000 połączeń.

Kod serwerowy: publikacja zdarzenia

const Pusher = require('pusher');

const pusher = new Pusher({
    appId: 'YOUR_APP_ID',
    key: 'YOUR_KEY',
    secret: 'YOUR_SECRET',
    cluster: 'eu',
    useTLS: true
});

pusher.trigger('my-channel', 'my-event', {
    message: 'Hello from server',
    timestamp: Date.now()
}).then(() => {
    console.log('Zdarzenie opublikowane');
}).catch(console.error);

Kod kliencki: subskrypcja zdarzeń

import Pusher from 'pusher-js';

const pusher = new Pusher('YOUR_KEY', {
    cluster: 'eu',
    forceTLS: true
});

const channel = pusher.subscribe('my-channel');

channel.bind('my-event', (data) => {
    console.log('Otrzymane zdarzenie:', data);
    displayNotification(data.message);
});

Pusher w aplikacjach mobilnych

Pusher udostępnia SDK dla iOS (Swift) i Android (Java/Kotlin), które w pełni powtarzają funkcjonalność klienta JavaScript. Mobilne SDK obsługują te same typy kanałów, mechanizm autoryzacji i model zdarzeń. Dla React Native dostępny jest pakiet pusher-js działający przez most JavaScript.

Na urządzeniach mobilnych Pusher SDK automatycznie obsługuje przełączanie między Wi-Fi a siecią komórkową, używając mechanizmu ponownego łączenia z opóźnieniem wykładniczym. Jest to szczególnie ważne dla aplikacji iOS, gdzie iOS może wymuszać zamykanie połączeń WebSocket przy pracy w tle.

Według danych bloga technicznego Pusher (2024), średnie zużycie ruchu przez jedno połączenie Pusher wynosi 1–2 KB na minutę przy braku aktywnych zdarzeń. Osiąga się to dzięki zoptymalizowanemu protokołowi heartbeat z interwałem 30 sekund. Aplikacja średniej wielkości może obsługiwać do 1000 równoczesnych połączeń Pusher bez znaczącego wpływu na zużycie baterii.

Pusher Beams do powiadomień push

Pusher Beams — dodatkowa usługa do wysyłania powiadomień push na urządzenia mobilne przez APNs (iOS) i FCM (Android). Beams integruje się z Pusher Channels: zdarzenie z kanału może automatycznie wyzwalać powiadomienie push, jeśli klient jest offline. Rozwiązuje to problem dostarczania komunikatów przy zamkniętej aplikacji.

Bezpieczeństwo i autoryzacja Pusher

Bezpieczeństwo Pusher jest zrealizowane na kilku poziomach. Każde żądanie do Pusher API jest podpisywane HMAC-SHA256 z użyciem app_secret. Gwarantuje to, że tylko autoryzowany serwer może publikować zdarzenia. Klienckie SDK używają app_key do identyfikacji aplikacji, ale do dostępu do kanałów private i presence wymagana jest dodatkowa autoryzacja.

Autoryzacja kanałów private odbywa się w trzech krokach: klient wywołuje pusher.subscribe('private-channel'), Pusher Client SDK wysyła żądanie HTTP do twojego punktu końcowego backendu (/pusher/auth), serwer sprawdza prawa użytkownika i zwraca token auth podpisany tajnym kluczem. Pusher weryfikuje podpis i zezwala na subskrypcję.

Zaleca się używanie połączeń TLS dla wszystkich żądań (ustawienie useTLS: true w SDK). Pusher obsługuje również ograniczenie dostępu według adresów IP dla żądań serwerowych do REST API. Dla taryf enterprise dostępna jest obsługa VPC (Virtual Private Cloud) i wydzielonych klastrów z izolowaną infrastrukturą.