लॉन्ग पोलिंग पैटर्न और पुनःकनेक्शन तर्क

दीर्घ-अवधि अनुरोध एक चक्र में काम करता है: क्लाइंट HTTP अनुरोध भेजता है, सर्वर नई जानकारी उपलब्ध होने तक कनेक्शन खुला रखता है (या समय-समाप्ति हो जाती है, आमतौर पर 30–60 सेकंड), सर्वर जानकारी के साथ उत्तर देता है और क्लाइंट तुरंत एक और अनुरोध भेजता है। इससे सर्वर द्वारा डेटा भेजने जैसी विशेषताओं वाला लगभग निरंतर कनेक्शन बनता है।

React में दीर्घ-अवधि अनुरोध के लिए useEffect के भीतर async पुनरावर्ती फ़ंक्शन का उपयोग होता है। फ़ंक्शन fetch अनुरोध करता है, प्रतिक्रिया संसाधित करता है और फिर स्वयं को दोबारा कॉल करता है। AbortController signal घटक के अनमाउंट होने पर पुनरावृत्ति रोकता है। जब तक घटक माउंटेड है और abort का संकेत नहीं दिया गया है, फ़ंक्शन चलता रहता है।

useEffect के शीर्ष पर एक AbortController बनाएँ और प्रत्येक fetch कॉल में controller.signal भेजें। सफ़ाई फ़ंक्शन में controller.abort() कॉल करें। घटक के अनमाउंट होने पर यह किसी भी चल रहे अनुरोध को रद्द कर देता है, जिससे अनमाउंट किए गए घटकों की स्थिति अपडेट होने और नेटवर्क संसाधनों के रिसाव की समस्या रुकती है।

दीर्घ-अवधि अनुरोध विफल होने पर तुरंत पुनःप्रयास न करें — अगले प्रयास से पहले प्रतीक्षा करें। घातीय विलंब-वृद्धि प्रत्येक लगातार विफलता पर विलंब को दोगुना करती है: 1 सेकंड, 2 सेकंड, 4 सेकंड, 8 सेकंड, 16 सेकंड; अधिकतम 30 सेकंड तक। इससे विफल सर्वर पर बार-बार अनुरोध भेजने से बचाव होता है और अस्थायी समस्याओं को ठीक होने का समय मिलता है। सफल प्रतिक्रिया मिलने पर विलंब को 1 सेकंड पर फिर से सेट करें।

जब बहुत से क्लाइंट एक ही सर्वर को बार-बार अनुरोध भेजते हैं, तो यादृच्छिकता के बिना घातीय विलंब-वृद्धि से "एकसाथ उमड़ता झुंड" पैदा होता है: सभी क्लाइंट समान समय तक रुककर एक साथ पुनःप्रयास करते हैं और सर्वर पर फिर से अत्यधिक भार डालते हैं। विलंब को यादृच्छिक बनाकर यादृच्छिकता जोड़ें: delay + Math.random() * delay। इससे पुनःप्रयास एक समय-अवधि में फैल जाते हैं और सर्वर पर भार के अचानक बढ़ने में कमी आती है।

अनुरोध भेजने के जीवनचक्र को दिखाने के लिए कनेक्शन स्थिति की अवस्था बनाए रखें: isConnecting (प्रारंभिक कनेक्शन या त्रुटि के बाद पुनःकनेक्शन), isConnected (अंतिम अनुरोध सफल रहा), isError (लगातार विफलताएँ और अधिकतम पुनःप्रयास संख्या पूरी हो गई)। यह स्थिति UI में दिखाएँ, ताकि उपयोगकर्ता वास्तविक-समय डेटा की विश्वसनीयता समझ सकें।

अगले पुनःप्रयास से पहले विलंब के दौरान आप उलटी गिनती दिखा सकते हैं: "8 सेकंड में पुनःकनेक्शन..." और उसके साथ प्रगति सूचक भी दिखा सकते हैं। विलंब टाइमर सेट करते समय पुनःप्रयास का टाइमस्टैम्प निकालें और हर सेकंड प्रदर्शन को अपडेट करें। यह पारदर्शिता उपयोगकर्ताओं को भरोसा दिलाती है कि ऐप सक्रिय रूप से समस्या ठीक करने का प्रयास कर रहा है।

पोलिंग के लिए setTimeout का पुनरावर्ती उपयोग करें (प्रतिक्रिया हैंडलर के भीतर अगला अनुरोध करें), setInterval का नहीं। पिछला अनुरोध पूरा होने में कितना समय लगा, इसकी परवाह किए बिना setInterval निश्चित अंतराल पर चलता है — लंबे समय तक चलने वाले अनुरोधों से एक-दूसरे पर चढ़े हुए अनुरोध बन सकते हैं। पुनरावर्ती setTimeout पिछला अनुरोध पूरा होने के बाद ही अगला अनुरोध शुरू करता है।

अपने हुक में अनुरोध अंतराल को विन्यास विकल्प के रूप में उपलब्ध कराएँ: useLongPoll({ url, interval: 5000 })। अलग-अलग डेटा स्रोतों को अलग-अलग ताज़गी अंतराल चाहिए: "कौन जुड़ा है" सूचक हर 30 सेकंड में अनुरोध भेज सकता है, जबकि कार्य की स्थिति हर 5 सेकंड में भेज सकती है। कार्यान्वयन कोड में अंतराल को स्थिर रूप से लिखने से बचें।

जैसे-जैसे आपका API विकसित होता है, बेहतर दक्षता के लिए आप बार-बार अनुरोध भेजने की प्रणाली को SSE से बदल सकते हैं। बार-बार अनुरोध भेजने वाले हुक का उपयोग करने वाला React घटक परिवहन परत से अलग होना चाहिए। यदि आपका हुक वही इंटरफ़ेस (onData, स्थिति, त्रुटि) उपलब्ध कराता है, तो भीतर से बार-बार अनुरोध भेजने की प्रणाली को EventSource से बदलने पर हुक का उपयोग करने वाले घटक में कोई बदलाव आवश्यक नहीं होगा।

जब सर्वर दीर्घ-अवधि अनुरोध का कनेक्शन खुला रखता है और कोई डेटा नहीं आता, तो उसे समय-समाप्ति के साथ उत्तर देना चाहिए (खाली निकाय के साथ 200 या 204 बिना सामग्री के), ताकि कनेक्शन अनिश्चित समय तक अटका न रहे। इसके बाद क्लाइंट तुरंत फिर से अनुरोध भेजता है। यह सर्वर-पक्षीय समय-समाप्ति (30–60 सेकंड) क्लाइंट-पक्षीय fetch समय-समाप्ति से अलग होती है (जो अधिक लंबी होती है, जैसे 90 सेकंड)।

दीर्घ-अवधि अनुरोध में क्लाइंट अनुरोध भेजता है, सर्वर डेटा उपलब्ध होने या समय-समाप्ति होने तक प्रतीक्षा करता है और प्रतिक्रिया के तुरंत बाद क्लाइंट फिर से अनुरोध भेजता है। इसे useEffect में पुनरावर्ती async fetch और सफ़ाई के लिए AbortController के साथ लागू करें। त्रुटि होने पर: एकसाथ उमड़ते झुंड को रोकने के लिए घातीय विलंब-वृद्धि (1 सेकंड, 2 सेकंड, 4 सेकंड... अधिकतम 30 सेकंड) के साथ यादृच्छिकता जोड़ें। अनुरोधों के एक-दूसरे पर चढ़ने से बचने के लिए setInterval के बजाय पुनरावर्ती setTimeout का उपयोग करें। UI प्रतिक्रिया के लिए isConnecting/isConnected/isError स्थिति ट्रैक करें।