Microservices: अनुबंध का अनुपालन कैसे करें

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



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

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

प्रागितिहास

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

यदि पहले एपीआई महत्वपूर्ण था, तो अब यह उत्पाद का एक महत्वपूर्ण घटक बन गया है। और यह एपीआई प्रदान करता है कि प्रक्रियाओं परिपक्व हो गया है।

प्रमुख मुद्दे

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

1. विवरण पुराना है

प्रोग्रामर Vasya को कंपोनेंट A विकसित करने दें, जो कंपोनेंट B के API का उपयोग करता है। उत्तरार्द्ध में एक एनोटेशन है, लेकिन यह अमान्य है। वास्या को किसी और के कोड में क्रॉल करना पड़ता है, लोगों की तलाश करें, सवाल पूछें। समय सीमा समाप्त हो रही है, और उनके प्रबंधक कोल्या को समय सीमा के हस्तांतरण से निपटना चाहिए।

2. एपीआई संगत नहीं है

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

3. एपीआई दस्तावेज नहीं

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

4. एपीआई पुराने संस्करण के साथ संगत नहीं है।

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

उपचार के तरीके

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

दर्द 1. एनोटेशन कार्यान्वयन के अनुरूप नहीं है

एनोटेशन सेवा की वर्तमान स्थिति से भिन्न हो सकती है, न केवल इसलिए कि यह "डार्क पास्ट" का एपीआई है, जिसे पहुँचा नहीं जा सकता है। यह एक उज्ज्वल भविष्य का एपीआई भी हो सकता है जो अभी तक नहीं आया है।

इन स्थितियों का कारण यह समझने की कमी है कि एनोटेशन की आवश्यकता क्यों है। आर्किटेक्ट्स की ओर से आतंक के बिना, डेवलपर्स एनोटेशन को एक आंतरिक सहायक उपकरण मानते हैं और इसका मतलब यह नहीं है कि बाहर का कोई व्यक्ति इसका उपयोग करेगा।

आप इस दर्द को ठीक कर सकते हैं:

• वास्तुकला की समीक्षा। सभी आकारों की कंपनियों के लिए एक बहुत ही उपयोगी चीज, जिसमें कम से कम एक प्रोग्रामर है जो "इसे सही तरीके से करना जानता है"। सेवा बदलते समय, आर्किटेक्ट या प्रभारी व्यक्ति को एनोटेशन की स्थिति की निगरानी करनी चाहिए और प्रोग्रामरों को याद दिलाना चाहिए कि यह न केवल सेवा को अपडेट करना आवश्यक है, बल्कि इसका विवरण भी है। दुष्प्रभाव - वास्तुकार के चेहरे में एक अड़चन
• कोड पीढ़ी एनोटेशन से। यह तथाकथित एपीआई-पहला दृष्टिकोण है। तात्पर्य यह है कि आप शुरू में एनोटेशन करते हैं, फिर प्राथमिक कोड उत्पन्न करते हैं (इसके लिए पर्याप्त उपकरण हैं, उदाहरण के लिए [go-swagger] (https://github.com/go-swagger/go-swagger), और फिर व्यवसाय- सेवा भरें तर्क। यह व्यवस्था विसंगतियों से बचाती है। यह तब अच्छी तरह से काम करता है जब सेवा द्वारा हल किए गए कार्यों का क्षेत्र स्पष्ट रूप से चित्रित किया जाता है।
• परीक्षण एनोटेशन बनाम कार्यान्वयन । ऐसा करने के लिए, हम एनोटेशन (RAML / स्वैगर) क्लाइंट से उत्पन्न करते हैं जो अनुरोधों के साथ सेवा पर बमबारी करता है। यदि उत्तर एनोटेशन के अनुरूप हैं, और सेवा स्वयं नहीं गिरती है, तो सब कुछ ठीक है।

परीक्षण एनोटेशन बनाम कार्यान्वयन
हमें परीक्षण पर ध्यान दें। ऐसी पूरी तरह से स्वचालित क्वेरी पीढ़ी एक जटिल कार्य है। एपीआई एनोटेशन से डेटा होने पर, आप अलग-अलग अनुरोध बना सकते हैं। हालाँकि, कोई भी API निर्भरता का अर्थ है, उदाहरण के लिए, GET / क्लाइंट / {cliend_id} कॉल करने से पहले, आपको यह ऑब्जेक्ट पहले बनाना होगा और फिर इसकी आईडी प्राप्त करनी होगी। कभी-कभी निर्भरताएं कम स्पष्ट होती हैं - एक वस्तु एक्स बनाने के लिए संबंधित वस्तु वाई के पहचानकर्ता को पारित करने की आवश्यकता होती है, और यह एक उप-संग्रह नहीं है। न तो RAML और न ही स्वैगर स्पष्ट निर्भरता का वर्णन करने की अनुमति देते हैं। इसलिए, कई दृष्टिकोण यहां संभव हैं:

1. एनोटेशन में डेवलपर्स से औपचारिक टिप्पणियों की अपेक्षा करें जो निर्भरता का संकेत देते हैं।
2. डेवलपर्स से अपेक्षित अनुक्रम का वर्णन करने का अनुरोध करें ( यकीमल , विशेष डीएसएलआई या एक सुंदर जीयूआई के माध्यम से अनुरोधों का वर्णन करने के लिए कुछ तरीके हैं, जैसा कि अब छोड़ दिया गया था ।
3. वास्तविक डेटा लें (उदाहरण के लिए, सभी सर्वर अनुरोधों और प्रतिक्रियाओं को लॉग करने के लिए OpenResty का उपयोग करके)
4. (लगभग) कृत्रिम बुद्धिमत्ता (जैसे रेस्लर ) का उपयोग कर एनोटेशन से निर्भरता निकालें

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



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

अनुरोधों के अनुक्रम का वर्णन करने के लिए हमारी उपयोगिता निम्नलिखित yaml का उपयोग करती है:



घुंघराले कोष्ठक वे चर घोषित करते हैं जो परीक्षण के दौरान प्रतिस्थापित किए जाते हैं। पता चर CLI पैरामीटर के रूप में पारित किया गया है, और यादृच्छिक एक मनमाना स्ट्रिंग उत्पन्न करता है। सबसे बड़ी दिलचस्पी यहां प्रतिक्रिया-दर-क्षेत्र है: इसमें एक चर होता है जिसमें सर्वर प्रतिक्रिया के साथ json लिखा जाएगा। इस प्रकार, अंतिम पंक्ति में, आप task.id का उपयोग करके बनाई गई ऑब्जेक्ट की आईडी प्राप्त कर सकते हैं।

दर्द 2. एपीआई संगत नहीं है

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

असंगति के कई उदाहरण हैं:

1. एक ही डेटा के विभिन्न स्वरूपों का उपयोग। उदाहरण के लिए, समय प्रारूप, पहचानकर्ता का प्रकार (संख्या या स्ट्रिंग UUID),
2. फ़िल्टरिंग या पृष्ठांकन के लिए अलग-अलग वाक्यविन्यास लागू करना,
3. सेवाओं के लिए विभिन्न प्राधिकरण योजनाएं। न केवल अंतर पाउडर प्रोग्रामर के दिमाग, वे उन परीक्षणों पर भी प्रतिबिंबित करते हैं जिन्हें विभिन्न योजनाओं का समर्थन करने की आवश्यकता होगी।

उपचार :

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

उदाहरण - स्थैतिक परीक्षण आइटम

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

हमारी कंपनी में, हमने दिशानिर्देश में निम्नलिखित बिंदुओं को शामिल किया है:


दिशानिर्देशों के अन्य अच्छे उदाहरण Microsoft , PayPal , Google पर देखे जा सकते हैं।

दर्द 3. एपीआई प्रलेखित नहीं

एनोटेशन का अस्तित्व एपीआई के साथ काम करने की सादगी के लिए एक आवश्यक लेकिन पर्याप्त स्थिति नहीं है। आप एक एनोटेशन लिख सकते हैं ताकि उसे अपनी पूरी क्षमता का एहसास न हो। ऐसा तब होता है जब:

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

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

उपचार:

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

Acronis में, एसडीके क्लाइंट और ट्राइ-इट सेक्शन के साथ एनोटेशन के आधार पर एक एनोटेशन एपीआई उत्पन्न होता है। कोड के नमूने और उपयोग के मामलों के विवरण के साथ, वे प्रोग्रामर के लिए आवश्यक और सुविधाजनक ऐड-ऑन की एक पूरी श्रृंखला बनाते हैं। हमारा पोर्टल developer.acronis.com पर देखें



मुझे कहना होगा कि एपीआई संदर्भ उत्पन्न करने के लिए उपकरणों का एक पूरा वर्ग है। कुछ कंपनियां खुद अपनी जरूरतों के लिए ऐसे उपकरण विकसित करती हैं। अन्य लोग स्वैगर संपादक की तरह काफी सरल और मुफ्त टूल का उपयोग करते हैं। एक लंबे (वास्तव में लंबे) शोध के बाद, हम Acronis Apimatic.io पर बस गए, इसे REST यूनाइटेड, Mulesoft AnyPoint और अन्य के लिए प्राथमिकता दी।

दर्द 4. पिछड़ी हुई अनुकूलता के मुद्दे

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

ऐसी घटनाएँ भी क्यों हो सकती हैं? मुख्य कारण एपीआई जीवन चक्र की गलतफहमी है, जो अप्रत्याशित ईओएल (जीवन का अंत) नीतियों में, और अस्पष्ट एपीआई रिलीज में, एकीकरण को तोड़ने में प्रकट हो सकता है।

उपचार:

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

प्रबंधन बदलें

एपीआई जीवन चक्र से जुड़ी गतिविधियों का वर्णन करने वाले नियमों को परिवर्तन प्रबंधन नीतियां कहा जाता है।



यदि आपके पास "वर्तमान" और "नए" एनोटेशन के दो संस्करण हैं, तो बैकवर्ड संगतता जांच तकनीकी रूप से सरल है: बस एनोटेशन दोनों को पार्स करें और जांचें कि क्या आवश्यक फ़ील्ड मौजूद हैं



हमने एक विशेष उपकरण लिखा है जो आपको CI में पिछड़े संगतता के लिए महत्वपूर्ण सभी मापदंडों की तुलना करने की अनुमति देता है। उदाहरण के लिए, GET / स्वास्थ्य परीक्षण अनुरोध में प्रतिक्रिया निकाय को बदलते समय, निम्न के जैसा संदेश प्रदर्शित किया जाएगा:

निष्कर्ष

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


खराब एपीआई के लिए दवाएं।

हम किसी भी विचार, रेटिंग, टिप्पणी, राय और प्रश्नों के लिए खुश होंगे!