हम विज्ञापन प्रणालियों के लिए UI कैसे बनाते हैं

ज्वाइन करने के बजाय

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

यह सब कैसे शुरू हुआ

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

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

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

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

विन्यास और शब्दावली

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

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



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

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

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



परियोजना की JSON कॉन्फ़िगरेशन (चित्र देखें) में समान अवधारणाएं पाई जा सकती हैं।

डेटाबेस संरचना

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

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



चित्र में उदाहरण पर विचार करें: यहां एक अतिरिक्त क्षेत्र के साथ रचनात्मक के लिए डेटाबेस संरचना का वर्णन किया गया है - `image_url`। केवल इसकी आईडी रचनात्मक तालिका में संग्रहीत की जाती है, और image_url को एक अलग तालिका में संग्रहीत किया जाता है, उनके संबंध को तालिका LinkRegistry में एक और प्रविष्टि द्वारा वर्णित किया गया है। इस प्रकार, इस रचनात्मक को तीन प्रविष्टियों, प्रत्येक तालिकाओं में से एक द्वारा वर्णित किया जाएगा। तदनुसार, इस तरह के रचनात्मक को बचाने के लिए, आपको उनमें से प्रत्येक में एक प्रविष्टि बनाने की आवश्यकता है, और इसे उसी तरह से पढ़ने के लिए, 3 तालिकाओं पर जाएं। खरोंच से हर बार इस तरह के प्रसंस्करण को लिखना बहुत असुविधाजनक होगा, इसलिए हमारी लाइब्रेरी प्रोग्रामर से इन सभी विवरणों को सार करती है। डेटा के साथ काम करने के लिए, Django और DRF कोड द्वारा वर्णित मॉडल और धारावाहिक का उपयोग करते हैं। हमारी परियोजनाओं में, मॉडल और सीरीज़ में फ़ील्ड्स का सेट JSON कॉन्फ़िगरेशन द्वारा रनटाइम में निर्धारित किया जाता है, मॉडल कक्षाएं गतिशील रूप से बनाई जाती हैं (प्रकार फ़ंक्शन का उपयोग करके) और एक विशेष रजिस्टर में संग्रहीत की जाती हैं, जहां से वे आवेदन संचालन के दौरान उपलब्ध हैं। हम इन मॉडलों और धारावाहिकों के लिए विशेष आधार वर्गों का भी उपयोग करते हैं, जो गैर-मानक आधार संरचना के साथ काम करने में मदद करते हैं।

एक नई वस्तु को सहेजते समय (या किसी मौजूदा को अपडेट करने पर), फ्रंट-एंड से प्राप्त डेटा धारावाहिक में आ जाता है, जहाँ उन्हें मान्य किया जाता है - कुछ भी असामान्य नहीं है, मानक DRF तंत्र काम करता है। लेकिन बचत और अद्यतन को यहां फिर से परिभाषित किया गया है। धारावाहिक हमेशा यह जानता है कि यह किस मॉडल के साथ काम करता है, और हमारे गतिशील मॉडल के आंतरिक प्रतिनिधित्व के अनुसार, यह समझ सकता है कि अगले फ़ील्ड के डेटा को किस तालिका में रखा जाना चाहिए। हम इस जानकारी को कस्टम मॉडल फ़ील्ड्स में एन्कोड करते हैं (याद रखें कि Django में `फॉरेनकेय` का वर्णन कैसे किया जाता है - संबंधित मॉडल को फ़ील्ड के अंदर पास किया जाता है, हम ऐसा ही करते हैं)। इन विशेष क्षेत्रों में, हम डिस्क्रिप्टर तंत्र का उपयोग करके LinkRegistry में एक तीसरा बाइंडिंग रिकॉर्ड जोड़ने की आवश्यकता को भी पूरा करते हैं - कोड में आप 'रचनात्मक.image_url =' http: // foo.bar '' लिखते हैं, और ओवरराइड पद्धति में `__set__` हम रिकॉर्ड करते हैं `LinkRegistry`।
यह डेटाबेस पर लिखने पर लागू होता है। और अब पढ़ने के साथ सौदा करते हैं। एक टैंगो को एक डेटाबेस से कैसे निकाला जाता है जो कि एक Django मॉडल के उदाहरण में परिवर्तित होता है? बेस Django मॉडल में एक `from_db` विधि है, जिसे` क्वेरीसेट` में किसी क्वेरी को निष्पादित करते समय प्राप्त प्रत्येक ट्यूपल के लिए कहा जाता है। इनपुट पर, यह एक टुपल प्राप्त करता है और Django मॉडल का उदाहरण देता है। हमने अपने बेस मॉडल में इस विधि को फिर से परिभाषित किया, जहां मुख्य मॉडल (जहां केवल `आईडी` आता है) के टपल के अनुसार, हमें अन्य संबंधित तालिकाओं से डेटा मिलता है और यह पूरा सेट होने के बाद, हम मॉडल को तुरंत भेज देते हैं। बेशक, हमने अपने गैर-मानक उपयोग मामले के लिए Django प्रीफ़ेटिंग तंत्र को अनुकूलित करने का भी काम किया।

परीक्षण

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

परीक्षणों को चलाने के लिए, हम पाइस्टेस्ट का उपयोग करते हैं। बैकएंड पर, हमारे पास परीक्षण के दो बड़े वर्ग हैं: हमारे ढांचे के परीक्षण (हम इसे "कोर" भी कहते हैं) और परियोजना परीक्षण।

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

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

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

अंतभाषण

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

यह लेख मॉस्कोपिथॉनकोफ ++ 2019 में मेरी प्रस्तुति का एक विस्तारित प्रतिलेख है, इसलिए मैं वीडियो और स्लाइड के लिंक भी साझा करता हूं।