फ्रंट-एंड डेवलपर हैबर के लॉग: रिफलेक्टर और रिफ्लेक्स

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

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

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

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

हमने कार्य निर्धारित किया

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

मेरी मुख्य चिंता संसाधन दक्षता थी और जिसे एक सहज इंटरफ़ेस कहा जाता है। "होम-वर्क-होम" मार्ग पर हर दिन, मैंने अपने पुराने टेलीफोन को धारा में 20 शीर्षकों को प्रदर्शित करने की सख्त कोशिश करते देखा। यह कुछ इस तरह देखा गया:

_{रिफैक्टरिंग से पहले मोबाइल हैबर इंटरफ़ेस}

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

_{पुराने SSR-CSR सर्किट। प्राधिकरण सी 3 और सी 4 के चरणों में ही संभव है, जब नोड जेएस एचटीएमएल उत्पन्न करने में व्यस्त नहीं है और एपीआई अनुरोधों को प्रॉक्सी कर सकता है।}

उस समय की हमारी वास्तुकला को हबर के उपयोगकर्ताओं में से एक द्वारा बहुत सटीक रूप से वर्णित किया गया था:

मोबाइल संस्करण बकवास है। मैं जैसा बोलता हूं वैसा ही होता है। सीएसआर के साथ एसएसआर का एक भयानक संयोजन।

हमें इसे स्वीकार करना पड़ा, हालांकि दुखद यह हो सकता है।

मैंने विकल्पों का पता लगाया, "अब यह बुरा है, नियम बनाओ" के स्तर पर एक विवरण के साथ खुद को "जीरा" में टिकट सेट करें और विस्तृत स्ट्रोक के साथ मैंने कार्य को विघटित कर दिया:

• डेटा का पुन: उपयोग करें
• रिड्रेस की संख्या कम करें,
• डुप्लिकेट अनुरोधों को बाहर करें
• लोडिंग प्रक्रिया को और अधिक स्पष्ट करें।

डेटा का पुन: उपयोग करें

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

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

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

समस्याओं में से एक जो JSON के परिपत्र संरचनाओं को परिवर्तित करने में असमर्थता थी; बस उनके फ्लैट एनालॉग्स के साथ ऐसी संरचनाओं को बदलकर हल किया गया था।

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

रिड्रेस कम करें

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

समस्या के केवल दो समाधान थे:

• चौराहे के अनुरोधों के लिए प्राधिकरण डेटा को बंद करने के लिए;
• स्प्लिट नोड जेएस दो अलग-अलग उदाहरणों में परतों।

पहले समाधान के लिए सर्वर पर वैश्विक चर के उपयोग की आवश्यकता थी, और दूसरे ने कार्य को पूरा करने के लिए आवश्यक समय को कम से कम एक महीने तक बढ़ाया।

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

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

_{रिफैक्टरिंग के पहले चरण के बाद मोबाइल हैबर इंटरफ़ेस}

अंततः, SSR-CSR आर्किटेक्चर का मोबाइल संस्करण इस चित्र की ओर ले जाता है:

_{"दो दिवसीय" एसएसआर-सीएसआर योजना। नोड जेएस एपीआई हमेशा एसिंक्रोनस I / O के लिए तैयार है और SSR फ़ंक्शन द्वारा अवरुद्ध नहीं है, क्योंकि उत्तरार्द्ध एक अलग उदाहरण में है। क्वेरी श्रृंखला # 3 की आवश्यकता नहीं है।}

डुप्लिकेट अनुरोधों को छोड़ दें

जोड़तोड़ के बाद, मिर्गी को भड़काने के लिए प्रारंभिक पृष्ठ प्रतिपादन बंद हो गया। लेकिन एसपीए मोड में हैबर के आगे उपयोग ने अभी भी घबराहट का कारण बना।

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

_{पोस्ट फीड में वापसी एक नए डेटा अनुरोध को उत्तेजित करती है}

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

 ArticlesList: [ { Article1 }, ... ], PageArticle: { ArticleFull1 }, 

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

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

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

 ArticlesList: { ROUTE_FEED: [ { Article1 }, ... ], ROUTE_ALL: [ { Article2 }, ... ], } 

लेकिन क्या होगा यदि लेख सूची कई मार्गों के बीच ओवरलैप कर सकती है, और क्या होगा यदि हम किसी पोस्ट पेज को रेंडर करने के लिए आर्टिकल ऑब्जेक्ट के डेटा का पुन: उपयोग करना चाहते हैं, इसे आर्टिकलफुल में बदल दें? इस मामले में, ऐसी संरचना का उपयोग करना अधिक तर्कसंगत होगा:

 ArticlesIds: { ROUTE_FEED: [ '1', ... ], ROUTE_ALL: [ '1', '2', ... ], }, ArticlesList: { '1': { Article1 }, '2': { Article2 }, ... } 

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

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

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

डाउनलोड को अधिक मनोरंजक बना रहा है

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


_Habraloading

Refleksiruem

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

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

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