हो सकता है कि आपको WebSocket की ज़रूरत न हो

• WebSocket real-time communication के लिए उपयोगी है, लेकिन इसकी हमेशा ज़रूरत नहीं होती, और HTTP-आधारित विकल्प अधिक सरल और स्थिर हो सकते हैं
• transaction processing, connection management और server complexity जैसे पहलुओं में WebSocket अनावश्यक overhead पैदा कर सकता है
• HTTP Streaming और library (eventkit) का उपयोग करके WebSocket के बिना भी real-time synchronization और event handling संभव है

WebSocket क्या है

• WebSocket एक ऐसी तकनीक है जो client और server के बीच लगातार चलने वाला bidirectional communication channel खोलती है
• connection की शुरुआत HTTP से होती है, लेकिन उसके बाद communication एक अलग protocol पर होता है
• इसका उपयोग अक्सर real-time applications में किया जाता है, और bidirectional communication इसकी बड़ी उपयोगिता है

WebSocket messages transaction-आधारित नहीं होते

• WebSocket request और response के बीच सीधे संबंध की गारंटी नहीं देता
• state change commands और उनके result messages एक ही stream में मिलकर आ सकते हैं
• उदाहरण के लिए, अगर एक client state बदलता है और error आती है, तो यह समझना मुश्किल हो सकता है कि error किस command के लिए थी
• इसका समाधान requestId शामिल करके command और response को जोड़ना है, लेकिन इससे complexity और management cost बढ़ती है
• command भेजने के लिए HTTP का transaction model और state change broadcast के लिए केवल WebSocket का उपयोग करना अधिक सरल तरीका है
• sending side को HTTP requests से और receiving side को WebSocket या किसी अन्य streaming method से अलग किया जा सकता है

WebSocket connection lifecycle को संभालने की कठिनाई

• WebSocket का उपयोग करने पर connection की शुरुआत, समाप्ति, error और reconnection जैसी चीज़ों को सीधे संभालना पड़ता है
• browser में basic handling के उदाहरण में connection open, message receive, error और connection close events को handle करना शामिल है
• reconnection logic, message buffering और exponential backoff जैसी अतिरिक्त logic की भी ज़रूरत पड़ती है
• इसके विपरीत, HTTP में request स्तर पर शुरुआत और अंत स्पष्ट होते हैं, इसलिए implementation सरल होता है
• यह जटिल lifecycle management तभी उचित है जब WebSocket उपयोग करने का कारण वास्तव में स्पष्ट हो

server code complexity में वृद्धि

• WebSocket में HTTP upgrade requests को संभालना पड़ता है, जिसके लिए अतिरिक्त handshake logic चाहिए
• Sec-WebSocket-Key जैसे special headers को validate करना और response headers सही तरह से लौटाना आवश्यक होता है
• WebSocket connection के बाद लगातार message receive और send state बनाए रखनी पड़ती है, और partial frame handling जैसी समस्याएँ भी आ सकती हैं
• केवल HTTP उपयोग करने की तुलना में debugging और error handling अधिक कठिन हो जाती है
• framework कुछ प्रक्रियाओं को abstract कर सकता है, लेकिन मूल complexity फिर भी बनी रहती है

विकल्प: HTTP Streaming

• HTTP मूल रूप से streaming support करने वाला protocol है, इसलिए पूरे file के बजाय data stream को real time में भेजा जा सकता है
• मौजूदा WebSocket के receiving side function को HTTP streaming से बदला जा सकता है
• async generator का उपयोग करके state updates को stream के रूप में संभाला जा सकता है
• server-side flow
  • state updates command handling function में किए जाते हैं
  • connected clients generator के माध्यम से हर नया value आने पर उसे प्राप्त करते हैं
  • state change commands HTTP POST से भेजे जाते हैं, और real-time stream को GET request से subscribe किया जाता है
• client-side flow
  • Fetch API और Stream Reader के माध्यम से real-time data receive करना
  • text decode करने के बाद UI update करना
• इस संरचना से WebSocket के बिना भी real-time state synchronization लागू किया जा सकता है

बोनस: eventkit library का परिचय

• eventkit एक library है जो async streams को आसानी से compose और observe करने में मदद करती है
• यह RxJS के समान है, लेकिन side effect management बेहतर है और इसे generator-आधारित तरीके से डिज़ाइन किया गया है
• state updates को stream में push करने पर client उन्हें real time में receive कर सकता है
• Stream और AsyncObservable के माध्यम से server/client दोनों तरफ इसे सरलता से लागू किया जा सकता है
• server-side में eventkit का उपयोग
  • state changes को Stream में push किया जाता है, और client उस stream को subscribe करते हैं
• client-side में eventkit का उपयोग
  • stream data प्राप्त करके decode करने के बाद UI update करना
• आधिकारिक GitHub repository और HTTP Streaming guide भी उपलब्ध हैं

GitHub: https://github.com/hntrl/eventkit

[GN⁺]

Hacker News राय

• मुझे नहीं लगता कि HTTP streaming को इस पैटर्न को ध्यान में रखकर डिज़ाइन किया गया था। HTTP streaming का उपयोग बड़े डेटा को टुकड़ों में बाँटने के लिए होता है। अगर streaming को pub/sub mechanism की तरह इस्तेमाल करेंगे, तो बाद में पछताना पड़ सकता है। HTTP intermediaries इस तरह के traffic pattern की अपेक्षा नहीं करते (NGINX, CloudFlare आदि)। हर बार WiFi कनेक्शन टूटने पर fetch API शायद request failure की error देगा

  • कई मामलों में WebSockets की ज़रूरत नहीं होती। Server-Sent Events (SSE) एक अधिक सरल समाधान है। अफ़सोस है कि SSE को उतना ध्यान नहीं मिला

• RequestID को server को भेजकर request/response cycle पाना न अजीब है, न ही ज़्यादा। गंभीर apps में send(message).then(res => ...) जैसी API होना हमेशा उपयोगी होता है

  • upgrade request उलझाऊ होती है। यह परेशान करने वाला है कि WebSocket server, HTTP server के अंदर embed होकर integrate नहीं होता
  • WebSocket request में headers['authorization'] पढ़ने वाले middleware को reuse करने के बजाय, connectionParams object को access करना पड़ता है जो request header होने का दिखावा करता है
  • WebSocket browser API, EventSource की तुलना में संभालने में बेहतर है

• video streaming में client range के साथ chunks request करता है, यह single HTTP connection नहीं होता

• EventKit की जगह SSE का उपयोग करना बेहतर है

• POC में पारंपरिक HTTP form submission का उपयोग करने वाला हूँ। किसी और चीज़ की ज़रूरत नहीं है

  • architect ज़ोर देता है कि WebSockets चाहिए
  • POC में XHR या WebSockets की ज़रूरत नहीं है। यह एक sequential purchase flow है
  • अंत में अनावश्यक WebSockets देने पड़ते हैं

• HTTP2 की समस्या यह है कि server push को मौजूदा protocol के ऊपर जोड़ा गया था। HTTP एक resource transfer protocol है, जो अनावश्यक overhead जोड़ता है। HTTP2 का मुख्य उद्देश्य यह है कि server फ़ाइलें/resources को client तक पहले से push करे ताकि round-trip latency कम हो

  • WebSockets bidirectional communication के लिए डिज़ाइन किया गया एक अधिक सरल protocol है। एक single connection के साथ data flow को नियंत्रित करना आसान है। state management और connection loss recovery आसान हो जाती है। authentication और access control सरल हो जाते हैं

• WebSockets stream के रूप में नहीं, बल्कि datagrams (packets) के रूप में भेजते हैं। JavaScript library की WebSockets API backpressure को संभाल नहीं सकती, और सभी errors को भी handle नहीं कर सकती। इसे TCP stream की तरह इस्तेमाल करते समय सावधानी ज़रूरी है

• WebSockets को production में deploy करने के बाद पछतावा हुआ। NGINX 4/8 घंटे बाद connection बंद कर देता था, browser sleep के बाद reconnect नहीं करता था, जैसी समस्याएँ थीं। संभव हो तो WebSockets और long-lived connections से बचना चाहिए

• WebSockets को लेकर एक आदर्शवादी धारणा है। streaming/real-time use cases में WebSockets का उपयोग करने की प्रवृत्ति होती है। WebSockets के साथ HTTP tools की सादगी और फ़ायदे खो जाते हैं। streaming server changes का समाधान h2/h3 और SSE हैं। अगर प्रति client अधिकतम 0.5req/s तक batch किया जा सकता है, तो WebSockets की ज़रूरत नहीं है

• जिन्हें HTTP streaming में रुचि है, उन्हें Braid-HTTP देखना चाहिए। यह HTTP में event streaming को सुंदर तरीके से extend करके एक शक्तिशाली state synchronization protocol प्रदान करता है