फ़ेच एपीआई का इस्तेमाल करते समय गड़बड़ी ठीक करने के तरीके को लागू करें

इस लेख में, Fetch API का इस्तेमाल करते समय, गड़बड़ी को मैनेज करने के कुछ तरीके बताए गए हैं. Fetch API की मदद से, किसी रिमोट नेटवर्क संसाधन का अनुरोध किया जा सकता है. रिमोट नेटवर्क कॉल करने पर, आपके वेब पेज पर नेटवर्क से जुड़ी कई गड़बड़ियां हो सकती हैं.

यहां दिए गए सेक्शन में, संभावित गड़बड़ियों के बारे में बताया गया है. साथ ही, कोड लिखने का तरीका भी बताया गया है, ताकि गड़बड़ियों और नेटवर्क की अप्रत्याशित स्थितियों से बचने के लिए, बेहतर तरीके से काम किया जा सके. रिज़िलिएंट कोड की मदद से, आपके उपयोगकर्ता खुश रहते हैं और आपकी वेबसाइट पर स्टैंडर्ड लेवल की सेवा मिलती रहती है.

नेटवर्क से जुड़ी संभावित गड़बड़ियों का अनुमान लगाना

इस सेक्शन में एक ऐसी स्थिति के बारे में बताया गया है जिसमें उपयोगकर्ता ने "My Travels.mp4" नाम का एक नया वीडियो बनाया है. इसके बाद, वह वीडियो शेयर करने वाली वेबसाइट पर वीडियो अपलोड करने की कोशिश करता है.

फ़ेच के साथ काम करते समय, हैप्पी पाथ को आसानी से ध्यान में रखा जा सकता है. इस पाथ में, उपयोगकर्ता वीडियो को अपलोड कर लेता है. हालांकि, कुछ अन्य पाथ भी हैं जो उतने आसान नहीं हैं. हालांकि, वेब डेवलपर को इनके लिए प्लान बनाना चाहिए. ऐसे (अनचाहे) पाथ, उपयोगकर्ता की गलती की वजह से, अचानक बदली हुई परिस्थितियों की वजह से या वीडियो शेयर करने वाली वेबसाइट में बग की वजह से हो सकते हैं.

उपयोगकर्ता की ओर से होने वाली गड़बड़ियों के उदाहरण

  • उपयोगकर्ता, वीडियो फ़ाइल के बजाय इमेज फ़ाइल (जैसे, JPEG) अपलोड करता है.
  • उपयोगकर्ता गलत वीडियो फ़ाइल अपलोड करना शुरू कर देता है. इसके बाद, अपलोड के दौरान उपयोगकर्ता, अपलोड करने के लिए सही वीडियो फ़ाइल चुनता है.
  • वीडियो अपलोड होने के दौरान, उपयोगकर्ता गलती से "अपलोड रद्द करें" पर क्लिक कर देता है.

पर्यावरण में होने वाले बदलावों के उदाहरण

  • वीडियो अपलोड करते समय इंटरनेट कनेक्शन बंद हो जाता है.
  • वीडियो अपलोड होने के दौरान ब्राउज़र रीस्टार्ट हो जाता है.
  • वीडियो अपलोड होने के दौरान, वीडियो शेयर करने वाली वेबसाइट के सर्वर रीस्टार्ट हो जाते हैं.

वीडियो शेयर करने वाली वेबसाइट से जुड़ी गड़बड़ियों के उदाहरण

  • वीडियो शेयर करने वाली वेबसाइट, स्पेस वाली फ़ाइल का नाम नहीं दिखा सकती. "My Travels.mp4" के बजाय, "My_Travels.mp4" या "MyTravels.mp4" जैसा कोई नाम डालें.
  • वीडियो शेयर करने वाली वेबसाइट, फ़ाइल के लिए तय किए गए साइज़ से ज़्यादा साइज़ का वीडियो अपलोड नहीं कर सकती.
  • वीडियो शेयर करने वाली वेबसाइट, अपलोड किए गए वीडियो में मौजूद वीडियो कोडेक के साथ काम नहीं करती.

ये उदाहरण, असल दुनिया में हो सकते हैं और हो भी रहे हैं. हो सकता है कि आपको पहले भी इस तरह के उदाहरण मिले हों! आइए, पिछली सभी कैटगरी में से एक उदाहरण चुनें और इन बातों पर चर्चा करें:

  • अगर वीडियो शेयर करने वाली सेवा, दिए गए उदाहरण को हैंडल नहीं कर सकती, तो डिफ़ॉल्ट रूप से क्या होगा?
  • उदाहरण में, उपयोगकर्ता को क्या दिखना चाहिए?
  • हम इस प्रोसेस को कैसे बेहतर बना सकते हैं?
कार्रवाई उपयोगकर्ता गलत वीडियो फ़ाइल अपलोड करना शुरू कर देता है. इसके बाद, अपलोड के दौरान उपयोगकर्ता, अपलोड करने के लिए सही वीडियो फ़ाइल चुनता है.
डिफ़ॉल्ट रूप से क्या होता है नई फ़ाइल अपलोड होने के दौरान, ओरिजनल फ़ाइल बैकग्राउंड में अपलोड होती रहती है.
उपयोगकर्ता क्या चाहता है उपयोगकर्ता चाहता है कि ओरिजनल अपलोड रुक जाए, ताकि इंटरनेट बैंडविड्थ बर्बाद न हो.
क्या बेहतर किया जा सकता है नई फ़ाइल अपलोड होने से पहले, JavaScript ओरिजनल फ़ाइल के लिए फ़ेच करने का अनुरोध रद्द कर देता है.
कार्रवाई वीडियो अपलोड करने के दौरान, उपयोगकर्ता का इंटरनेट कनेक्शन बंद हो जाता है.
डिफ़ॉल्ट रूप से क्या होता है अपलोड की प्रोग्रेस बार 50% पर रुक गई है. आखिर में, Fetch API को टाइम आउट का सामना करना पड़ता है और अपलोड किया गया डेटा खारिज कर दिया जाता है. इंटरनेट कनेक्शन वापस आने पर, उपयोगकर्ता को अपनी फ़ाइल फिर से अपलोड करनी होगी.
उपयोगकर्ता क्या चाहता है उपयोगकर्ता को यह उम्मीद होती है कि अगर उसकी फ़ाइल अपलोड नहीं हो पा रही है, तो उसे इसकी सूचना दी जाएगी. साथ ही, वह यह भी चाहता है कि जब वह फिर से ऑनलाइन हो जाए, तो अपलोड की प्रोसेस अपने-आप 50% तक फिर से शुरू हो जाए.
क्या बेहतर किया जा सकता है अपलोड पेज पर, उपयोगकर्ता को इंटरनेट कनेक्शन से जुड़ी समस्याओं के बारे में बताया जाता है. साथ ही, उसे यह भी बताया जाता है कि इंटरनेट कनेक्शन वापस आने पर, अपलोड की प्रोसेस फिर से शुरू हो जाएगी.
कार्रवाई वीडियो शेयर करने वाली वेबसाइट, स्पेस वाली फ़ाइल का नाम नहीं दिखा सकती. "My Travels.mp4" के बजाय, "My_Travels.mp4" या "MyTravels.mp4" जैसे नाम इस्तेमाल करें.
डिफ़ॉल्ट रूप से क्या होता है उपयोगकर्ता को अपलोड पूरा होने का इंतज़ार करना होगा. फ़ाइल अपलोड होने के बाद, प्रोग्रेस बार में "100%" दिखने पर, प्रोग्रेस बार में यह मैसेज दिखता है: "कृपया फिर से कोशिश करें."
उपयोगकर्ता क्या चाहता है उपयोगकर्ता को अपलोड शुरू होने से पहले या कम से कम अपलोड के पहले सेकंड में, फ़ाइल नाम से जुड़ी सीमाओं के बारे में बताया जाना चाहिए.
क्या बेहतर किया जा सकता है आम तौर पर, वीडियो शेयर करने वाली सेवा, स्पेस वाले फ़ाइल नामों के साथ काम करती है. अपलोड शुरू करने से पहले, उपयोगकर्ता को फ़ाइल के नाम से जुड़ी पाबंदियों की सूचना देने का विकल्प भी है. इसके अलावा, वीडियो शेयर करने वाली सेवा को गड़बड़ी के बारे में पूरी जानकारी देने वाले मैसेज के साथ, वीडियो अपलोड करने की अनुमति नहीं देनी चाहिए.

Fetch API की मदद से गड़बड़ियों को मैनेज करना

ध्यान दें कि नीचे दिए गए कोड के उदाहरणों में, टॉप-लेवल await (ब्राउज़र के साथ काम करने की सुविधा) का इस्तेमाल किया गया है. इसकी वजह यह है कि इस सुविधा से आपके कोड को आसान बनाया जा सकता है.

जब Fetch API गड़बड़ियां दिखाता है

इस उदाहरण में, try ब्लॉक में आने वाली गड़बड़ियों को पकड़ने के लिए, try/catch ब्लॉक स्टेटमेंट का इस्तेमाल किया गया है. उदाहरण के लिए, अगर Fetch API, तय किए गए संसाधन को फ़ेच नहीं कर पाता है, तो गड़बड़ी का मैसेज दिखता है. इस तरह के catch ब्लॉक में, उपयोगकर्ता को काम का अनुभव देने का ध्यान रखें. अगर उपयोगकर्ता को कोई स्पिनर दिखाया जाता है, तो catch ब्लॉक में ये कार्रवाइयां की जा सकती हैं:

  1. पेज से स्पिनर हटाएं.
  2. उपयोगकर्ता को काम के मैसेज भेजें. इनमें यह जानकारी होनी चाहिए कि क्या गड़बड़ी हुई है और उपयोगकर्ता के पास कौनसे विकल्प हैं.
  3. उपलब्ध विकल्पों के आधार पर, उपयोगकर्ता को "फिर से कोशिश करें" बटन दिखाएं.
  4. गड़बड़ी की जानकारी को बैकग्राउंड में, गड़बड़ी ट्रैक करने वाली सेवा या बैक-एंड पर भेजें. यह कार्रवाई, गड़बड़ी को लॉग करती है, ताकि बाद में इसका पता लगाया जा सके.
try {
 
const response = await fetch('https://website');
} catch (error) {
 
// TypeError: Failed to fetch
  console
.log('There was an error', error);
}

बाद में, लॉग की गई गड़बड़ी का पता लगाते समय, आपके पास टेस्ट केस लिखने का विकल्प होता है. इससे, उपयोगकर्ताओं को गड़बड़ी का पता चलने से पहले ही, उसे ठीक किया जा सकता है. गड़बड़ी के हिसाब से, यह टेस्ट यूनिट, इंटिग्रेशन या स्वीकार करने से जुड़ा टेस्ट हो सकता है.

जब नेटवर्क स्टेटस कोड में गड़बड़ी दिखती है

इस कोड के उदाहरण में, एचटीटीपी टेस्टिंग सेवा से अनुरोध किया जाता है. यह सेवा हमेशा एचटीटीपी स्टेटस कोड 429 Too Many Requests के साथ जवाब देती है. दिलचस्प बात यह है कि जवाब, catch ब्लॉक तक नहीं पहुंचता. कुछ अन्य स्टेटस कोड के साथ-साथ 404 स्टेटस, नेटवर्क से जुड़ी गड़बड़ी नहीं दिखाता. इसके बजाय, यह सामान्य तरीके से ठीक हो जाता है.

यह देखने के लिए कि एचटीटीपी स्टेटस कोड सही है या नहीं, इनमें से किसी भी विकल्प का इस्तेमाल किया जा सकता है:

  • Response.ok प्रॉपर्टी का इस्तेमाल करके यह पता लगाएं कि स्टेटस कोड, 200 से 299 की रेंज में था या नहीं.
  • जवाब सही है या नहीं, यह पता लगाने के लिए Response.status प्रॉपर्टी का इस्तेमाल करें.
  • रिस्पॉन्स सही है या नहीं, यह पता लगाने के लिए Response.headers जैसे किसी अन्य मेटाडेटा का इस्तेमाल करें.
let response;

try {
  response
= await fetch('https://httpbin.org/status/429');
} catch (error) {
  console
.log('There was an error', error);
}

// Uses the 'optional chaining' operator
if (response?.ok) {
  console
.log('Use the response here!');
} else {
  console
.log(`HTTP Response Code: ${response?.status}`)
}

एचटीटीपी रिस्पॉन्स स्टेटस कोड को समझने के लिए, अपने संगठन और टीम के लोगों के साथ काम करना सबसे अच्छा तरीका है. बैकएंड डेवलपर, डेवलपर ऑपरेशंस, और सर्विस इंजीनियर कभी-कभी ऐसे असामान्य मामलों के बारे में खास जानकारी दे सकते हैं जिनकी आपको शायद उम्मीद न हो.

नेटवर्क के जवाब को पार्स करते समय गड़बड़ी होने पर

इस कोड के उदाहरण में, एक और तरह की गड़बड़ी के बारे में बताया गया है. यह गड़बड़ी, रिस्पॉन्स बॉडी को पार्स करने के दौरान हो सकती है. Response इंटरफ़ेस, अलग-अलग तरह के डेटा को पार्स करने के आसान तरीके उपलब्ध कराता है. जैसे, टेक्स्ट या JSON. नीचे दिए गए कोड में, एचटीटीपी टेस्टिंग सेवा के लिए नेटवर्क अनुरोध किया गया है. यह सेवा, रिस्पॉन्स बॉडी के तौर पर एक एचटीएमएल स्ट्रिंग दिखाती है. हालांकि, रिस्पॉन्स बॉडी को JSON के तौर पर पार्स करने की कोशिश की जाती है, जिससे गड़बड़ी का मैसेज मिलता है.

let json;

try {
 
const response = await fetch('https://httpbin.org/html');
  json
= await response.json();
} catch (error) {
 
if (error instanceof SyntaxError) {
   
// Unexpected token < in JSON
    console
.log('There was a SyntaxError', error);
 
} else {
    console
.log('There was an error', error);
 
}
}

if (json) {
  console
.log('Use the JSON here!', json);
}

आपको अपने कोड को अलग-अलग तरह के रिस्पॉन्स फ़ॉर्मैट के हिसाब से तैयार करना होगा. साथ ही, यह भी पक्का करना होगा कि किसी अनचाहे रिस्पॉन्स की वजह से, उपयोगकर्ता के वेब पेज पर कोई गड़बड़ी न हो.

इस स्थिति पर विचार करें: आपके पास एक रिमोट रिसॉर्स है, जो मान्य JSON रिस्पॉन्स दिखाता है और Response.json() तरीके से उसे पार्स किया जाता है. ऐसा हो सकता है कि सेवा बंद हो जाए. डाउन होने के बाद, 500 Internal Server Error दिखता है. अगर JSON को पार्स करते समय, गड़बड़ी को ठीक करने के सही तरीकों का इस्तेमाल नहीं किया जाता है, तो उपयोगकर्ता के लिए पेज काम नहीं करेगा. इसकी वजह यह है कि गड़बड़ी को ठीक नहीं किया जा सका.

जब नेटवर्क अनुरोध पूरा होने से पहले ही उसे रद्द करना ज़रूरी हो

इस कोड के उदाहरण में, फ़्लाइट के दौरान किए गए अनुरोध को रद्द करने के लिए AbortController का इस्तेमाल किया गया है. इन-फ़्लाइट अनुरोध, नेटवर्क का ऐसा अनुरोध होता है जो शुरू हो गया है, लेकिन पूरा नहीं हुआ है.

इन-फ़्लाइट अनुरोध को रद्द करने की ज़रूरत पड़ने की स्थितियां अलग-अलग हो सकती हैं. हालांकि, यह आपके इस्तेमाल के उदाहरण और एनवायरमेंट पर निर्भर करता है. यहां दिए गए कोड में, Fetch API को AbortSignal पास करने का तरीका बताया गया है. AbortSignal, AbortController से जुड़ा होता है. साथ ही, AbortController में abort() तरीका शामिल होता है. इससे ब्राउज़र को पता चलता है कि नेटवर्क अनुरोध रद्द किया जाना चाहिए.

const controller = new AbortController();
const signal = controller.signal;

// Cancel the fetch request in 500ms
setTimeout
(() => controller.abort(), 500);

try {
 
const url = 'https://httpbin.org/delay/1';
 
const response = await fetch(url, { signal });
  console
.log(response);
} catch (error) {
 
// DOMException: The user aborted a request.
  console
.log('Error: ', error)
}

नतीजा

गड़बड़ियों को मैनेज करने का एक अहम पहलू यह है कि उन अलग-अलग हिस्सों की पहचान की जाए जिनमें गड़बड़ी हो सकती है. हर स्थिति के लिए, पक्का करें कि आपके पास उपयोगकर्ता के लिए सही फ़ॉलबैक हो. फ़ेच अनुरोध के बारे में, खुद से ये सवाल पूछें:

  • टारगेट सर्वर के बंद होने पर क्या होता है?
  • अगर फ़ेच को कोई अनचाहा जवाब मिलता है, तो क्या होता है?
  • अगर उपयोगकर्ता का इंटरनेट कनेक्शन काम नहीं करता है, तो क्या होगा?

अपने वेब पेज की जटिलता के आधार पर, एक फ़्लोचार्ट भी बनाया जा सकता है. इसमें अलग-अलग स्थितियों के लिए, फ़ंक्शन और यूज़र इंटरफ़ेस के बारे में बताया जाता है.