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

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

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

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

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

आइए कार्य निर्धारित करें

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

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

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

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

पुरानी एसएसआर-सीएसआर योजना। प्राधिकरण केवल चरण C3 और C4 पर संभव है, जब नोड JS HTML उत्पन्न करने में व्यस्त नहीं होता है और एपीआई के लिए प्रॉक्सी अनुरोध कर सकता है।

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

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

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

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

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

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

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

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

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

जो समस्याएँ उत्पन्न हुई हैं उनमें से एक चक्रीय संरचनाओं को JSON में परिवर्तित करने में असमर्थता है (वृत्तीय संदर्भ); ऐसी संरचनाओं को उनके फ्लैट समकक्षों के साथ प्रतिस्थापित करके हल किया गया था।

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

पुनर्निर्धारण को न्यूनतम करना

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

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

• क्रॉस-सर्वर अनुरोधों में प्राधिकरण डेटा संलग्न करें;
• नोड JS परतों को दो अलग-अलग उदाहरणों में विभाजित करें।

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

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

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

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

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

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

डुप्लिकेट अनुरोधों को ख़त्म करना

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

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

पोस्ट फ़ीड पर लौटने से एक नया डेटा अनुरोध उत्पन्न होता है

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

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

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

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

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

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

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

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

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

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

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

डाउनलोडिंग को और अधिक मनोरंजक बनाना

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

हैब्रालोडिंग

दर्शाते

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

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

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

स्रोत: www.habr.com