फ्रंटएंड के लिए बैकएंड या कैसे Yandex.Market बैसाखी के बिना एक एपीआई बनाता है

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

यह गिरावट, Yandex.Market 18 साल की हो गई। इस समय, संबद्ध मार्केट इंटरफ़ेस विकसित हो रहा है। संक्षेप में, यह व्यवस्थापक पैनल है जिसके साथ स्टोर कैटलॉग अपलोड कर सकते हैं, वर्गीकरण के साथ काम कर सकते हैं, आंकड़ों का पालन कर सकते हैं, समीक्षाओं का जवाब दे सकते हैं, आदि। परियोजना की बारीकियां ऐसी हैं कि आपको विभिन्न बैकएंड के साथ बहुत अधिक बातचीत करनी होगी। हालाँकि, डेटा एक विशिष्ट बैकएंड से हमेशा एक स्थान पर प्राप्त नहीं किया जा सकता है।

किसी समस्या के लक्षण

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

तब प्रबंधक "मैं आपको एक एपीआई लाया" शब्दों के साथ सामने के छोर पर जाता है और जल्दी से सब कुछ स्क्रिप्ट की पेशकश करता है, क्योंकि, उनकी राय में, लगभग सभी काम पहले ही हो चुके हैं।

आप दस्तावेज़ देखें और इसे देखें:

№ |   ---------------------- 53 | feed_shoffed_id 54 | fesh 55 | filter-currency 56 | showVendors 

कुछ अजीब नहीं लगता? ऊंट, सांप और कबाब मामला एक पेन में। मैं फेश पैरामीटर की बात नहीं कर रहा हूं। आखिर क्या है? ऐसा शब्द भी मौजूद नहीं है। बिगाड़ने से पहले अनुमान लगाने की कोशिश करें।

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

असुविधाजनक एपीआई के लिए बहुत सारे विकल्प हैं। एक क्लासिक उदाहरण - एपीआई खोज और रिटर्न परिणाम:

 result: [ {id: 1, name: 'IPhone 8'}, {id: 2, name: 'IPhone 8 Plus'}, {id: 3, name: 'IPhone X'}, ] result: {id: 1, name: 'IPhone 8'} result: null 

यदि सामान मिलता है, तो हमें एक सरणी मिलती है। यदि एक उत्पाद मिलता है, तो हमें इस उत्पाद के साथ एक वस्तु मिलती है। यदि कुछ भी नहीं मिला है, तो सबसे अच्छा हमें शून्य मिलता है। सबसे खराब स्थिति में, बैकएंड 404 या यहां तक ​​कि 400 (खराब अनुरोध) के साथ प्रतिक्रिया करता है।

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

तो इस समस्या का समाधान क्या हो सकता है? स्वीकार्य गुणवत्ता के एपीआई के साथ काम करने के लिए हम अपनी ओर से फ्रंट-एंड प्रदाताओं के रूप में क्या कर सकते हैं?

आगे पीछे होना

हम भागीदार इंटरफ़ेस में प्रतिक्रिया / Redux क्लाइंट का उपयोग करते हैं। क्लाइंट के अंतर्गत Node.js निहित है, जो बहुत सी सहायक चीजें करता है, उदाहरण के लिए, इसे संपादकों के शुरुआती पेज पर फेंकता है। यदि आपके पास सर्वर-साइड रेंडरिंग है, तो यह महत्वपूर्ण नहीं है कि किस क्लाइंट फ्रेमवर्क के साथ, सबसे अधिक संभावना है, यह एक नोड द्वारा प्रदान किया गया है। लेकिन क्या होगा यदि आप एक कदम आगे जाते हैं और सीधे बैकएंड में क्लाइंट से संपर्क नहीं करते हैं, लेकिन अपने प्रॉक्सी एपीआई को नोड पर बना लेते हैं, जो कि अधिकतम ग्राहक आवश्यकताओं के अनुरूप होता है?
इस तकनीक को BFF (Backend For Frontend) कहा जाता है। यह शब्द पहली बार 2015 में साउंडक्लाउड द्वारा पेश किया गया था, और इस विचार को योजनाबद्ध रूप से निम्नानुसार दर्शाया जा सकता है:

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

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

परिणाम के साथ उस उदाहरण को याद रखें जब बैकएंड अशक्त, एक सरणी या एक वस्तु लौटाता है? अब हम इसे सामान्य पर वापस ला सकते हैं - कुछ इस तरह:

 function getItems (response) { if (isNull(response)) return [] if (isObject(response)) return [response] return response } 

यह कोड भयानक लगता है। क्योंकि वह भयानक है। लेकिन हमें अभी भी ऐसा करने की जरूरत है। हमारे पास एक विकल्प है: इसे सर्वर पर या क्लाइंट पर करें। मैं एक सर्वर चुनता हूं।

हम इन सभी कबाब और साँप के मामलों को हमारे लिए सुविधाजनक शैली में भी मैप कर सकते हैं और यदि आवश्यक हो तो तुरंत डिफ़ॉल्ट मान डाल सकते हैं।

 query: { 'feed_shoffer_id': 'feedShofferId', 'pi-from': 'piFrom', 'show-urls': ({showUrls = 'offercard'}) => showUrls, } 

हमें और क्या फायदे मिलते हैं?

1. छानने का काम । ग्राहक को केवल वही मिलता है जिसकी उसे आवश्यकता है, अधिक नहीं, कम नहीं।
2. एकत्रीकरण। कई अजाक्स अनुरोध करने के लिए क्लाइंट नेटवर्क और बैटरी को बर्बाद करने की आवश्यकता नहीं है। इस तथ्य के कारण ध्यान देने योग्य गति प्राप्त होती है कि कनेक्शन खोलना एक महंगा ऑपरेशन है।
3. भंडारित करता है। आपकी बार-बार एकत्र की गई कॉल किसी को भी फिर से नहीं खींचेगी, लेकिन केवल 304 नॉट मॉडिफ़ाइड रिटर्न।
4. डेटा छिपाना । उदाहरण के लिए, आपके पास टोकन हो सकते हैं जो बैकएंड के बीच की आवश्यकता होती है और क्लाइंट को नहीं जाना चाहिए। ग्राहक को इन टोकन के अस्तित्व के बारे में जानने का अधिकार नहीं हो सकता है, न कि उनकी सामग्री का उल्लेख करने के लिए।
5. माइक्रोसर्विस । यदि आपके पास पीठ पर एक मोनोलिथ है, तो बीएफएफ माइक्रोसर्विस का पहला कदम है।

अब विपक्ष के बारे में।

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

इन minuses को समतल करने के लिए, सरल नियमों का पालन करना पर्याप्त है। पहला फ्रंट-एंड और बिजनेस लॉजिक को अलग करना है। आपके BFF को कोर API के व्यावसायिक तर्क को नहीं बदलना चाहिए। दूसरा, यदि आवश्यक हो तो आपकी परत को केवल डेटा परिवर्तित करना चाहिए। हम स्व-निहित व्यापक एपीआई के बारे में बात नहीं कर रहे हैं, लेकिन केवल एक प्रॉक्सी के बारे में जो अंतराल को भरता है, बैकएंड की खामियों को सही करता है।

GraphQL

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

वहीं, ग्राफकॉल REST के ऊपर काम कर सकता है, यानी डेटा स्रोत डेटाबेस नहीं है, बल्कि बाकी एपीआई है। ग्राफकॉल की घोषणात्मक प्रकृति के कारण, इस तथ्य के कारण कि यह सब रिएक्ट और संपादकों के साथ है, आपका क्लाइंट आसान हो जाता है।

वास्तव में, मैं ग्राफफेल को अपने प्रोटोकॉल और सख्त क्वेरी भाषा के साथ बीएफएफ के कार्यान्वयन के रूप में देखता हूं।

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

सबसे अच्छे दोस्त हमेशा के लिए

कोई भी तकनीकी समाधान संगठनात्मक परिवर्तनों के बिना सही ढंग से काम नहीं करेगा। आपको अभी भी प्रलेखन की आवश्यकता है, गारंटी देता है कि प्रतिक्रिया प्रारूप अचानक नहीं बदलेगा, आदि।

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

इसके अलावा, रिपोर्ट की शुरुआत में मैंने जो पीठ के बारे में बात की थी वह हमेशा किसी के दुर्भावनापूर्ण कार्यों के कारण उत्पन्न नहीं होती है। यह संभव है कि फ़ेश पैरामीटर का भी कुछ अर्थ हो।

कमिट की तारीख पर ध्यान दें। यह पता चला है कि हाल ही में फेश ने अपना सत्रहवाँ जन्मदिन मनाया।

बाईं ओर कुछ अजीब पहचानकर्ता देखें? यह एसवीएन है, केवल इसलिए कि 2001 में गीता नहीं थी। सेवा के रूप में जीथब नहीं, बल्कि संस्करण नियंत्रण प्रणाली के रूप में जीथ। वह 2005 में ही दिखाई दिए।

प्रलेखन

इसलिए, हम सभी को बैक-एंड के साथ झगड़ा करने की ज़रूरत नहीं है, लेकिन सहमत होने के लिए। यह तभी किया जा सकता है जब हमें सत्य का एक ही स्रोत मिल जाए। वह स्रोत प्रलेखन होना चाहिए।

यहां सबसे महत्वपूर्ण बात यह है कि हम कार्यक्षमता पर काम करना शुरू करने से पहले प्रलेखन लिखना चाहते हैं। जैसा कि एक पूर्व-समझौता समझौते के साथ, किनारे पर हर चीज पर सहमत होना बेहतर है।

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

अकड़

एपीआई प्रलेखन के लिए एक अच्छा विकल्प स्वैगर प्रारूप है, जिसे अब ओपनएपीआई कहा जाता है। स्वैगर को YAML प्रारूप में उपयोग करना बेहतर है, क्योंकि, JSON के विपरीत, यह मनुष्यों द्वारा बेहतर पढ़ा जाता है, लेकिन मशीन के लिए कोई अंतर नहीं है।

नतीजतन, सभी समझौते स्वैगर-प्रारूप में तय किए जाते हैं और एक सामान्य भंडार में प्रकाशित होते हैं। बिक्री बैकएंड के लिए दस्तावेज़ विज़ार्ड में होना चाहिए।

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

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

Faker.js

इन उद्देश्यों के लिए Faker महान है। यह भारी मात्रा में नकली डेटा बनाने के लिए एक पुस्तकालय है। यह विभिन्न प्रकार के डेटा उत्पन्न कर सकता है: दिनांक, नाम, पते आदि, यह सब अच्छी तरह से स्थानीय है, रूसी भाषा के लिए समर्थन है।

इसी समय, फ़ेकर स्वैगर के साथ दोस्त हैं, और आप शांत रूप से मॉक सर्वर को बढ़ा सकते हैं, जो कि स्वैगर स्कीम के आधार पर, आवश्यक तरीकों से आपके लिए नकली उत्तर उत्पन्न करेगा।

मान्यता

स्वैगर को एक जेसन -स्कीम में बदला जा सकता है, और ajv जैसे टूल्स की मदद से आप सीधे रनटाइम में बैकएंड रिस्पॉन्स को वेरिफाई कर सकते हैं, अपने BFF में और विसंगतियों के मामले में टेस्टर्स, बैकएंडर्स को रिपोर्ट कर सकते हैं।

मान लीजिए कि किसी परीक्षक को साइट पर किसी प्रकार की बग मिलती है, उदाहरण के लिए, जब एक बटन पर क्लिक किया जाता है, तो कुछ भी नहीं होता है। परीक्षक क्या करता है? वह सामने के छोर पर एक टिकट लगाता है: "यह आपका बटन है, यह दबाया नहीं गया है, इसकी मरम्मत करें।"

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

निष्कर्ष

1. हम एपीआई के डिजाइन में सक्रिय रूप से शामिल हैं। हम एपीआई को डिज़ाइन करते हैं ताकि 17 वर्षों के बाद उपयोग करना सुविधाजनक हो।
2. हमें स्वैगर प्रलेखन की आवश्यकता है। कोई दस्तावेज नहीं - बैक-एंड ऑपरेशन पूरा नहीं हुआ था।
3. प्रलेखन है - हम इसे गिट में प्रकाशित करते हैं, और एपीआई में किसी भी बदलाव को फ्रंट-टीम प्रतिनिधि द्वारा अपडेट किया जाना चाहिए।
4. हम नकली सर्वर को बढ़ाते हैं और असली एपीआई की प्रतीक्षा किए बिना मोर्चे पर काम करना शुरू करते हैं।
5. हमने नोड को फ्रंटएंड के नीचे रखा और सभी उत्तरों को मान्य किया। साथ ही हमें डेटा को एग्रीगेट, नॉर्मल और कैश करने की क्षमता मिलती है।

यह भी देखें

→ किसी बड़े प्रोजेक्ट में REST जैसी दिखने वाली API का निर्माण कैसे करें
→ बैकेंड इन द फ्रंटेंड
→ BFF पैटर्न कार्यान्वयन के रूप में ग्राफकॉल का उपयोग करना