🙍🏽 🤧 👦🏽 विकास में DevOps: वेब एप्लिकेशन कोड स्वचालन ⚙️ 🎂 👨🏾‍⚖️

शुभ दिन, प्रिय हबरज़ितेली!

आज DevOps सफलता की लहर पर है। ऑटोमेशन के लिए समर्पित लगभग किसी भी सम्मेलन में, आप स्पीकर से यह कहते हुए सुन सकते हैं कि "हमने यहां और वहां देवओप्स को लागू किया, यह लागू किया और यह, परियोजनाओं, आदि का संचालन करना बहुत आसान हो गया"। और यह सराहनीय है। लेकिन, एक नियम के रूप में, कई कंपनियों में DevOps का कार्यान्वयन IT संचालन के स्वचालन के चरण में समाप्त होता है, और बहुत कम लोग ही DevOps को सीधे विकास प्रक्रिया में लागू करने की बात करते हैं।

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

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

मुझे उम्मीद है कि यह सामग्री आपके लिए रोचक और उपयोगी होगी।

खैर, चलो शुरू हो जाओ!

प्रागितिहास

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

पुरानी वास्तुकला पर नई सुविधाओं को जोड़ने की प्रक्रिया

पुरानी वास्तुकला पर नई सुविधाओं को जोड़ने की प्रक्रिया

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

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

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

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

क्या यह बहुत जटिल है?

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

कोड दोहराव से कैसे बचें? समाधान के लिए खोजें

हम आश्चर्यचकित होने लगे कि हम नई सुविधाओं को पेश करने की प्रक्रिया को कैसे अनुकूलित कर सकते हैं।

हमने अपने आप से सवाल पूछा: "क्या हम तुरंत बैक-एंड में इसकी संरचना में किसी भी बदलाव के बाद, फ्रंट-एंड में मॉडल के प्रतिनिधित्व में डुप्लिकेट परिवर्तन से बच सकते हैं?"

हमने सोचा और जवाब दिया: "नहीं, हम नहीं कर सकते।"

फिर हमने खुद से एक और सवाल पूछा: "ठीक है, फिर कोड के ऐसे दोहराव का कारण क्या है?"

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

और फिर हमें यह विचार मिला: क्या होगा यदि हम एप्लिकेशन आर्किटेक्चर का निर्माण इस तरह से करें:

एपीआई से प्राप्त फ्रंट-एंड न केवल मॉडल डेटा, बल्कि इन मॉडलों की संरचना भी;
मॉडल की संरचना के आधार पर गतिशील रूप से फ्रंट-एंड का गठन;
एपीआई की संरचना में कोई भी परिवर्तन स्वचालित रूप से फ्रंट-एंड पर प्रदर्शित किया गया था।

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

नई वास्तुकला की बहुमुखी प्रतिभा

और फिर, हमने थोड़ा और व्यापक रूप से सोचने का फैसला किया: क्या नई वास्तुकला केवल हमारे वर्तमान अनुप्रयोग के लिए उपयुक्त है, या हम इसे कहीं और उपयोग कर सकते हैं?

कई वेब लिंक के लिए सामान्य सुविधाएँ

दरअसल, एक तरह से या किसी अन्य, लगभग सभी अनुप्रयोगों में एक समान कार्यक्षमता का हिस्सा होता है:

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

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

इस प्रकार, एक लंबी चर्चा के दौरान, हमें VSTUtils बनाने का विचार आया - जो कि एक ढांचा होगा:

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

दोस्तों बैक-एंड और फ्रंट-एंड कैसे बनाएं?

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

इस समस्या के समाधान की तलाश में, हमारी नज़र OpenAPI विनिर्देश पर पड़ी , जो कि मॉडल और उनके बीच संबंधों के विवरण के आधार पर, एक विशाल JSON उत्पन्न करता है जिसमें यह सभी जानकारी होती है।

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

और कुछ समय बाद हमने उसे पढ़ाया।

संस्करण 1.0 - इससे क्या हुआ

पहले संस्करणों के VSTUtils ढांचे के आर्किटेक्चर में 3 सशर्त भाग शामिल थे और कुछ इस तरह दिखते थे:

पिछला अंत:
- Django और पायथन सभी मॉडल से संबंधित तर्क हैं। आधार Django मॉडल के आधार पर, हमने कोर VSTUtils मॉडल के कई वर्ग बनाए हैं। सभी क्रियाएं जो ये मॉडल प्रदर्शन कर सकते हैं, जिन्हें हमने पायथन का उपयोग करके कार्यान्वित किया है;
- Django REST फ्रेमवर्क - REST API पीढ़ी। मॉडल के विवरण के आधार पर, एक आरईएसटी एपीआई का गठन किया जाता है, जिसके लिए सर्वर और क्लाइंट संवाद करते हैं;

बैक-एंड और फ्रंट-एंड के बीच इंटरलेयर:

OpenAPI - एपीआई संरचना के विवरण के साथ JSON पीढ़ी। बैक-एंड पर सभी मॉडल वर्णित किए जाने के बाद, उनके लिए विचार बनाए जाते हैं। प्रत्येक दृश्य को जोड़ने से परिणामी JSON में आवश्यक जानकारी का परिचय होता है:

JSON उदाहरण - OpenAPI स्कीमा

{ // ,     (, ), //   -  , //  -     . definitions: { //    Hook. Hook: { // ,     (, ), //   -   , //  -       (,    ..). properties: { id: { title: "Id", type: "integer", readOnly: true, }, name: { title: "Name", type: "string", minLength:1, maxLength: 512, }, type: { title: "Type", type: "string", enum: ["HTTP","SCRIPT"], }, when: { title: "When", type: "string", enum: ["on_object_add","on_object_upd","on_object_del"], }, enable: { title:"Enable", type:"boolean", }, recipients: { title: "Recipients", type: "string", minLength: 1, } }, // ,     ,    . required: ["type","recipients"], } }, // ,     (, ), //   -   ( URL), //  -     . paths: { //      '/hook/'. '/hook/': { //    get    /hook/. //  ,       Hook. get: { operationId: "hook_list", description: "Return all hooks.", // ,       ,     . parameters: [ { name: "id", in: "query", description: "A unique integer value (or comma separated list) identifying this instance.", required: false, type: "string", }, { name: "name", in: "query", description: "A name string value (or comma separated list) of instance.", required: false, type: "string", }, { name: "type", in: "query", description: "Instance type.", required: false, type: "string", }, ], // ,     (, ), //   -   ; //  -   . responses: { 200: { description: "Action accepted.", schema: { properties: { results: { type: "array", items: { //   ,       . $ref: "#/definitions/Hook", }, }, }, }, }, 400: { description: "Validation error or some data error.", schema: { $ref: "#/definitions/Error", }, }, 401: { // ... }, 403: { // ... }, 404: { // ... }, }, tags: ["hook"], }, //    post    /hook/. //  ,       Hook. post: { operationId: "hook_add", description: "Create a new hook.", parameters: [ { name: "data", in: "body", required: true, schema: { $ref: "#/definitions/Hook", }, }, ], responses: { 201: { description: "Action accepted.", schema: { $ref: "#/definitions/Hook", }, }, 400: { description: "Validation error or some data error.", schema: { $ref: "#/definitions/Error", }, }, 401: { // ... }, 403: { // ... }, 404: { // ... }, }, tags: ["hook"], }, } } }

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

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

नए आर्किटेक्चर पर एप्लिकेशन में एंबेडिंग की विशेषताएं - यह कैसे काम करता है

कस्टम हुक जोड़ने का कार्य याद रखें? यहाँ हम इसे VSTUtils के आधार पर एक आवेदन में कैसे लागू करेंगे:

नई वास्तुकला में नई सुविधाओं को जोड़ने की प्रक्रिया

अब VSTUtils के लिए धन्यवाद हमें खरोंच से कुछ भी लिखने की आवश्यकता नहीं है। यहाँ हम कस्टम हुक बनाने की क्षमता जोड़ने के लिए क्या करते हैं:

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

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

संस्करण 1.0 - हमारे दिलों की मांग बदल जाती है

लेकिन, जैसा कि आप जानते हैं, पूर्णता की कोई सीमा नहीं है, और VSTUtils कोई अपवाद नहीं था।

इस तथ्य के बावजूद कि हम फ्रंट-एंड के गठन को स्वचालित करने में सक्षम थे, परिणाम प्रत्यक्ष समाधान नहीं था जो हम मूल रूप से चाहते थे।

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

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

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

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

Refactoring - JS फ्रेमवर्क का विकल्प

सबसे लोकप्रिय जेएस फ्रेमवर्क में: कोणीय, प्रतिक्रिया, Vue, हमारी पसंद Vue पर गिरी क्योंकि:

Vue का कोड आधार, React और Angular से कम वजन का होता है;

Gzipped फ्रेमवर्क आकार तुलना चार्ट

ढांचा	आकार, केबी
कोणीय 2	111
कोणीय 2 + आरएक्स	143
कोणीय 1.4.5	51
प्रतिक्रिया 0.14.5 + प्रतिक्रिया डोम	40
प्रतिक्रिया 0.14.5 + प्रतिक्रिया डोम + Redux	42
प्रतिक्रिया 15.3.0 + प्रतिक्रिया डोम	43
वि ० २.४.२	21

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

संस्करण 2.0 - फ्रंट-एंड रिफैक्टिंग का परिणाम

VSTUtils के फ्रंट-एंड के वैश्विक रीफैक्टरिंग की प्रक्रिया में लगभग 4 महीने का समय लगा और इसी के साथ हमारा समापन हुआ:

नया फ्रॉन-और VSTUtils आर्किटेक्चर

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

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

मॉडल वर्ग और उसके वंश की वस्तुएं Django मॉडल के सर्वर-साइड अमूर्त के अनुरूप वस्तुएं हैं। इस प्रकार की वस्तुओं में मॉडल (मॉडल का नाम, मॉडल फ़ील्ड, आदि) की संरचना पर डेटा होता है;
QuerySet वर्ग और उसके वंश की वस्तुएं सर्वर-साइड Django QuerySets अमूर्त के अनुरूप वस्तुएं हैं। इस प्रकार की वस्तुओं में वे विधियाँ होती हैं जो आपको एपीआई अनुरोधों को जोड़ने (जोड़ने, संशोधित करने, प्राप्त करने, मॉडल वस्तुओं का डेटा हटाने) की अनुमति देती हैं;
व्यू क्लास की वस्तुएं - ऐसी वस्तुएँ जो किसी विशेष पृष्ठ पर मॉडल का प्रतिनिधित्व करने के तरीके के बारे में जानकारी संग्रहीत करती हैं, जो पेज को "रेंडर" करने के लिए उपयोग करती हैं, जो इस पृष्ठ के मॉडल के अन्य प्रतिनिधित्व से लिंक कर सकते हैं, आदि।

रेंडरिंग और राउटिंग के लिए जिम्मेदार यूनिट भी काफी बदल गई है। हमने Vue.js. के पक्ष में स्व-लिखित JS SPA लाइब्रेरीज़ को छोड़ दिया हमने अपने स्वयं के Vue घटक विकसित किए हैं जो हमारे वेब एप्लिकेशन के सभी पृष्ठ बनाते हैं। व्यू-राउटर लाइब्रेरी के उपयोग से विचारों के बीच रूटिंग होती है, और हम एप्लीकेशन स्टेट के रिएक्टिव स्टोरेज के रूप में vuex का उपयोग करते हैं।

मैं यह भी ध्यान देना चाहूंगा कि सामने के छोर पर मॉडल, क्वेरसेट और व्यू कक्षाओं का कार्यान्वयन रेंडरिंग और रूटिंग के साधनों पर निर्भर नहीं करता है, अर्थात यदि हम अचानक Vue से किसी अन्य फ्रेमवर्क पर स्विच करना चाहते हैं, उदाहरण के लिए, प्रतिक्रिया या कुछ नया, फिर हमें केवल नए ढांचे के घटकों के लिए Vue घटकों को फिर से लिखना होगा, राउटर, रिपॉजिटरी को फिर से लिखना होगा, और वह सब - VSTUtils फ्रेमवर्क फिर से काम करेगा। मॉडल, क्वेरीसेट और व्यू क्लासेस का कार्यान्वयन समान रहेगा, क्योंकि यह Vue.js. पर निर्भर नहीं करता है हमारा मानना है कि भविष्य में संभावित बदलावों के लिए यह एक बहुत अच्छी मदद है।

संक्षेप में देना

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

वेब एप्लिकेशन की वास्तुकला को औपचारिक बनाने से हमें जो लाभ प्राप्त हुए हैं:

VSTUtils के आधार पर चलने वाले अनुप्रयोगों की रिलीज़ अक्सर 2 गुना अधिक होने लगी। यह इस तथ्य के कारण है कि अब एक नई सुविधा शुरू करने के लिए, अक्सर, हमें केवल बैक-एंड पर कोड जोड़ने की आवश्यकता होती है, फ्रंट-एंड स्वचालित रूप से उत्पन्न होगा - यह समय बचाता है;
बुनियादी कार्यक्षमता को अद्यतन करने में सरलीकृत। चूंकि अब सभी बुनियादी कार्यक्षमता एक फ्रेमवर्क में इकट्ठी की गई हैं, इसलिए कुछ महत्वपूर्ण निर्भरताओं को अपडेट करने या बुनियादी कार्यक्षमता में सुधार करने के लिए, हमें केवल एक ही स्थान पर सुधार करने की आवश्यकता है - VSTUtils कोड बेस में। बाल परियोजनाओं में VSTUtils के संस्करण को अपडेट करते समय, सभी नवाचारों को स्वचालित रूप से उठाया जाएगा;
नए कर्मचारियों को ढूंढना आसान हो गया है। सहमत हूं, एक औपचारिक प्रौद्योगिकी स्टैक (Django, Vue) के लिए एक डेवलपर को ढूंढना बहुत आसान है जो किसी ऐसे व्यक्ति की तलाश में है जो एक अज्ञात रिकॉर्डर के साथ काम करने के लिए सहमत है। उन डेवलपर्स के लिए खोज परिणाम जिन्होंने अपने सीवी (सभी क्षेत्रों में हेडहंटर पर Django या Vue का उल्लेख किया है):
- Django - 3,134 आवेदकों के लिए 3,454 रिज्यूमे मिला;
- 3,747 नौकरी चाहने वालों के लिए Vue - 4,092 रिज्यूमे मिला।

वेब एप्लिकेशन की वास्तुकला के इस तरह के औपचारिककरण के नुकसानों में निम्नलिखित शामिल हैं:

ओपनएपीआई योजना के पार्सिंग के कारण, क्लाइंट पर एप्लिकेशन का प्रारंभ पहले की तुलना में थोड़ा अधिक समय लेता है (लगभग 20-30 मिलीसेकंड लंबा);
महत्वहीन खोज अनुक्रमण। तथ्य यह है कि फिलहाल हम VSTUtils के ढांचे में सर्वर रेंडरिंग का उपयोग नहीं कर रहे हैं, और एप्लिकेशन की सभी सामग्री क्लाइंट पर पहले से ही अंतिम रूप में बनाई गई है। लेकिन हमारी परियोजनाओं के लिए, अक्सर उच्च खोज परिणामों की आवश्यकता नहीं होती है और हमारे लिए यह इतना महत्वपूर्ण नहीं है।

इस पर मेरी कहानी समाप्त होती है, आपके ध्यान के लिए धन्यवाद!

विकास में DevOps: वेब एप्लिकेशन कोड स्वचालन