आपसी समझ को बनाए रखते हुए फ्रंटएंड और बैकेंड को कैसे अलग किया जाए

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

कुछ साल पहले, मैंने एक वैज्ञानिक लेख में पढ़ा था कि पूर्ण प्रशिक्षण के लिए अधिक से अधिक समय की आवश्यकता होती है, और निकट भविष्य में ज्ञान प्राप्त करने में अस्सी साल लगेंगे। जाहिर है, आईटी में यह भविष्य पहले ही आ चुका है।

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

प्रागितिहास

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

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

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

आगे और पीछे

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

यहां सब कुछ स्पष्ट प्रतीत होता है: हम फ्रंट-एंड प्रोग्रामर की भर्ती कर रहे हैं, वे उपयोगकर्ता इंटरफ़ेस के लिए जिम्मेदार होंगे, और बैकएंड अंततः व्यावसायिक तर्क, डेटा मॉडल और अन्य इंजन हुड पर ध्यान केंद्रित करने में सक्षम होंगे। एक ही समय में, बैकएंड, फ्रंटएंड, परीक्षक और डिजाइनर एक टीम में रहेंगे (क्योंकि वे एक सामान्य उत्पाद बनाते हैं, वे बस इसके विभिन्न हिस्सों पर ध्यान केंद्रित करते हैं)। एक टीम में होने का मतलब है एक सूचनात्मक और, अधिमानतः, क्षेत्रीय स्थान; एक साथ नई सुविधाओं पर चर्चा करें और तैयार लोगों को अलग करें; एक बड़े काम पर समन्वय कार्य।

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

"हम एक परियोजना में सब कुछ करेंगे, यह अधिक सुविधाजनक होगा", उन्होंने कहा ...

आर्किटेक्चर

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

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

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

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

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

जिम्मेदारी के क्षेत्रों को विभाजित करके स्थिरता में वृद्धि।

संचार

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

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

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

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

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

एपीआई

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

नए उत्पाद और डिजाइन विचारों को लागू करने में दैनिक कठिनाइयों से नई एपीआई के लिए लक्ष्य सामने आए हैं। हमें जरूरत थी:

1. सिस्टम घटकों की कमजोर कनेक्टिविटी ताकि बैकेंड और फ्रंटेंड को समानांतर में विकसित किया जा सके।
2. उच्च स्केलेबिलिटी ताकि नई एपीआई इमारत की कार्यक्षमता में हस्तक्षेप न करे।
3. स्थिरता और निरंतरता।

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

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

एक अन्य आम समाधान ग्राफकॉल है। यह भी सही नहीं है, लेकिन REST के विपरीत, ग्राफकलाइन एपीआई केवल एक वर्णनात्मक मॉडल नहीं है, बल्कि वास्तविक नियम है।

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

अगला, आपको यह तय करना था कि बैकएंड एपीआई का उपयोग कैसे किया जाए। सबसे पहले हमने REST API बढ़ाने की दिशा में देखा, फिर हमने N ++ के लिए C ++ में ऐड-ऑन का उपयोग करने का प्रयास किया। नतीजतन, हमने महसूस किया कि यह सब हमारे अनुरूप नहीं था, और बैकएंड के लिए एक विस्तृत विश्लेषण के बाद , हमने जीआरपीसी सेवाओं के आधार पर एक एपीआई चुना ।

C ++, TypeScript, GraphQL और gRPC का उपयोग करने में प्राप्त अनुभव को एक साथ इकट्ठा करने के बाद, हमें एक एप्लिकेशन आर्किटेक्चर मिला है जो एक सिंगल सॉफ़्टवेयर उत्पाद बनाने के लिए बैकएंड और फ्रंटेंड के लचीले विकास की अनुमति देता है।

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

वास्तुकला में बदलाव के बाद काम की सामान्य योजना

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

परिणाम

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

1. डिस्प्ले के लिए फ्रंटेंड जिम्मेदार है, और बैकेंड डेटा के लिए जिम्मेदार है।
2. सामने के छोर पर, डेटा को क्वेरी और प्राप्त करने के संदर्भ में लचीलापन बना रहा। इंटरफ़ेस जानता है कि आप सर्वर से क्या पूछ सकते हैं और उत्तर क्या होना चाहिए।
3. बैकएंड के पास कोड को इस विश्वास के साथ बदलने का अवसर है कि उपयोगकर्ता इंटरफ़ेस काम करना जारी रखेगा। पूरे दृश्य को फिर से करने की आवश्यकता के बिना माइक्रोसॉर्स्क आर्किटेक्चर पर स्विच करना संभव हो गया।
4. बैकएंड अभी तैयार नहीं होने पर आप फ्रंटेंड के लिए मॉक डेटा का उपयोग कर सकते हैं।
5. सहयोग योजनाओं के निर्माण ने सहभागिता की समस्याओं को समाप्त कर दिया जब टीमों ने एक ही कार्य को अलग तरह से समझा। डेटा स्वरूपों को बदलने के लिए पुनरावृत्तियों की संख्या कम कर दी गई है: हम "सात बार मापें, एक बार काटें" के सिद्धांत पर कार्य करते हैं।
6. अब आप समानांतर में स्प्रिंट कार्य की योजना बना सकते हैं।
7. व्यक्तिगत माइक्रोसर्विसेज को लागू करने के लिए, अब आप उन डेवलपर्स को भर्ती कर सकते हैं जो C ++ से परिचित नहीं हैं।

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

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

यहाँ मैंने एक उत्पाद पर टीम और टीम के काम के मुद्दों पर छुआछूत की, एपीआई तकनीक (REST बनाम ग्राफक्यूएल) का चुनाव, C ++ के साथ Node.js अनुप्रयोगों का संबंध, आदि। इन विषयों में से प्रत्येक एक अलग लेख खींचता है, और यदि आप रुचि रखते हैं, तो हम उन्हें लिखेंगे।