BIF पैटर्न: सर्वर डेटा के साथ क्लीन-एंड कोड और सुविधाजनक कार्य

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

विफल सर्वर API की समस्या

आइए कई वास्तविक परियोजनाओं के आधार पर एक सशर्त उदाहरण पर विचार करें। मान लीजिए कि हम एक संगठन के लिए एक नई वेबसाइट विकसित कर रहे हैं जो कुछ समय से मौजूद है। उसके पास पहले से ही अन्य समापन बिंदु हैं, लेकिन हम जो बनाने जा रहे हैं, उसके लिए वे काफी डिज़ाइन नहीं हैं। यहां हमें केवल उपयोगकर्ता को प्रमाणित करने, उसके बारे में जानकारी प्राप्त करने और इस उपयोगकर्ता से अनवांटेड नोटिफिकेशन की सूची डाउनलोड करने के लिए सर्वर तक पहुंचने की आवश्यकता है। परिणामस्वरूप, हम सर्वर API के निम्नलिखित समापन बिंदुओं में रुचि रखते हैं:

• /auth : उपयोगकर्ता को अधिकृत करता है और एक्सेस टोकन लौटाता है।
• /profile : मूल उपयोगकर्ता जानकारी लौटाता है।
• /notifications : आप बिना पढ़े उपयोगकर्ता सूचनाएँ प्राप्त कर सकते हैं।

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

उदाहरण के लिए, एंडपॉइंट /profile प्राचीन काल में बनाया गया था, यह जावास्क्रिप्ट में नहीं लिखा गया था, परिणामस्वरूप, इसमें दिए गए डेटा के गुणों के नाम एक जेएस एप्लिकेशन के लिए असामान्य दिखते हैं:

 { "Profiles": [   {     "id": 1234,     "Christian_Name": "David",     "Surname": "Gilbertson",     "Photographs": [       {         "Size": "Medium",         "URLS": [           "/images/david.png"         ]       }     ],     "Last_Login": "2018-01-01"   } ] } 

सामान्य तौर पर - कुछ भी अच्छा नहीं है।

सच है, यदि आप यह देखते हैं कि समापन बिंदु /notifications क्या पैदा करती हैं, तो /profile से उपरोक्त डेटा बहुत अच्छा लगेगा:

 { "data": {   "msg-1234": {     "timestamp": "1529739612",     "user": {       "Christian_Name": "Alice",       "Surname": "Guthbertson",       "Enhanced": "True",       "Photographs": [         {           "Size": "Medium",           "URLS": [             "/images/alice.png"           ]         }       ]     },     "message_summary": "Hey I like your hair, it re",     "message": "Hey I like your hair, it really goes nice with your eyes"   },   "msg-5678": {     "timestamp": "1529731234",     "user": {       "Christian_Name": "Bob",       "Surname": "Smelthsen",       "Photographs": [         {           "Size": "Medium",           "URLS": [             "/images/smelth.png"           ]         }       ]     },     "message_summary": "I'm launching my own cryptocu",     "message": "I'm launching my own cryptocurrency soon and many thanks for you to look at and talk about"   } } } 

यहां संदेशों की सूची एक वस्तु है, न कि एक सरणी। इसके अलावा, यहां उपयोगकर्ता डेटा हैं, जो कि केवल अनपेक्षित रूप से /profile एंडपॉइंट के मामले में व्यवस्थित हैं। और - यहाँ एक आश्चर्य की बात है - timestamp संपत्ति में 1970 की शुरुआत से सेकंड की संख्या शामिल है।

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


सिस्टम आरेख

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

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

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

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

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

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

वास्तव में, एक विकल्प के रूप में, इस समस्या को हल करने के लिए एक स्थिर प्रकार की प्रणाली को लागू करना संभव होगा, लेकिन सख्त टाइपिंग सक्षम नहीं है, केवल इसकी उपस्थिति के तथ्य से, खराब कोड को अच्छा बनाने के लिए।

अब आप जिस समस्या का सामना कर रहे हैं उसकी गंभीरता को देख सकते हैं, आइए इसे सुलझाने के तरीकों के बारे में बात करते हैं।

समाधान # 1: सर्वर एपीआई बदल रहा है

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


नया सर्वर API जो सिस्टम के क्लाइंट पक्ष की आवश्यकता को ठीक से उत्पन्न करता है

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

समाधान # 2: BFF पैटर्न

यह एक अच्छा पुराना BFF ( बैकएंड-फॉर-द-फ्रंटेंड ) पैटर्न है। इस पैटर्न का उपयोग करके, आप जटिल सार्वभौमिक REST समापन बिंदुओं से सार कर सकते हैं और सामने वाले को वास्तव में वही दे सकते हैं जिसकी उसे आवश्यकता है। यहाँ इस तरह के एक समाधान का एक योजनाबद्ध प्रतिनिधित्व है।


BFF पैटर्न लागू करना

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

मेरा पसंदीदा आर्किटेक्चर NodeJS BFF है, जिसके उपयोग से फ्रंट-एंड डेवलपर्स क्या कर सकते हैं, उनकी जरूरत है, जिससे वे क्लाइंट एप्लिकेशन के लिए शानदार APIs बना सकें। आदर्श रूप से, संबंधित कोड सामने के अंत के कोड के समान ही रिपॉजिटरी में है, जो कोड साझाकरण को सरल करता है, उदाहरण के लिए, भेजे गए डेटा की जाँच के लिए, क्लाइंट और सर्वर दोनों पर।

इसके अलावा, इसका अर्थ है कि एप्लिकेशन के क्लाइंट भाग और उसके सर्वर API में परिवर्तन की आवश्यकता वाले कार्यों को एक रिपॉजिटरी में किया जाता है। एक तिपहिया, जैसा कि वे कहते हैं, लेकिन अच्छा है।

हालाँकि, BFF का हमेशा उपयोग नहीं किया जा सकता है। और यह तथ्य हमें खराब सर्वर एपीआई के सुविधाजनक उपयोग की समस्या के लिए एक और समाधान की ओर ले जाता है।

समाधान # 3: BIF पैटर्न

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


BIF पैटर्न लागू करना

▍ बीआईएफ क्या है?

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

यहाँ मैं यह नोट करना चाहूँगा, हालाँकि इसे कोई आपदा नहीं कहा जा सकता है, मुझे अक्सर अनपढ़ बीआईएफ कार्यान्वयन को देखना पड़ता था। इसलिए, यह मुझे लगता है कि कई लोग इस पैटर्न को सही ढंग से लागू करने के बारे में एक कहानी सुनने के लिए इच्छुक होंगे।

BIF कोड को एक कोड के रूप में माना जाना चाहिए जिसे एक बार Node.js सर्वर पर ले जाया और स्थानांतरित किया जा सकता है, जिसके बाद सब कुछ पहले की तरह ही काम करेगा। या यहां तक ​​कि इसे एक निजी एनपीएम पैकेज में स्थानांतरित करें, जिसका उपयोग एक कंपनी के ढांचे के भीतर कई फ्रंट-एंड परियोजनाओं में किया जाएगा, जो कि बस आश्चर्यजनक है।

याद रखें कि हमने मुख्य समस्याओं के ऊपर चर्चा की थी जो एक असफल सर्वर एपीआई के साथ काम करते समय उत्पन्न होती हैं। उनमें से एपीआई के लिए एक बहुत लगातार कॉल है और तथ्य यह है कि उनके द्वारा लौटाए गए डेटा फ्रंटएंड की जरूरतों को पूरा नहीं करते हैं।

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

Ining एपीआई कॉल का संयोजन

हमारे क्लाइंट कोड में सर्वर एपीआई के लिए बहुत सारी कॉल करना इतनी गंभीर समस्या नहीं है। हालाँकि, मैं इसे अमूर्त करना चाहूंगा, ताकि एक "अनुरोध" (एप्लिकेशन कोड से BIF लेयर तक) को पूरा किया जा सके, और वास्तव में प्रतिक्रिया में जो आवश्यक हो, प्राप्त करें।

बेशक, हमारे मामले में, सर्वर से तीन HTTP अनुरोध करने से कोई बच नहीं सकता है, लेकिन एप्लिकेशन को इसके बारे में जानने की आवश्यकता नहीं है।

मेरे BIF लेयर के API को फ़ंक्शंस के रूप में दर्शाया गया है। इसलिए, जब एप्लिकेशन को उपयोगकर्ता के बारे में कुछ डेटा की आवश्यकता होती है, तो वह getUser() फ़ंक्शन को कॉल करेगा, जो इस डेटा को इसे वापस कर देगा। यहां देखें कि यह फ़ंक्शन कैसा है:

 import parseUserData from './parseUserData'; import fetchJson from './fetchJson'; export const getUser = async () => { const auth = await fetchJson('/auth'); const [ profile, notifications ] = await Promise.all([   fetchJson(`/profile/${auth.userId}`, auth.jwt),   fetchJson(`/notifications/${auth.userId}`, auth.jwt), ]); return parseUserData(auth, profile, notifications); }; 

यहां, सबसे पहले, एक टोकन प्राप्त करने के लिए प्रमाणीकरण सेवा से अनुरोध किया जाता है, जिसका उपयोग उपयोगकर्ता को अधिकृत करने के लिए किया जा सकता है (हम यहां प्रमाणीकरण तंत्र के बारे में बात नहीं करेंगे, फिर भी हमारा मुख्य लक्ष्य बीआईएफ है)।

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

वैसे, यह देखें कि async/await कंस्ट्रक्शन कितना सुंदर लगता है जब इसके साथ काम करते समय Promise.all और विनाशकारी असाइनमेंट का उपयोग किया जाता है।

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

▍ डेटा की सफाई

मैं तुरंत एक सिफारिश देना चाहता हूं, जो, मेरा मानना ​​है कि एक परियोजना को गंभीरता से प्रभावित कर सकता है, जिसमें पहले एक बीआईएफ परत नहीं थी, विशेष रूप से, एक नई परियोजना। कुछ समय के लिए सर्वर से आपको क्या मिलेगा, इसके बारे में न सोचने की कोशिश करें। इसके बजाय, इस बात पर ध्यान दें कि आपके एप्लिकेशन को किन डेटा की आवश्यकता है।

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

तो, वापस हमारे व्यवसाय के लिए। अब हम जानते हैं कि तीन सर्वर एपीआई से प्राप्त डेटा कैसा दिखता है, और हम जानते हैं कि विश्लेषण के बाद उन्हें क्या करना चाहिए।

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

 import parseUserData from './parseUserData'; it('should parse the data', () => { const authApiData = {   userId: 1234,   jwt: 'the jwt', }; const profileApiData = {   Profiles: [     {       id: 1234,       Christian_Name: 'David',       Surname: 'Gilbertson',       Photographs: [         {           Size: 'Medium',           URLS: [             '/images/david.png',           ],         },       ],       Last_Login: '2018-01-01'     },   ], }; const notificationsApiData = {   data: {     'msg-1234': {       timestamp: '1529739612',       user: {         Christian_Name: 'Alice',         Surname: 'Guthbertson',         Enhanced: 'True',         Photographs: [           {             Size: 'Medium',             URLS: [               '/images/alice.png'             ]           }         ]       },       message_summary: 'Hey I like your hair, it re',       message: 'Hey I like your hair, it really goes nice with your eyes'     },     'msg-5678': {       timestamp: '1529731234',       user: {         Christian_Name: 'Bob',         Surname: 'Smelthsen',       },       message_summary: 'I\'m launching my own cryptocu',       message: 'I\'m launching my own cryptocurrency soon and many thanks for you to look at and talk about'     },   }, }; const parsedData = parseUserData(authApiData, profileApiData, notificationsApiData); expect(parsedData).toEqual({   jwt: 'the jwt',   id: '1234',   name: 'David Gilbertson',   photoUrl: '/images/david.png',   notifications: [     {       id: 'msg-1234',       dateTime: expect.any(Date),       name: 'Alice Guthbertson',       premiumMember: true,       photoUrl: '/images/alice.png',       message: 'Hey I like your hair, it really goes nice with your eyes'     },     {       id: 'msg-5678',       dateTime: expect.any(Date),       name: 'Bob Smelthsen',       premiumMember: false,       photoUrl: '/images/placeholder.jpg',       message: 'I\'m launching my own cryptocurrency soon and many thanks for you to look at and talk about'     },   ], }); }); 

और यहाँ फ़ंक्शन का कोड ही है:

 const getPhotoFromProfile = profile => { try {   return profile.Photographs[0].URLS[0]; } catch (err) {   return '/images/placeholder.jpg'; //   } }; const getFullNameFromProfile = profile => `${profile.Christian_Name} ${profile.Surname}`; export default function parseUserData(authApiData, profileApiData, notificationsApiData) { const profile = profileApiData.Profiles[0]; const result = {   jwt: authApiData.jwt,   id: authApiData.userId.toString(), // ID        name: getFullNameFromProfile(profile),   photoUrl: getPhotoFromProfile(profile),   notifications: [], //      ,     }; Object.entries(notificationsApiData.data).forEach(([id, notification]) => {   result.notifications.push({     id,     dateTime: new Date(Number(notification.timestamp) * 1000), // ,   ,   ,     Unix,         name: getFullNameFromProfile(notification.user),     photoUrl: getPhotoFromProfile(notification.user),     message: notification.message,     premiumMember: notification.user.Enhanced === 'True',   }) }); return result; } 

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

मैंने पहले कहा था कि डेटा के संयोजन और समाशोधन के लिए BFF मेरा पसंदीदा दृष्टिकोण है, लेकिन एक ऐसा क्षेत्र है जिसमें BIF BFF से बेहतर है। अर्थात्, सर्वर से प्राप्त डेटा में जावास्क्रिप्ट ऑब्जेक्ट शामिल हो सकते हैं जो JSON का समर्थन नहीं करते हैं, जैसे Date या Map ऑब्जेक्ट (शायद यह सबसे अधिक अप्रयुक्त जावास्क्रिप्ट सुविधाओं में से एक है)। उदाहरण के लिए, हमारे मामले में, हमें उस तारीख को रूपांतरित करना होगा जो सर्वर से आई थी (सेकंड में व्यक्त की गई, मिलीसेकंड नहीं) एक Date जेएस ऑब्जेक्ट में।

परिणाम

अगर आपको लगता है कि आपके प्रोजेक्ट में कुछ ऐसा है जिसमें हमने असफल API की समस्याओं की जांच की है, तो क्लाइंट पर सर्वर से डेटा का उपयोग करने के बारे में अपने आप से निम्नलिखित प्रश्न पूछकर इसके कोड का विश्लेषण करें:

• क्या आपको उन गुणों को संयोजित करना होगा जो कभी भी अलग से उपयोग नहीं किए जाते हैं (उदाहरण के लिए, उपयोगकर्ता का पहला और अंतिम नाम)?
• क्या JS कोड को संपत्ति के नाम के साथ मिलकर काम करना पड़ता है जो JS (PascalCase की तरह) में स्वीकार नहीं किया जाता है?
• विभिन्न पहचानकर्ताओं के डेटा प्रकार क्या हैं? शायद कभी ये तार होते हैं, कभी संख्या?
• आपकी परियोजना में तारीखें कैसे प्रस्तुत की जाती हैं? हो सकता है कि कभी-कभी ये Date जेएस ऑब्जेक्ट इंटरफ़ेस में उपयोग के लिए तैयार होते हैं, और कभी-कभी संख्या या तार भी होते हैं?
• क्या आपको अक्सर उनके अस्तित्व के लिए संपत्तियों की जांच करनी होती है, या जाँचना चाहिए कि क्या कोई इकाई एक सरणी है इससे पहले कि आप इस इकाई के तत्वों को उसके आधार पर उपयोगकर्ता इंटरफ़ेस के कुछ टुकड़े बनाने के लिए गणना करना शुरू करें? क्या यह हो सकता है कि यह इकाई एक सरणी नहीं होगी, भले ही खाली हो?
• क्या आपको इंटरफ़ेस बनाते समय सरणियों को सॉर्ट या फ़िल्टर करना होगा, जो कि, आदर्श रूप से, पहले से ही सही ढंग से सॉर्ट और फ़िल्टर किए जाने चाहिए?
• यदि यह पता चला है कि, अपने अस्तित्व के लिए गुणों की जांच करते समय, कोई गुण नहीं मांगे गए हैं, तो क्या आपको कुछ डिफ़ॉल्ट मानों का उपयोग करने के लिए स्विच करना होगा (उदाहरण के लिए, मानक तस्वीर का उपयोग करें जब सर्वर से प्राप्त डेटा में कोई उपयोगकर्ता फोटो नहीं है)?
• क्या गुण समान रूप से नामित हैं? क्या ऐसा होता है कि एक ही इकाई के अलग-अलग नाम हो सकते हैं, जो संभवतः, अपेक्षाकृत पुराने, "पुराने" और "नए" सर्वर एपीआई के संयुक्त उपयोग के कारण होता है?
• क्या आपको उपयोगी डेटा के साथ, कहीं डेटा का उपयोग नहीं करना है, जो केवल इसलिए कर रहा है क्योंकि यह सर्वर एपीआई से आता है? क्या यह अप्रयुक्त डेटा डिबगिंग में हस्तक्षेप करता है?

यदि आप इस सूची में से एक या दो प्रश्नों का उत्तर सकारात्मक रूप से दे सकते हैं, तो शायद आपको किसी ऐसी चीज़ की मरम्मत नहीं करनी चाहिए जो पहले से ठीक से काम करती हो।

हालाँकि, यदि आप इन प्रश्नों को पढ़ रहे हैं, तो उनमें से प्रत्येक में अपनी परियोजना की समस्याओं का पता लगाएँ, यदि आपके कोड का उपकरण इस सब के कारण अनावश्यक रूप से जटिल है, अगर यह देखना और परीक्षण करना कठिन है, यदि इसमें ऐसी त्रुटियां हैं, जिनका पता लगाना मुश्किल है, तो BIF पैटर्न देखें।

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

प्रिय पाठकों! , BIF?