प्रॉम्प्ट और दायरा
एक सहयोगात्मक (collaborative) पेज उच्च-आवृत्ति वाले इवेंट प्राप्त करता है और सर्वर को संपादन (edits) भेजता है। मूल्यांकन करें कि क्या WebSocketStream उपयुक्त है, समझाएं कि Streams बैकप्रेशर, क्लोज़ और कैंसिलेशन संदेशों के संचय (buildup) को कैसे रोकते हैं, और असमर्थित ब्राउज़रों के लिए एक फ़ॉलबैक डिज़ाइन करें।
WebSocketStream एक प्रायोगिक (experimental), गैर-मानक Web API है। यह कनेक्शन को ReadableStream और WritableStream ऑब्जेक्ट्स के रूप में प्रस्तुत करता है, जिससे Streams बैकप्रेशर पढ़ने और लिखने को नियंत्रित कर सकता है। MDN उत्पादन (production) में उपयोग से पहले ब्राउज़र अनुकूलता की जांच करने की स्पष्ट अनुशंसा करता है। यह इंटरव्यू स्ट्रीम-प्रोटोकॉल डिज़ाइन और जोखिम मूल्यांकन के बारे में है।
इंटरव्यूअर क्या जांच रहा है
ReadableStream और WritableStream के जीवनचक्र, बैकप्रेशर कैसे असीमित कतारों (unbounded queues) को रोकता है, reader और writer लॉक, abort और close के बीच का अंतर, संदेश क्रम और इडेम्पोटेंसी (idempotency), हार्टबीट और पुनः कनेक्ट होना, Worker का उपयोग, क्षमता पहचान (capability detection), और फ़ॉलबैक को कवर करें।
30-सेकंड का उत्तर
"मैं पहले पुष्टि करता हूँ कि WebSocketStream व्यापक रूप से मानकीकृत क्षमता नहीं है और सुविधा का पता लगाने (feature detection) के बाद ही इसे सक्षम करता हूँ। मैं readable और writable को स्वतंत्र रूप से प्रबंधित करता हूँ, असीमित ऐरे को बफर करने के बजाय बैकप्रेशर को प्रसारित होने देता हूँ, और close, कैंसिलेशन और नेटवर्क त्रुटियों को अवलोकनीय (observable) स्थितियाँ बनाता हूँ। AbortSignal कंपोनेंट के जीवनकाल को एसिंक्रोनस कार्य में स्थानांतरित करता है। प्रोडक्शन समान संदेश प्रोटोकॉल, सीमित कतारों, पुनः कनेक्ट बैकऑफ़ और डुप्लिकेट दमन के साथ एक क्लासिक WebSocket एडेप्टर बनाए रखता है।"
चरण-दर-चरण समाधान
चरण 1: क्षमता और सीमा की पुष्टि करें
सक्षम करने से पहले जांचें कि क्या रनटाइम WebSocketStream को उजागर करता है। यह प्रायोगिक और गैर-मानक है, इसलिए किसी एक Chrome बिल्ड में समर्थन का अर्थ हर ब्राउज़र, WebView, या एंटरप्राइज़ वातावरण में समर्थन नहीं है। एक विफल क्षमता जांच सीधे स्थिर कार्यान्वयन का चयन करती है।
चरण 2: कनेक्शन और स्ट्रीम खोलें
WebSocketStream का निर्माण करें और readable, writable, प्रोटोकॉल और एक्सटेंशन जानकारी प्राप्त करने के लिए opened प्रॉमिस की प्रतीक्षा (await) करें। एक reader के माध्यम से readable पक्ष का उपभोग करें और एक writer के माध्यम से लिखें; closed प्रॉमिस के माध्यम से कनेक्शन बंद होने की रिपोर्ट करें।
const socket = new WebSocketStream(url);
const { readable, writable } = await socket.opened;
const reader = readable.getReader();
const writer = writable.getWriter();चरण 3: बैकप्रेशर का उपयोग करें
प्रत्येक इवेंट को सामान्य ऐरे में पुश न करें। डाउनस्ट्रीम TransformStream या WritableStream के highWaterMark को कतार को सीमित करने दें, भेजने से पहले writer.ready की प्रतीक्षा करें, और उपभोक्ता की गति से read को कॉल करें। बैकप्रेशर क्लाइंट स्ट्रीम को नियंत्रित करता है; सर्वर को अभी भी प्रोटोकॉल-स्तरीय दर सीमाओं (rate limits) की आवश्यकता होती है।
चरण 4: संदेश क्रम परिभाषित करें
संपादन (edits) को एक अनुक्रम संख्या (sequence number), दस्तावेज़ संस्करण (document version), और इडेम्पोटेंसी कुंजी (idempotency key) दें। पुनः कनेक्ट होने के बाद, यह न मानें कि पुरानी स्ट्रीम में अंतिम संदेश सहेजा गया था। नए इवेंट लागू करने से पहले सर्वर से एक अंतर (gap) या संस्करणित स्नैपशॉट का अनुरोध करें, और रेंडरिंग व ट्रांसपोर्ट दोनों परतों को डुप्लिकेट पहचानने योग्य बनाएं।
चरण 5: रद्दीकरण और क्लोज़ को संभालें
जब कोई उपयोगकर्ता दस्तावेज़ छोड़ता है या बदलता है, तो पढ़ना और लिखना बंद करें, फिर प्रासंगिक स्ट्रीम को क्लोज़ या रद्द करें। AbortSignal कंपोनेंट के जीवनकाल को एसिंक्रोनस कार्य से जोड़ता है। सामान्य क्लोज़, सक्रिय रद्दीकरण, प्रोटोकॉल त्रुटि और नेटवर्क हानि अलग-अलग स्थितियाँ होनी चाहिए ताकि पुनः कनेक्ट तर्क केवल वास्तविक नेटवर्क विफलताओं पर लागू हो।
चरण 6: मेमोरी और UI को सुरक्षित रखें
पार्सिंग, सत्यापन और रेंडरिंग को अलग करें; आवश्यकता पड़ने पर डिकोडिंग या बैच प्रोसेसिंग को Worker में स्थानांतरित करें। अधिकतम संदेश आकार, लंबित-इवेंट गणना, और बैच समय निर्धारित करें। सीमा से ऊपर, सदस्यता रोकें, पुनर्निर्माण योग्य मध्यवर्ती इवेंट्स को मर्ज करें या छोड़ें, या अनिश्चित काल तक जमा करने के बजाय एक सर्वर स्नैपशॉट का अनुरोध करें।
चरण 7: पुनः कनेक्ट और पुनर्प्राप्ति डिज़ाइन करें
जिटर के साथ घातीय बैकऑफ़ (exponential backoff with jitter) का उपयोग करें और अंतिम पुष्टि किए गए दस्तावेज़ संस्करण को शामिल करें। सर्वर द्वारा छूटे हुए इवेंट या स्नैपशॉट लौटाने के बाद, लाइव स्ट्रीम फिर से शुरू करें। क्लाइंट द्वारा उत्पन्न इडेम्पोटेंसी आईडी डिस्कनेक्ट किए गए राइट को दो बार सबमिट होने से रोकती हैं।
चरण 8: फ़ॉलबैक और अवलोकनीयता (observability) लागू करें
समान संदेश आवरण (envelope) और स्टेट मशीन के साथ क्लासिक WebSocket को डिफ़ॉल्ट फ़ॉलबैक के रूप में उपयोग करें। प्रयोग का विस्तार करने से पहले क्षमता परिणाम, opened और closed विलंबता, कतार गहराई, बैकप्रेशर प्रतीक्षा, पुनः कनेक्ट गणना, छोड़े गए इवेंट, और स्नैपशॉट पुनर्प्राप्ति दर को रिकॉर्ड करें। उन्हें ब्राउज़र, नेटवर्क प्रकार और पेज संस्करण द्वारा विभाजित करें।
ट्रेड-ऑफ़ और सीमाएं
WebSocketStream या WebSocket
WebSocketStream स्ट्रीम बैकप्रेशर और Promise-आधारित जीवनचक्र संकेत प्रदान करता है, लेकिन समर्थन और मानकीकरण सीमित हैं। क्लासिक WebSocket व्यापक रूप से उपलब्ध है फिर भी एप्लिकेशन को onmessage कार्य और भेजने की कतार को सीमित करने की आवश्यकता होती है। एक प्रोटोकॉल अमूर्तन (abstraction) दोनों ट्रांसपोर्ट का समर्थन कर सकता है।
इवेंट छोड़ें या स्नैपशॉट का अनुरोध करें
कर्सर मूवमेंट जैसे पुनर्निर्माण योग्य इवेंट्स को कतार भरने पर मर्ज किया जा सकता है या छोड़ा जा सकता है। दस्तावेज़ संपादनों को चुपचाप नहीं छोड़ा जा सकता; उपभोग रोकें और एक संस्करणित स्नैपशॉट का अनुरोध करें। विकल्प क्रमविनिमेयता (commutativity), क्रम और सर्वर रीप्ले समर्थन पर निर्भर करता है।
मुख्य थ्रेड या Worker
छोटे संदेश और कम दर वाली रेंडरिंग मुख्य थ्रेड के अनुकूल हैं। उच्च-दर बाइनरी डिकोडिंग, संपीड़न और बैच विलय को Worker में स्थानांतरित किया जा सकता है। एक Worker कुल मेमोरी सीमा को नहीं हटाता है, इसलिए ट्रांसपोर्ट कतारों और रद्दीकरण को अभी भी स्पष्ट सीमाओं की आवश्यकता होती है।
विफलता अभ्यास और विकास
ब्राउज़र API का समर्थन नहीं करता है
क्षमता शाखा को बंद करें और सत्यापित करें कि क्लासिक WebSocket कनेक्ट होता है, समान संदेशों का उपभोग करता है, और अनुकूलता मेट्रिक्स की रिपोर्ट करता है।
उपभोक्ता धीमा हो जाता है
रेंडरिंग को कृत्रिम रूप से धीमा करें और सत्यापित करें कि बैकप्रेशर प्रतीक्षा बढ़ती है, कतार सीमित रहती है, और क्रैश होने के बजाय सीमा पर एक स्नैपशॉट पुनर्प्राप्ति पथ ट्रिगर होता है।
लिखते समय कनेक्शन कट जाता है
संपादन भेजने के तुरंत बाद डिस्कनेक्ट करें। सत्यापित करें कि इडेम्पोटेंसी आईडी, अंतिम पुष्टि किया गया संस्करण, और पुनः कनेक्ट बैकऑफ़ संपादन को दो बार लागू किए बिना स्थिति को पुनर्स्थापित करते हैं।
सामान्य गलतियाँ और फ़ॉलो-अप
गलती 1: यह मानना कि Streams सर्वर थ्रॉटलिंग को हल करते हैं
फ़ॉलो-अप: बैकप्रेशर क्या नियंत्रित करता है? यह क्लाइंट स्ट्रीम के अंदर उत्पादन और उपभोग को नियंत्रित करता है; यह सर्वर कोटा, कनेक्शन सीमा, या व्यावसायिक बैचिंग की जगह नहीं लेता है।
गलती 2: close, cancel और abort को समान मानना
फ़ॉलो-अप: कंपोनेंट अनमाउंट पर क्या होता है? सामान्य क्लोज़, पढ़ने के रद्दीकरण, और एसिंक्रोनस एबॉर्ट को अलग-अलग रिकॉर्ड करें ताकि पुनः कनेक्ट तर्क वास्तविक नेटवर्क दोषों को लक्षित करे।
गलती 3: केवल WebSocketStream भेजना
फ़ॉलो-अप: WebView या पुराने ब्राउज़र के बारे में क्या? एक विफल क्षमता जांच क्लासिक WebSocket एडेप्टर का चयन करती है, जबकि संदेश प्रोटोकॉल और स्टेट मशीन समान रहते हैं।
गहन फ़ॉलो-अप और मॉडल उत्तर
writer.ready का await क्यों करें?
यह प्रेषक को असीमित प्रॉमिस या ऐरे बनाने के बजाय बैकप्रेशर के तहत WritableStream क्षमता की प्रतीक्षा करने देता है। सर्वर दर सीमाएं और संदेश-आकार सीमाएं अभी भी आवश्यक हैं।
क्लाइंट को स्नैपशॉट का अनुरोध कब करना चाहिए?
जब इवेंट कतार अपनी सीमा से अधिक हो जाती है, एक अनुक्रम अंतराल दिखाई देता है, या क्लाइंट एक सतत संस्करण की पुष्टि नहीं कर सकता है, तो इवेंट क्रम का अनुमान लगाने की तुलना में एक संस्करणित स्नैपशॉट अधिक सुरक्षित होता है।
आप एक प्रायोगिक API को कैसे रोल आउट करते हैं?
क्षमता, ब्राउज़र संस्करण और पेज संस्करण द्वारा समूहीकृत करें, फिर एक छोटे प्रतिशत को सक्षम करें। कतार गहराई, डिस्कनेक्ट पुनर्प्राप्ति, त्रुटि दर, और रेंडर विलंबता की तुलना करें; जब मेट्रिक्स खराब हों तो ध्वज (flag) को अक्षम करें और क्लासिक WebSocket पर वापस लौटें।