Realtime komunikácia

Keď aplikácia nemá čakať na ďalší refresh

Navrhujem komunikáciu udalostí tam, kde má používateľ alebo systém dostať informáciu hneď po jej vzniku.

Polling nie je vždy odpoveď

Aktuálny stav bez pravidelných otázok na server

Pri pollingu prehliadač opakovane zisťuje, či sa niečo zmenilo. Realtime model doručí udalosť až vtedy, keď naozaj vznikne.

Poznáte to?

Používateľ stále obnovuje stránku a čaká.

Jednoduchá zmena trvá dlhšie, než by mala.

Nie je jasné, kde začať bez veľkého rizika.

Nie každá aplikácia musí byť realtime. Ak však proces čaká na udalosť, polling nemusí byť správna odpoveď.

Čo sa s tým dá robiť

Prvý krok môže byť malý a konkrétny

Najskôr chcem pochopiť, čo vás dnes brzdí. Potom môžeme zmerať, oddeliť alebo overiť najrizikovejšiu časť bez toho, aby sa naraz menilo všetko.

Dnes

Zmena je neistota

Riziko pri zásahu
Previazané časti
Čakanie alebo manuálna práca

Po postupnej zmene

Lepší priestor na rozvoj

Jasnejšie hranice
Bezpečnejší ďalší krok
Viditeľnejší stav procesu

Čo môže realtime riešiť

Výber závisí od typu udalosti, oprávnení a požadovanej spoľahlivosti.

WebSocket komunikácia

Obojsmerné spojenie medzi browserom a realtime vrstvou.

Publish / subscribe

Udalosti sa doručujú len relevantným topicom a odberateľom.

Monitoring a spracovanie

Pre dashboardy, notifikácie, CRM, rezervácie a background procesy.

Typické scenáre

Živé dashboardy a monitoring
Stav objednávok, rezervácií alebo CRM
Notifikácie používateľov v browseri
AI a worker procesy, ktoré publikujú výsledok

Technický pohľad

Vlastný WebSocket broker môže byť jednou z realizácií. Dôležité sú topic routing, namespaces, autorizácia a pozorovateľnosť.

PHP backend
     ↓ REST publish
Realtime broker
   ├── Browser
   ├── Worker
   └── AI service

Spôsob spolupráce

Udalosť, tok a kontrola prístupu

Udalosti Čo sa má doručiť a komu.
Kanály Topicy, namespaces a pravidlá prístupu.
Prevádzka Monitoring, chybové stavy a overenie správania.

Rozhodnutie podľa použitia

WebSocket nie je potrebný pre všetko

Polling je pravidelná otázka klienta na nový stav a pri zriedkavých zmenách môže byť najjednoduchší a úplne postačujúci. Persistentné WebSocket spojenie má prínos pri nízkej latencii alebo veľkom počte klientov, no vyžaduje reconnect, heartbeat (pravidelný signál, že spojenie žije), autorizáciu a monitoring. Backpressure je ochrana pred situáciou, keď príjemca nestíha správy spracovať; bez nej môže realtime vrstva zhoršiť problém, ktorý mala riešiť.

Relevantné technológie

Go WebSocket REST Wildcard topics Namespaces Authorization Monitoring Docker

Modelový príklad

Okamžité doručovanie udalostí bez pravidelného pollingu

Backend publikuje zmenu; browser alebo worker dostane iba relevantnú udalosť.

Backend
  ↓ publish
Broker
  ↓ event
Browser

Má aplikácia reagovať okamžite?

Popíšte udalosť, používateľov a očakávané správanie.

Prebrať realtime riešenie →

Pozrime sa, kde dnes váš systém zbytočne čaká.

Nemusíte mať hotové zadanie ani presne vedieť, akú technológiu potrebujete. Stačí problém, ktorý dnes stojí čas, peniaze alebo zbytočnú manuálnu prácu.

Prejsť problém spolu →

Menu