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

Umar Hansa

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

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

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

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

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

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

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

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

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

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

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

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

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

Fetch API की मदद से गड़बड़ियां ठीक करें

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

जब फे़च एपीआई गड़बड़ी दिखाता है

इस उदाहरण में, try ब्लॉक में मौजूद गड़बड़ियों को ठीक करने के लिए, try/catch ब्लॉक स्टेटमेंट का इस्तेमाल किया गया है. उदाहरण के लिए, अगर फे़च एपीआई बताए गए संसाधन को फ़ेच नहीं कर पाता, तो एक गड़बड़ी होती है. इस तरह के 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 का इस्तेमाल करके, फ़्लाइट बुक करने के अनुरोध को रद्द किया जाता है. इन-फ़्लाइट अनुरोध, ऐसा नेटवर्क अनुरोध होता है जो शुरू हो गया है, लेकिन पूरा नहीं हुआ है.

उन स्थितियों में हो सकता है जहां आपको इन-फ़्लाइट अनुरोध रद्द करने की ज़रूरत पड़ सकती है. हालांकि, यह आपके इस्तेमाल के उदाहरण और माहौल पर निर्भर करता है. नीचे दिया गया कोड बताता है कि फे़च एपीआई में 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)
}

नतीजा

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

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

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