कोणीय में HTTP अनुरोध को पुन: प्रयास करना

सर्वर डेटा तक पहुंच का संगठन लगभग किसी एक पृष्ठ के आवेदन का आधार है। इस तरह के अनुप्रयोगों में सभी गतिशील सामग्री बैकएंड से डाउनलोड की जाती है।

ज्यादातर मामलों में, सर्वर से HTTP अनुरोध मज़बूती से काम करता है और वांछित परिणाम लौटाता है। हालाँकि, कुछ स्थितियों में, अनुरोध विफल हो सकते हैं।

कल्पना करें कि कोई व्यक्ति आपकी वेबसाइट के साथ 200 किलोमीटर प्रति घंटे की गति से देश भर में यात्रा करने वाली ट्रेन में पहुंच बिंदु के माध्यम से कैसे काम करता है। इस परिदृश्य में नेटवर्क कनेक्शन धीमा हो सकता है, लेकिन सर्वर अनुरोध, इसके बावजूद अपना काम करते हैं।

लेकिन अगर ट्रेन सुरंग में जा गिरे तो क्या होगा? एक उच्च संभावना है कि इंटरनेट से कनेक्शन बाधित हो जाएगा और वेब एप्लिकेशन सर्वर पर "पहुंच" करने में सक्षम नहीं होगा। इस मामले में, उपयोगकर्ता को ट्रेन के सुरंग से निकलने और इंटरनेट कनेक्शन के बहाल होने के बाद एप्लिकेशन पेज को फिर से लोड करना होगा।

पृष्ठ को पुनः लोड करने से एप्लिकेशन की वर्तमान स्थिति प्रभावित हो सकती है। इसका मतलब यह है कि उपयोगकर्ता उदाहरण के लिए, उस डेटा को खो सकता है जिसे उसने फ़ॉर्म में दर्ज किया था।

केवल इस तथ्य के साथ सामंजस्य स्थापित करने के बजाय कि एक निश्चित अनुरोध असफल था, इसे कई बार दोहराना और उपयोगकर्ता को एक अनुरूप अधिसूचना दिखाना बेहतर होगा। इस दृष्टिकोण के साथ, जब उपयोगकर्ता को पता चलता है कि एप्लिकेशन समस्या का सामना करने की कोशिश कर रहा है, तो वह सबसे अधिक संभावना पृष्ठ को फिर से लोड नहीं करेगा।



सामग्री, जिसका अनुवाद आज हम प्रकाशित करते हैं, कोणीय-अनुप्रयोगों में असफल अनुरोधों को दोहराने के कई तरीकों के विश्लेषण के लिए समर्पित है।

बार-बार असफल अनुरोध

आइए ऐसी स्थिति को पुन: उत्पन्न करें जो एक ट्रेन से इंटरनेट पर काम करने वाले उपयोगकर्ता का सामना कर सकती है। हम एक बैकएंड बनाएंगे जो पहले तीन प्रयासों के दौरान अनुरोध को गलत तरीके से संसाधित करता है, केवल चौथे प्रयास से डेटा लौटाता है।
आमतौर पर, कोणीय का उपयोग करते हुए, हम एक सेवा बनाते हैं, HttpClient कनेक्ट करते हैं और बैकएंड से डेटा प्राप्त करने के लिए इसका उपयोग करते हैं।

 import {Injectable} from '@angular/core'; import {HttpClient} from '@angular/common/http'; import {EMPTY, Observable} from 'rxjs'; import {catchError} from 'rxjs/operators'; @Injectable() export class GreetingService {  private GREET_ENDPOINT = 'http://localhost:3000';  constructor(private httpClient: HttpClient) {  }  greet(): Observable<string> {    return this.httpClient.get<string>(`${this.GREET_ENDPOINT}/greet`).pipe(      catchError(() => {        //           return EMPTY;      })    );  } } 

यहां कुछ खास नहीं है। हम कोणीय HttpClient मॉड्यूल में प्लग करते हैं और एक सरल GET अनुरोध निष्पादित करते हैं। यदि अनुरोध एक त्रुटि देता है, तो हम इसे संसाधित करने के लिए कुछ कोड निष्पादित करते हैं और अनुरोध के बारे में सूचित करने के लिए एक खाली Observable (अवलोकन योग्य वस्तु) वापस करते हैं। यह कोड, जैसा कि यह था, कहते हैं: "एक त्रुटि थी, लेकिन सब कुछ क्रम में है, मैं इसे संभाल सकता हूं।"

अधिकांश एप्लिकेशन इस तरह से HTTP अनुरोध करते हैं। उपरोक्त कोड में, अनुरोध केवल एक बार निष्पादित किया जाता है। उसके बाद, यह या तो सर्वर से प्राप्त डेटा लौटाता है, या असफल है।

यदि समापन बिंदु /greet अनुपलब्ध है या त्रुटि लौटाता /greet , तो अनुरोध को कैसे दोहराएं? शायद एक उपयुक्त RxJS बयान है? बेशक यह मौजूद है। RxJS के पास हर चीज के लिए ऑपरेटर हैं।

इस स्थिति में पहली बात जो ध्यान में आ सकती है वह है retry । आइए इसकी परिभाषा देखें: “रिटर्न अ ऑब्जर्वेबल जो error को छोड़कर ओरिजनल ऑब्जर्वबल को प्ले करता है। यदि मूल ऑब्जर्वेबल कॉल error , तो यह विधि, त्रुटि को फैलाने के बजाय, मूल ऑब्जर्वेबल को फिर से सदस्यता देगी।

री-सब्सक्रिप्शन की अधिकतम संख्या count तक सीमित है (यह विधि के लिए दिया गया संख्यात्मक पैरामीटर है)। "

retry बहुत कुछ वैसा ही है जैसा हमें चाहिए। तो चलो इसे हमारी श्रृंखला में एम्बेड करते हैं।

 import {Injectable} from '@angular/core'; import {HttpClient} from '@angular/common/http'; import {EMPTY, Observable} from 'rxjs'; import {catchError, retry, shareReplay} from 'rxjs/operators'; @Injectable() export class GreetingService {  private GREET_ENDPOINT = 'http://localhost:3000';  constructor(private httpClient: HttpClient) {  }  greet(): Observable<string> {    return this.httpClient.get<string>(`${this.GREET_ENDPOINT}/greet`).pipe(      retry(3),      catchError(() => {        //           return EMPTY;      }),      shareReplay()    );  } } 

हमने retry ऑपरेटर का सफलतापूर्वक उपयोग किया है। आइए देखें कि यह प्रयोगात्मक आवेदन में निष्पादित HTTP अनुरोध के व्यवहार को कैसे प्रभावित करता है। यहां एक बड़ी GIF फ़ाइल है जो इस एप्लिकेशन की स्क्रीन और ब्राउज़र डेवलपर टूल के नेटवर्क टैब को दिखाती है। आपको यहां इस तरह के कई और प्रदर्शन देखने को मिलेंगे।

हमारा आवेदन बेहद सरल है। यह सिर्फ एक HTTP अनुरोध करता है जब PING THE SERVER बटन पर क्लिक किया जाता है।

जैसा कि पहले ही उल्लेख किया गया है, बैकएंड एक त्रुटि देता है जब पहले तीन अनुरोधों को निष्पादित करने का प्रयास करता है, और जब एक चौथा अनुरोध आता है, तो यह एक सामान्य प्रतिक्रिया देता है।

नेटवर्क डेवलपर के टूल टैब पर, आप देख सकते हैं कि retry उसे सौंपे गए कार्य को हल करता है और तीन बार असफल अनुरोध के निष्पादन को दोहराता है। अंतिम प्रयास सफल होता है, एप्लिकेशन को एक प्रतिक्रिया मिलती है, पेज पर एक संबंधित संदेश दिखाई देता है।

यह सब बहुत अच्छा है। अब आवेदन विफल अनुरोधों को दोहरा सकता है।

हालाँकि, इस उदाहरण में अभी भी सुधार किया जा सकता है। कृपया ध्यान दें कि अब उन अनुरोधों के निष्पादन के तुरंत बाद दोहराए गए अनुरोधों को निष्पादित किया जाता है जो असफल हैं। सिस्टम के इस व्यवहार से हमारी स्थिति में बहुत लाभ नहीं होगा - जब ट्रेन सुरंग में जाती है और इंटरनेट कनेक्शन थोड़ी देर के लिए खो जाता है।

विफल अनुरोधों की विलंबित पुनर्प्राप्ति

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

ऐसा करने के लिए, हमें बार-बार अनुरोधों को निष्पादित करने की प्रक्रिया को बेहतर ढंग से नियंत्रित करने की आवश्यकता है। हमें अनुरोधों को दोहराने के बारे में निर्णय लेने में सक्षम होने की आवश्यकता है। इसका मतलब है कि retry ऑपरेटर की क्षमताएं अब हमारे लिए पर्याप्त नहीं हैं। इसलिए, हम फिर से आरएक्सजेएस पर प्रलेखन की ओर मुड़ते हैं।

प्रलेखन में retryWhen का विवरण होता है, जो हमें सूट करता है। प्रलेखन में, इसे निम्नानुसार वर्णित किया गया है: “एक ऑब्जर्वेबल रिटर्न जो मूल ऑब्जर्वेबल को error के अपवाद के साथ निभाता है। यदि मूल ऑब्जर्वेबल कॉल error , तो यह विधि थ्रोबेबल को फेंक देगी, जो त्रुटि का कारण बनी, ऑब्जर्वेबल notifier से वापस आ गया। यदि यह अवलोकनीय complete या error कहता है, तो यह विधि बाल सदस्यता पर complete या error कहेगी। अन्यथा, यह विधि मूल अवलोकन के लिए फिर से सदस्यता लेगी। "

हां, परिभाषा सरल नहीं है। अधिक सुलभ भाषा में इसका वर्णन करते हैं।

retryWhen एक कॉलबैक स्वीकार करता है जो एक retryWhen रिटर्न देता है। लौटे हुए अवलोकन योग्य निर्णय लेते हैं कि कुछ नियमों के आधार पर retryWhen ऑपरेटर कैसे व्यवहार करेगा। अर्थात्, यह है कि जब retryWhen ऑपरेटर retryWhen :

• यह काम करना बंद कर देता है और एक त्रुटि फेंकता है अगर लौटे ऑब्जर्वबल में कोई त्रुटि होती है।
• यदि प्रेक्षित रिपोर्ट पूर्ण हो जाती है तो यह बाहर निकल जाता है।
• अन्य मामलों में, जब ऑब्जर्वेबल सफलतापूर्वक लौटता है, तो यह मूल ऑब्जर्वेबल के निष्पादन को दोहराता है

कॉलबैक केवल तभी कहा जाता है जब मूल ऑब्जर्वेबल पहली बार एक त्रुटि फेंकता है।

अब हम इस ज्ञान का उपयोग RxJS retryWhen का उपयोग करते हुए एक असफल अनुरोध के लिए विलंबित retryWhen तंत्र बनाने के लिए कर सकते हैं।

 retryWhen((errors: Observable<any>) => errors.pipe(    delay(delayMs),    mergeMap(error => retries-- > 0 ? of(error) : throwError(getErrorMessage(maxEntry))    )) ) 

यदि मूल ऑब्जर्वेबल, जो हमारा HTTP अनुरोध है, एक त्रुटि देता है, तो retryWhen स्टेटमेंट retryWhen । कॉलबैक में, हमारे पास उस त्रुटि तक पहुंच है जो विफलता का कारण बनी। हम errors को दूर करते errors , रिट्रीट की संख्या को कम करते हैं, और एक नया ऑब्जर्वेबल लौटाते हैं जो एक त्रुटि फेंकता है।

retryWhen के नियमों के आधार पर, यह retryWhen , क्योंकि यह retryWhen , अनुरोध को retryWhen । यदि पुनरावृत्ति कई बार असफल होती है और retries चर का मान 0 तक घट जाता है, तो हम अनुरोध को निष्पादित करते समय एक त्रुटि के साथ कार्य समाप्त करते हैं।

अद्भुत! जाहिर है, हम ऊपर दिए गए कोड को ले सकते हैं और इसके साथ हमारी श्रृंखला में retry ऑपरेटर को बदल सकते हैं। लेकिन यहां हम थोड़ा धीमा हो जाते हैं।

वेरिएबल retries से कैसे retries ? इस चर में विफल अनुरोध पुनर्प्राप्ति प्रणाली की वर्तमान स्थिति है। वह कहां घोषित है? स्थिति कब रीसेट की जाती है? राज्य को धारा के अंदर प्रबंधित करने की आवश्यकता है, इसके बाहर नहीं।

Reat अपने स्वयं के विलंबित कथन का विवरण दें

हम राज्य प्रबंधन की समस्या को हल कर सकते हैं और उपरोक्त कोड को एक अलग RxJS ऑपरेटर के रूप में लिखकर कोड की पठनीयता में सुधार कर सकते हैं।

अपने खुद के RxJS ऑपरेटर बनाने के लिए अलग-अलग तरीके हैं। किस विधि का उपयोग करना है यह इस बात पर निर्भर करता है कि विशेष ऑपरेटर कैसे संरचित है।

हमारा ऑपरेटर मौजूदा RxJS ऑपरेटरों पर आधारित है। नतीजतन, हम अपने स्वयं के ऑपरेटर बनाने के लिए सबसे सरल तरीके का उपयोग कर सकते हैं। हमारे मामले में, RxJs ऑपरेटर निम्नलिखित हस्ताक्षर के साथ एक फ़ंक्शन है:

 const customOperator = (src: Observable<A>) => Observable<B> 

यह कथन मूल ऑब्जर्वेबल को लेता है और एक और ऑब्जर्वेबल को लौटाता है।

चूंकि हमारा ऑपरेटर उपयोगकर्ता को यह निर्दिष्ट करने की अनुमति देता है कि कितनी बार बार-बार अनुरोधों को निष्पादित किया जाना चाहिए, और उन्हें कितनी बार निष्पादित करने की आवश्यकता है, तो हमें उपरोक्त फ़ंक्शन घोषणा को फ़ैक्टरी फ़ंक्शन में लपेटने की आवश्यकता है, जिसमें विलंब ( delayMs बीच विलंब) और maxRetry ( दोहराव की अधिकतम संख्या)।

 const customOperator = (delayMs: number, maxRetry: number) => {   return (src: Observable<A>) => Observable<B> } 

यदि आप एक ऑपरेटर बनाना चाहते हैं जो मौजूदा ऑपरेटरों पर आधारित नहीं है, तो आपको त्रुटियों और सदस्यता को संभालने पर ध्यान देने की आवश्यकता है। इसके अलावा, आपको Observable कक्षा का विस्तार करने और lift फ़ंक्शन को लागू करने की आवश्यकता होगी।

यदि आप रुचि रखते हैं, तो यहां देखें ।

तो, उपरोक्त कोड स्निपेट के आधार पर, आइए अपने स्वयं के RxJs ऑपरेटर लिखें।

 import {Observable, of, throwError} from 'rxjs'; import {delay, mergeMap, retryWhen} from 'rxjs/operators'; const getErrorMessage = (maxRetry: number) =>  `Tried to load Resource over XHR for ${maxRetry} times without success. Giving up`; const DEFAULT_MAX_RETRIES = 5; export function delayedRetry(delayMs: number, maxRetry = DEFAULT_MAX_RETRIES) {  let retries = maxRetry;  return (src: Observable<any>) =>    src.pipe(      retryWhen((errors: Observable<any>) => errors.pipe(        delay(delayMs),        mergeMap(error => retries-- > 0 ? of(error) : throwError(getErrorMessage(maxRetry))        ))      )    ); } 

बहुत बढ़िया। अब हम इस ऑपरेटर को क्लाइंट कोड में आयात कर सकते हैं। HTTP अनुरोध को निष्पादित करते समय हम इसका उपयोग करेंगे।

 return this.httpClient.get<string>(`${this.GREET_ENDPOINT}/greet`).pipe(        delayedRetry(1000, 3),        catchError(error => {            console.log(error);            //               return EMPTY;        }),        shareReplay()    ); 

हमने delayedRetry ऑपरेटर को चेन में डाल दिया और पैरामीटर के रूप में 1000 और 3 नंबर दिए। पहला पैरामीटर बार-बार अनुरोध करने के प्रयासों के बीच मिलीसेकंड में देरी सेट करता है। दूसरा पैरामीटर दोहराया अनुरोधों की अधिकतम संख्या निर्धारित करता है।

एप्लिकेशन को पुनरारंभ करें और देखें कि नया ऑपरेटर कैसे काम करता है।

ब्राउज़र डेवलपर के टूल का उपयोग करके कार्यक्रम के व्यवहार का विश्लेषण करने के बाद, हम देख सकते हैं कि अनुरोध को निष्पादित करने के लिए बार-बार प्रयास के निष्पादन में एक सेकंड के लिए देरी हो रही है। अनुरोध का सही उत्तर प्राप्त करने के बाद, एप्लिकेशन विंडो में एक संबंधित संदेश दिखाई देगा।

घातांक निवेदन

चलो विफल अनुरोधों के विलंबित पुनर्प्रयास के विचार को विकसित करते हैं। पहले, हमने हमेशा एक ही समय पर दोहराए गए अनुरोधों के निष्पादन में देरी की।

यहां हम बात करते हैं कि प्रत्येक प्रयास के बाद देरी को कैसे बढ़ाया जाए। अनुरोध को पुनः प्राप्त करने का पहला प्रयास एक सेकंड के बाद किया जाता है, दूसरा दो सेकंड के बाद, तीसरा तीन के बाद।

एक नया कथन बनाएँ, retryWithBackoff , जो इस व्यवहार को लागू करता है।

 import {Observable, of, throwError} from 'rxjs'; import {delay, mergeMap, retryWhen} from 'rxjs/operators'; const getErrorMessage = (maxRetry: number) =>  `Tried to load Resource over XHR for ${maxRetry} times without success. Giving up.`; const DEFAULT_MAX_RETRIES = 5; const DEFAULT_BACKOFF = 1000; export function retryWithBackoff(delayMs: number, maxRetry = DEFAULT_MAX_RETRIES, backoffMs = DEFAULT_BACKOFF) {  let retries = maxRetry;  return (src: Observable<any>) =>    src.pipe(      retryWhen((errors: Observable<any>) => errors.pipe(        mergeMap(error => {            if (retries-- > 0) {              const backoffTime = delayMs + (maxRetry - retries) * backoffMs;              return of(error).pipe(delay(backoffTime));            }            return throwError(getErrorMessage(maxRetry));          }        )))); } 

यदि आप आवेदन में इस ऑपरेटर का उपयोग करते हैं और इसका परीक्षण करते हैं, तो आप देख सकते हैं कि प्रत्येक नए प्रयास के बाद दोहराया अनुरोध को निष्पादित करने में देरी कैसे होती है।

प्रत्येक प्रयास के बाद, हम एक निश्चित समय प्रतीक्षा करते हैं, अनुरोध दोहराते हैं और प्रतीक्षा समय बढ़ाते हैं। यहां, हमेशा की तरह, जब सर्वर अनुरोध का सही उत्तर देता है, तो हम एप्लिकेशन विंडो में एक संदेश प्रदर्शित करते हैं।

परिणाम

बार-बार विफल HTTP अनुरोध अनुप्रयोगों को अधिक स्थिर बनाता है। यह बहुत महत्वपूर्ण प्रश्नों का प्रदर्शन करते समय विशेष रूप से महत्वपूर्ण है, जिसके माध्यम से प्राप्त किए गए डेटा के बिना, एप्लिकेशन सामान्य रूप से काम नहीं कर सकता है। उदाहरण के लिए, यह उन सर्वरों के पते युक्त कॉन्फ़िगरेशन डेटा हो सकता है जिनके साथ एप्लिकेशन को सहभागिता करने की आवश्यकता होती है।

ज्यादातर परिदृश्यों में, RxJs रिट्री retry विफल अनुरोधों के लिए एक विश्वसनीय रिट्री सिस्टम प्रदान करने के लिए पर्याप्त नहीं है। retryWhen डेवलपर को बार-बार अनुरोधों पर उच्च स्तर का नियंत्रण देता है। यह आपको बार-बार अनुरोधों के लिए अंतराल को कॉन्फ़िगर करने की अनुमति देता है। इस ऑपरेटर की क्षमताओं के कारण, विलंबित पुनरावृत्ति योजना या तेजी से विलंबित पुनरावृत्ति को लागू करना संभव है।

RxJS श्रृंखला में पुन: उपयोग के लिए उपयुक्त व्यवहार पैटर्न को लागू करते समय, यह अनुशंसा की जाती है कि उन्हें नए ऑपरेटरों के रूप में स्वरूपित किया जाए। यहां वह रिपॉजिटरी है जिससे इस लेख में कोड का उपयोग किया गया था।

प्रिय पाठकों! आप HTTP अनुरोधों को पुनः प्राप्त करने की समस्या का समाधान कैसे करते हैं?