कम आंकी गई Server-Sent Events (SSE) तकनीक
(igorstechnoclub.com)Server-Sent Events (SSE) को कम आंका जाता है
- ज़्यादातर developers WebSockets के बारे में जानते हैं, लेकिन SSE एक अधिक सरल और अक्सर नज़रअंदाज़ किया जाने वाला विकल्प है.
- SSE HTTP के ज़रिए server से client तक एक one-way communication channel स्थापित करता है.
- WebSockets के bidirectional connection के विपरीत, SSE server से client तक updates भेजने के लिए एक खुला HTTP connection बनाए रखता है.
SSE को कम क्यों आंका जाता है
- WebSocket की लोकप्रियता: WebSockets की full-duplex communication क्षमता, SSE के सरल approach को छिपा देती है.
- सीमाओं के बारे में धारणा: इसका one-way nature सीमित लग सकता है, लेकिन कई use cases के लिए यह पर्याप्त है.
SSE की प्रमुख ताकतें
-
implementation की सरलता
- यह standard HTTP protocol का उपयोग करता है, जिससे WebSocket connection management की जटिलता खत्म हो जाती है.
-
infrastructure compatibility
- यह मौजूदा HTTP infrastructure के साथ सहज रूप से काम करता है:
- load balancer
- proxy
- firewall
- standard HTTP server
- यह मौजूदा HTTP infrastructure के साथ सहज रूप से काम करता है:
-
resource efficiency
- WebSockets की तुलना में कम resource consumption:
- one-way nature
- standard HTTP connection का उपयोग
- लगातार socket maintenance की आवश्यकता नहीं
- WebSockets की तुलना में कम resource consumption:
-
automatic reconnection
- browser में built-in support:
- connection interruption को संभालना
- अपने-आप reconnect की कोशिश
- अधिक resilient real-time experience
- browser में built-in support:
-
स्पष्ट semantics
- one-way communication pattern यह सुनिश्चित करता है:
- concerns का स्पष्ट separation
- intuitive data flow
- सरल application logic
- one-way communication pattern यह सुनिश्चित करता है:
व्यावहारिक उपयोग
- real-time news feed और social updates
- stock prices और financial data
- progress bar और task monitoring
- server log streaming
- collaborative editing (updates के लिए)
- game leaderboard
- location tracking systems
implementation उदाहरण
server side (Flask)
/streamroute SSE connection को संभालता है.generate_random_data()लगातार formatted events बनाता है.text/event-streamMIME type, SSE protocol को संकेत देता है.stream_with_contextFlask application context को बनाए रखता है.
client side (JavaScript)
EventSourceobject SSE connection को manage करता है.onmessagehandler प्राप्त events को process करता है.onerrorconnection issues को संभालता है.- browser अपने-आप reconnection को संभालता है.
सीमाएँ और विचारणीय बातें
-
one-way communication
- केवल server से client तक संभव
- client से server communication के लिए अलग HTTP request की आवश्यकता
-
browser support
- आधुनिक browsers में अच्छा support
- पुराने browsers में polyfill की आवश्यकता हो सकती है
-
data format
- मुख्य रूप से text-based data का support
- binary data के लिए encoding की आवश्यकता (जैसे: Base64)
best practices
-
error handling
eventSource.onerrorसे connection errors को संभालें.
-
connection management
- काम पूरा होने पर connection को साफ़ करें.
-
reconnection strategy
- maximum retry count सेट करें और reconnection logic लागू करें.
वास्तविक उदाहरण: ChatGPT का implementation
- आधुनिक large language models (LLM) streaming responses देने के लिए SSE का उपयोग करते हैं.
- प्रमुख pattern:
content-type: text/event-streamheader return करना\r\n\r\nसे अलग किए गए data blocks की streaming
निष्कर्ष
- SSE real-time server-client communication के लिए एक elegant solution देता है.
- इसकी simplicity, efficiency, और मौजूदा infrastructure के साथ integration इसे कई applications के लिए उपयुक्त बनाते हैं.
- WebSockets अब भी bidirectional communication के लिए उपयोगी हैं, लेकिन SSE one-way data streaming scenarios के लिए अधिक केंद्रित और उपयुक्त solution प्रदान करता है.
5 टिप्पणियां
मैंने OpenAI को REST के साथ implement करते हुए वास्तव में SSE का इस्तेमाल किया।
जिन स्थितियों में one-way communication की ज़रूरत होती है, वहाँ मैं इसे ज़रूर अपनाने की सोचूँगा.
SSE अक्सर security devices (web firewall या intelligent security) में ब्लॉक नहीं होता, लेकिन कई बार newline character यूनिट पर streaming काम नहीं करती। जैसे (on-premise) बीच में पूरा response लेकर उसे एक ही बार में भेज दिया जाता है।
यह सचमुच अफसोस की बात है कि OpenAPI SSE को support नहीं करता
NAT environment में bidirectional communication बनाने का यह वाकई बहुत अच्छा तरीका है।
Hacker News राय
Mercure, SSE पर आधारित एक open protocol है, जिसका उपयोग WebSockets-आधारित solutions के विकल्प के रूप में किया जाता है। Mercure एक स्वतंत्र hub के इर्द-गिर्द काम करता है जो clients के साथ लगातार SSE connection बनाए रखता है, और server apps तथा clients के लिए एक सरल HTTP API प्रदान करता है। Mercure में JWT-आधारित authentication mechanism, कई topics के लिए single-connection subscription, event history, और network समस्या होने पर automatic state reconciliation जैसी सुविधाएँ भी जोड़ी गई हैं
SSE की एक बड़ी कमी यह है कि HTTP/2 न होने पर maximum connections की सीमा होती है। यह browser-प्रति कम सीमा होने के कारण कई tabs खोलने पर समस्या बन सकती है
Doppler के CLI में SSE का उपयोग करके auto-restart feature लागू किया गया था। SSE के जरिए server से events प्राप्त किए जाते थे, नवीनतम secrets लाए जाते थे, और उन्हें application process में inject किया जाता था। WebSockets के बजाय SSE चुनने का कारण यह था कि Golang application में अतिरिक्त dependencies न जोड़नी पड़ें। HTTP timeout समस्या हल करने के लिए बीच-बीच में "ping" events भेजने पड़े
SSE की one-way प्रकृति सीमित लग सकती है, लेकिन कई मामलों में यह पर्याप्त होती है। SSE की मुख्य सीमाएँ यह हैं कि यह text-only है और HTTP/1.1 में browser connection limits लागू होती हैं। HTTP/2 या उससे ऊपर का उपयोग करने पर connection limit समस्या नहीं रहती। यदि performance महत्वपूर्ण हो, तो fetch और ReadableStream का उपयोग करके अधिक flexible और कम-overhead solution चुना जा सकता है
SSE की सादगी के कारण कई developers उचित implementation का उपयोग करने के बजाय data chunks को regular expressions से parse करते हैं। यह समस्या बन सकता है क्योंकि SSE stream में comments को support करता है
Data-star.dev एक frontend library है जो SSE के जरिए hypermedia responses को stream करने पर केंद्रित है। इसे backend technologies के रूप में Go और NATS का उपयोग करके विकसित किया गया है, और यह सभी SSE implementations के साथ compatible है
SSE को कम आंका नहीं जाता। वास्तव में, इसका उपयोग Open AI में streaming completions के लिए हो रहा है। ReactJS codebase में SSE लागू करना मुश्किल था, और उस समय Axios इसे support नहीं करता था, इसलिए native fetch का उपयोग करना पड़ा
जब एक web project में SSE लागू किया गया, तो 6 से अधिक tabs खोलने पर website काम करना बंद कर देती थी। Firefox, SSE connections को host की 6 maximum connections limit में गिनता है, जिसके कारण अतिरिक्त requests block हो जाते हैं
SSE तब कम आंका जाता है जब यह अच्छी तरह काम करे। वर्तमान में जिस project पर काम चल रहा है, उसमें authentication issues और tunnel के keep-alive issues के कारण कठिनाइयाँ आ रही हैं। यह protocol की समस्या नहीं है, लेकिन इसका समाधान ढूँढना कठिन है