Naše softwarové oddělení se věnuje především vývoji backendu, různým integracím a backoffice aplikacím. Proto jsme dlouhou dobu neměli potřebu využít již poměrně starou technologií WebSocket. Tato příležitost se nám naskytla při přípravě „dashboardu“.
Základní vlastností jakéhokoliv dashboardu je, aby obsahoval co nejčerstvější data a okamžitě reflektoval změny, ke kterým dochází na serveru. Nelze tedy čekat na akci uživatele, ale je nutné, aby aplikace data občerstvovala sama.
Prvním možným řešením je tzv. polling – aplikace si v pravidelných intervalech obnovuje data ze serveru. Nevýhody jsou nasnadě:
- Data jsou jen tak čerstvá, jak vysoká je frekvence obnovování ze serveru.
- Čím častější obnovování, tím větší je zátěž na server bez ohledu na to, zda došlo k nějakým změnám dat či nikoliv.
Možnou alternativou je tzv. long-polling, který ale přináší další technické problémy v podobě timeoutů, množství otevřených spojení či latence.
Jako další možnost se tedy nabízí využití WebSocket. Tento protokol umožňuje obousměrnou komunikaci, a tedy i pushování dat ze strany serveru ke klientovi. A to je vlastnost, která nás zajímala.
Samotná implementace na straně klienta je snadná – k dispozici je jednoduchá JS API. Na první nevýhody lze ale narazit již při konfiguraci infrastruktury (v našem případě HAP), neboť komunikace probíhá tak, že úvodní handshake proběhne přes HTTP/1.1 a následně dojde k upgradu na websocket. K dispozici je i zabezpečná varianta wss, ale již právě zmíněný upgrade otevírá prostor pro potenciální útoky. Navíc nelze využít výhody protokolu HTTP/2.
Na další problém lze narazit hned při implementaci na straně serveru. Nelze zde totiž využít cookie a session s identifikací uživatele, ale veškerou autentizaci je nutné řešit samostatně. Tato vlastnost nakonec rozhodla, jak jsme WebSocket využili. Místo vlastních dat zasíláme pouze zprávy a na základě těchto zpráv si teprve aplikace stáhne aktuální data. Výhody jsou následující:
- Nemusíme řešit autentizaci ani autorizaci – klienti dostanou pouze zprávu o změně a data si stáhnou již standardním způsobem. Neautorizovaný klient získá maximálně zprávy o změně a problém může nastat jen tehdy, pokud by takových klientů bylo opravdu hodně.
- Serverovou část jsme mohli vydělit do zcela nezávislé samostatné služby (využili jsme jednoduchou službu gwsocket.io) a nemuseli prakticky měnit vlastní aplikaci.
- Implementace na straně klienta byla téměř totožná jako pro polling.
Nevýhodou je dotaz na server navíc.
Poslední problém se ukázal při testování. V určitých situacích se ukázalo spojení jako nestabilní a bylo nutné naimplementovat fallback řešení – polling. Díky tomu, že klientská část stahuje data ze serveru samostatně na základě WebSocket zpráv, implementace záložního pollingu byla velmi jednoduchá.
Na závěr otázka. Existuje pro naše použití něco vhodnějšího? Ano, jsou to tzv. Server-Sent Events (SSE). Na rozdíl od WebSocket neumožňuje tato technologie obousměrnou komunikaci, ale pouze pushování dat ze serveru ke klientovi. Pro potřeby aplikace typu dashboard je to ale plně dostačující a výhody spojené s tím, že to celé běží nad HTTP protokolem mohou převážit ve prospěch této technologie.