फिर से "बैकेंड" बनाएं

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



वसंत होलीजस 2018 पितर सम्मेलन में निकोलाई राईजिकोव की एक रिपोर्ट के आधार पर सामग्री तैयार की गई थी।

वर्तमान में, निकोलाई राइज़िकोव स्वास्थ्य-आईटी क्षेत्र में चिकित्सा सूचना प्रणाली बनाने के लिए काम कर रहे हैं। कार्यात्मक प्रोग्रामर FPROG के सेंट पीटर्सबर्ग समुदाय के सदस्य। ऑनलाइन क्लोजर समुदाय के सक्रिय सदस्य, HL7 FHIR चिकित्सा सूचना विनिमय मानक के सदस्य। 15 साल से प्रोग्रामिंग कर रहा है।

---

- मुझे हमेशा इस सवाल से परेशान किया गया था: ग्राफिकल यूआई को हमेशा करना मुश्किल क्यों था? इसने हमेशा कई सवाल क्यों उठाए हैं?

आज मैं यह अनुमान लगाने की कोशिश करूंगा कि क्या उपयोगकर्ता इंटरफ़ेस को प्रभावी ढंग से विकसित करना संभव है। क्या हम इसके विकास की जटिलता को कम कर सकते हैं।

दक्षता क्या है?

आइए परिभाषित करें कि दक्षता क्या है। उपयोगकर्ता इंटरफ़ेस विकसित करने के दृष्टिकोण से, दक्षता का अर्थ है:

• विकास की गति
• बग की संख्या
• खर्च की गई राशि ...

एक बहुत अच्छी परिभाषा है:

दक्षता कम के साथ अधिक कर रहा है

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

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

मेरी राय में, विकास में जटिलता मुख्य समस्या है।

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

मेरे एक दोस्त ने कहा कि यूआई प्रोग्रामिंग ऐसी "गंदी समस्या है।" आप एक बार बैठ नहीं सकते और सही विकल्प के साथ आ सकते हैं ताकि समस्या हमेशा के लिए हल हो जाए। इसके अलावा, पिछले 10 वर्षों में, विकास की जटिलता केवल बढ़ी है।

12 साल पहले ...

हमने 12 साल पहले एक चिकित्सा सूचना प्रणाली विकसित करना शुरू किया था। पहले फ्लैश के साथ। फिर हमने देखा कि जीमेल ने क्या करना शुरू किया। हमें यह पसंद आया और हम HTML के साथ जावास्क्रिप्ट पर स्विच करना चाहते थे।

वास्तव में, तब हम समय से बहुत आगे थे। हमने एक डोज लिया, और वास्तव में हमारे पास सब कुछ वैसा ही था जैसा अब हमारे पास है। ऐसे घटक थे जो डोज़ो विगेट्स पर बहुत अच्छे थे, एक मॉड्यूलर बिल्ड सिस्टम था और इसके लिए आवश्यक था कि Google क्लीजुर कंपाइलर का निर्माण और कीमा बनाया हुआ हो (आवश्यकताएँJJS और CommonJS तब भी गंध नहीं करते थे)।

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

रेल रास्ता + jQuery

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

हमारा बैकेंड तब रूबी ऑन रेल्स में लिखा गया था। हालाँकि रूबी ऑन रेल्स समुदाय बहुत बड़ा नहीं है, लेकिन उद्योग पर इसका बहुत बड़ा प्रभाव पड़ा है। आपके छोटे से भावुक समुदाय से, आपके सभी पैकेज मैनेजर, GitHub, Git, Automatic मेकअप, आदि आए हैं।

हमारे सामने चुनौती का सार यह था कि हमें दो सप्ताह में रोगी पोर्टल को लागू करना था। और हमने रेल मार्ग की कोशिश करने का फैसला किया - सर्वर पर सब कुछ करने के लिए। ऐसा क्लासिक वेब 2.0। और उन्होंने किया - उन्होंने वास्तव में दो सप्ताह में किया।

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

इस आधार पर, मुझे वास्तव में अभी भी एक चोट है: सवाल थे। जब हमने बैकएंड पर जावा से रेल तक स्विच किया, तो विकास दक्षता लगभग 10 गुना बढ़ गई। लेकिन जब हमने एसपीए पर स्कोर किया, तो विकास दक्षता भी काफी बढ़ गई। ऐसा कैसे?

वेब 2.0 क्यों प्रभावी था?

चलिए एक और प्रश्न से शुरू करते हैं: हम एक ही पृष्ठ का आवेदन क्यों करते हैं, हम उसमें विश्वास क्यों करते हैं?

वे सिर्फ हमें बताते हैं: हमें ऐसा करने की आवश्यकता है - और हम करते हैं। और बहुत कम ही इस पर सवाल उठाते हैं। क्या REST API और SPA आर्किटेक्चर सही है? क्या यह वास्तव में उस मामले के लिए उपयुक्त है जहां हम इसका उपयोग करते हैं? हमें नहीं लगता।

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

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

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

12 साल हो गए

समय के साथ, नए रुझान सामने आने लगे।

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

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

रिएक्ट दिखाई दिया, जो थोड़ी सादगी लाया (कम से कम रेंडर का सीधापन, जो कि वर्चुअल डोम के कारण हमें हर बार की तरह अनुमति देता है, जैसे कि बस redraw करने के लिए, बस समझें और सिर्फ लिखें)। लेकिन दक्षता के मामले में, ईमानदार होने के लिए, रिएक्ट ने हमें काफी पीछे धकेल दिया।

सबसे बुरी बात यह है कि 12 वर्षों में कुछ भी नहीं बदला है। हम तब भी वही काम कर रहे हैं। यह सोचने का समय है - यहां कुछ गलत है।

फ्रेड ब्रुक्स कहते हैं कि सॉफ्टवेयर विकास के साथ दो समस्याएं हैं। बेशक, वह मुख्य समस्या को जटिलता में देखता है, लेकिन वह इसे दो समूहों में विभाजित करता है:

• महत्वपूर्ण जटिलता जो कार्य से ही आती है। यह केवल दूर नहीं फेंका जा सकता है, क्योंकि यह कार्य का हिस्सा है।
• यादृच्छिक जटिलता वह है जिसे हम इस समस्या को हल करने की कोशिश में लाते हैं।

सवाल यह है कि उनके बीच क्या संतुलन है। यह ठीक है कि अब हम क्या चर्चा कर रहे हैं।

उपयोगकर्ता इंटरफ़ेस करना इतना दर्दनाक क्यों है?

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



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

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

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

OUT OF THE TAR PIT (“टार पिट की तुलना में आसान”) नामक एक उत्कृष्ट लेख है, जिसमें ब्रूक्स के बाद के लोगों ने विश्लेषण करने का निर्णय लिया कि आवेदन की जटिलता में वास्तव में क्या योगदान है। वे निराशाजनक निष्कर्ष पर पहुंचे कि एक उत्परिवर्तनीय, राज्य-प्रसार प्रणाली जटिलता का मुख्य स्रोत है। यहां विशुद्ध रूप से कॉम्बीनेटरियल रूप से समझाना संभव है - यदि आपके पास दो कोशिकाएं हैं, और उनमें से प्रत्येक में एक गेंद झूठ बोल सकती है (या झूठ नहीं बोल सकती है), कितने राज्यों में संभव है? - चार।

यदि तीन कोशिकाएँ - २ ^३ , यदि १०० कोशिकाएँ - २ ^१०० । यदि आप अपना आवेदन प्रस्तुत करते हैं और समझते हैं कि राज्य कितना धुंधला है, तो आप महसूस करते हैं कि आपके सिस्टम के संभावित राज्यों की एक अनंत संख्या है। यदि उसी समय आप किसी चीज से सीमित नहीं हैं, तो यह बहुत मुश्किल है। और मानव मस्तिष्क कमजोर है, यह पहले से ही विभिन्न अध्ययनों से साबित हो चुका है। हम एक बार में तीन तत्वों को अपने सिर में धारण करने में सक्षम हैं। कुछ सात कहते हैं, लेकिन यहां तक ​​कि मस्तिष्क एक हैक का उपयोग करता है। इसलिए, जटिलता वास्तव में हमारे लिए एक समस्या है।

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

तो समस्या इस तथ्य से आती है कि:

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

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

बैकेंड कैसे विकसित हुआ?

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

पहला महान बैकएंड आविष्कार डेटाबेस है।



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

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

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

यहां, फिर से, यह महत्वपूर्ण है कि हमने प्रतिबंध लगाए हैं और अब हम एक सरल और अधिक अभिव्यंजक भाषा के माध्यम से इस आधार पर जाते हैं। पुनर्वितरित जटिलता।

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

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

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

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

लोग इसके बारे में सोचने लगे और पीएलओ और रिवाजों को खत्म करने का विचार लेकर आए।

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

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

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

यह पूरी तरह से अनुकरण करने की कोशिश करने के लिए आवश्यक नहीं है - बनाएं।

क्लोजर = जेएस--

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

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

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

उदाहरण

हम एएसटी के माध्यम से लिस्प कैसे प्राप्त करते हैं? यहाँ एक क्लासिक अभिव्यक्ति है:

(1 + 2) - 3 

यदि हम इसके एएसटी को लिखने की कोशिश करते हैं, उदाहरण के लिए, एक सरणी के रूप में, जहां सिर नोड का प्रकार है, और आगे क्या एक पैरामीटर है, तो हमें कुछ समान मिलेगा (हम इसे जावा स्क्रिप्ट में लिखने की कोशिश कर रहे हैं):

 ['minus', ['plus', 1, 2], 3] 

अब अतिरिक्त कोट्स को फेंक दें, हम माइनस को बदल सकते हैं - और प्लस को + साथ। लिस्प में व्हॉट्सएप वाले कॉमा को बाहर फेंक दें। हम एक ही एएसटी प्राप्त करेंगे:

 (- (+ 1 2) 3) 

और लिस्प में, हम सभी इस तरह लिखते हैं। हम जाँच सकते हैं - यह एक शुद्ध गणितीय कार्य है (मेरे ईमेक ब्राउज़र से जुड़े हैं; मैं वहां स्क्रिप्ट छोड़ता हूं, यह वहां की कमांड का मूल्यांकन करता है और इसे वापस ईमैक्स पर भेजता है - आप => प्रतीक के बाद मान देखते हैं):

 (- (+ 1 2) 3) => 0 

हम एक समारोह भी घोषित कर सकते हैं:

 (defn xplus [ab] (+ ab)) ((fn [xy] (* xy)) 1 2) => 2 

या एक अनाम फ़ंक्शन। शायद यह थोड़ा डरावना लग रहा है:

 (type xplus) 

उसका प्रकार एक जावास्क्रिप्ट फ़ंक्शन है:

 (type xplus) => #object[Function] 

हम इसे पैरामीटर पास करके इसे कॉल कर सकते हैं:

 (xplus 1 2) 

यही है, हम सब करते हैं एएसटी, जो तब या तो जेएस या बाईटेकोड में संकलित है, या व्याख्या की जाती है।

 (defn mymin [ab] (if (a > b) ba)) 

क्लोजर एक मेज़बान भाषा है। इसलिए, यह मूल रनटाइम से प्रिमिटिव लेता है, अर्थात, क्लोजर स्क्रिप्ट के मामले में, हमारे पास जावास्क्रिप्ट प्रकार होंगे:

 (type 1) => #object[Number] 

 (type "string") => #object[String] 

तो regexp लिखा जाता है:

 (type #"^Cl.*$") => #object[RegExp] 

हमारे जो कार्य हैं वे कार्य हैं:

 (type (fn [x] x)) => #object[Function] 

आगे हमें कुछ प्रकार के समग्र प्रकारों की आवश्यकता है।

 (def user {:name "niquola" :address {:city "SPb"} :profiles [{:type "github" :link "https://….."} {:type "twitter" :link "https://….."}] :age 37} (type user) 

इसे ऐसे पढ़ा जा सकता है जैसे कि आप जावास्क्रिप्ट में कोई ऑब्जेक्ट बना रहे हों:

 (def user {name: "niquola" … 

क्लोजर में, इसे हैशमैप कहा जाता है। यह एक कंटेनर है जिसमें मूल्य झूठ बोलते हैं। यदि वर्ग कोष्ठक का उपयोग किया जाता है - तो इसे वेक्टर कहा जाता है - यह आपकी सरणी है:

 (def user {:name "niquola" :address {:city "SPb"} :profiles [{:type "github" :link "https://….."} {:type "twitter" :link "https://….."}] :age 37} => #'intro/user (type user) 

हम हैशमैप और वैक्टर के साथ किसी भी जानकारी को रिकॉर्ड करते हैं।

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

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

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

क्लोजर में, हमारे पास जटिल समग्र प्रकारों के लिए भी मूल्य में उत्कृष्ट समानता संचालन हैं:

 (= {:a 1} {:a 1}) => true 

और यह ऑपरेशन इस तथ्य के कारण सस्ता है कि चालाक अपरिवर्तनीय संरचनाओं की तुलना केवल संदर्भ से की जा सकती है। इसलिए, लाखों चाबियों वाला एक हैशमैप भी हम एक ऑपरेशन में तुलना कर सकते हैं।

वैसे, रिएक्ट के लड़कों ने क्लोजर कार्यान्वयन की नकल की और जेएस को अपरिवर्तनीय बना दिया।

क्लोजर में भी ऑपरेशन का एक गुच्छा है, उदाहरण के लिए, हैशमैप में एक नेस्टेड पथ से कुछ प्राप्त करना:

 (get-in user [:address :city]) 

नेश्मत में नेस्टेड पथ के साथ कुछ रखो:

 (assoc-in user [:address :city] "LA") => {:name "niquola", :address {:city "LA"}, :profiles [{:type "github", :link "https://….."} {:type "twitter", :link "https://….."}], :age 37} 

कुछ मान अपडेट करें:

 (update-in user [:profiles 0 :link] (fn [old] (str old "+++++"))) 

केवल एक विशिष्ट कुंजी चुनें:

 (select-keys user [:name :address]) 

वेक्टर के साथ एक ही बात:

 (def clojurists [{:name "Rich"} {:name "Micael"}]) (first clojurists) (second clojurists) => {:name "Michael"} 

बेस लाइब्रेरी से सैकड़ों ऑपरेशन हैं जो आपको इन डेटा संरचनाओं पर काम करने की अनुमति देते हैं। मेजबान के साथ एक इंटरोप है। आपको इसे थोड़ा सा उपयोग करने की आवश्यकता है:

 (js/alert "Hello!") => nil </csource>         "".    location  window: <source lang="clojure"> (.-location js/window) 

जंजीरों के साथ जाने के लिए हर चीनी है:

 (.. js/window -location -href) => "http://localhost:3000/#/billing/dashboard" 

 (.. js/window -location -host) => "localhost:3000" 

मैं जेएस तारीख ले सकता हूं और उससे वर्ष वापस कर सकता हूं:

 (let [d (js/Date.)] (.getFullYear d)) => 2018 

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

 {select [:*] :from [:users] :where [:= :id "user-1"]} => {:select [:*], :from [:users], :where [:= :id "user-1"]} 

हम डेटा संरचना और टाइपसेट डेटा संरचनाओं के साथ रूटिंग भी लिखते हैं:

 {"users" {:get {:handler :users-list}} :get {:handler :welcome-page}} 

 [:div.row [:div {:on-click #(.log js/console "Hello")} "User "]] 

UI में DB

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

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



घटना (यह थोड़ा सा redux की तरह है) व्यू-ची से बाहर निकलती है, जिसे एक निश्चित नियंत्रक द्वारा पकड़ा जाता है। कंट्रोलर को हम ईवेंट-हैंडलर कहते हैं। ईवेंट-हैंडलर एक प्रभाव का उत्सर्जन करता है, जिसे डेटा संरचना द्वारा भी व्याख्या किया गया है।

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



यहाँ जोड़ा गया है कि क्या गायब है, उदाहरण के लिए, redux-s में।

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

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

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

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

आगे मैं बताऊंगा कि हमें प्रतिक्रियात्मक सदस्यता की आवश्यकता क्यों है।

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

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



यही है, बैकएंड मॉडल (ऑब्जेक्ट) से, हम एक दृश्य मॉडल प्राप्त कर सकते हैं, जिसमें किसी भी प्रतिपादन का उपयोग किए बिना, हम तार्किक मॉडल को फिर से बना सकते हैं। यदि किसी प्रकार का मेनू या कुछ समान है - यह सब दृश्य मॉडल में किया जा सकता है।

क्यों?

हम सब ऐसा क्यों कर रहे हैं?

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

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

हम परीक्षण कैसे करते हैं?

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



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

इस प्रकार, हम बैकएंड पर 80% कोड का परीक्षण कर सकते हैं, जबकि सभी बैकेंड विकास उपकरण हमारे लिए उपलब्ध हैं। जुड़नार या कुछ कारखानों का उपयोग करके, हम डेटाबेस में एक विशिष्ट स्थिति को फिर से बना सकते हैं।

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

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

प्रदर्शन

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



अगला हम सदस्यता फेंक देते हैं:



आमतौर पर URL पृष्ठ को पूरी तरह से परिभाषित करता है और कुछ घटना को फेंक दिया जाता है - आप अब ऐसे और ऐसे पृष्ठ पर हैं जिसमें मापदंडों का एक सेट है। यहाँ हम एक नए वर्कफ़्लो में गए और हमारी सदस्यता वापस आ गई:



दृश्य के पीछे, वह आधार पर गया, कुछ मिला, इसे हमारे यूआई-बेस में डाल दिया। इस पर सदस्यता ने काम किया और इसे तार्किक दृश्य मॉडल से घटा दिया।

हमने इसे इनिशियलाइज़ किया। और यहाँ हमारा तार्किक मॉडल है:



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

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



यदि वह यात्रा के लिए पहले ही भुगतान कर चुका है, तो वह इसे यूजर इंटरफेस में देखेगा:



परीक्षण चलाएं, CI पर सेट करें। बैकएंड और फ्रंटेंड के बीच सिंक की गारंटी परीक्षणों द्वारा दी जाएगी, और ईमानदारी से नहीं।

बैक टू बैक?

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

इस तरह के परीक्षणों की मदद से, हम भ्रम को कम से कम देव-समय में विकसित कर सकते हैं - विकास के समय - कि हम, वेब 2.0 के पुराने दिनों में, एक रनटाइम में सर्वर पर बैठे हैं और सब कुछ आरामदायक है।

एक और पागल विचार आया (इसे अभी तक लागू नहीं किया गया है)। इस हिस्से को बैकएंड पर कम क्यों नहीं किया? अब वितरित आवेदन से पूरी तरह से दूर क्यों नहीं? इस सदस्यता और हमारे दृश्य मॉडल को बैकएंड पर उत्पन्न होने दें? वहां आधार उपलब्ध है, सब कुछ समकालिक है। सब कुछ सरल और स्पष्ट है।

इसमें जो पहला प्लस मैं देख रहा हूं, वह यह है कि एक जगह पर हमारा नियंत्रण होगा। हम अपने वितरित एप्लिकेशन की तुलना में अभी सब कुछ सरल करते हैं। परीक्षण सरल हो जाते हैं, दोहरे सत्यापन गायब हो जाते हैं। इंटरैक्टिव मल्टी-यूज़र सिस्टम की फैशनेबल दुनिया खुल जाती है (यदि दो उपयोगकर्ता एक ही रूप में जाते हैं, तो हम उन्हें इसके बारे में बताते हैं; वे एक ही समय में इसे संपादित कर सकते हैं)।

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

दूसरी ओर, यह एक चुनौती पैदा करता है। हमें एक स्टेटफुल सर्वर रखना होगा, जिस पर ये सत्र रहते हैं। यदि हमारे पास कई ऐप सर्वर हैं, तो किसी तरह लोड को संतुलित करना या सत्र को दोहराने के लिए आवश्यक होगा। हालांकि, एक संदेह है कि यह समस्या हमें मिलने वाले प्लसस की संख्या से कम है।

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

यदि आपको रिपोर्ट पसंद आई है, तो ध्यान दें: 24-25 नवंबर को मॉस्को में एक नया होलीजेएस आयोजित किया जाएगा, और वहां कई दिलचस्प चीजें भी होंगी। कार्यक्रम के बारे में पहले से ही ज्ञात जानकारी साइट पर है , और टिकट वहां खरीदे जा सकते हैं।