स्लैक क्लाइंट में सर्विस वर्कर्स: डाउनलोड एक्सेलेरेशन और ऑफलाइन मोड पर

सामग्री, जिसका अनुवाद आज हम प्रकाशित करते हैं, स्लैक डेस्कटॉप क्लाइंट के नए संस्करण के अनुकूलन के बारे में कहानी को समर्पित है, जिसमें से एक केंद्रीय विशेषता लोडिंग का त्वरण था।

प्रागितिहास

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

सेवा कार्यकर्ता क्या है?

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

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

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

हम सेवाकर्मियों का उपयोग कैसे करते हैं

जब कोई उपयोगकर्ता पहली बार एक नया स्लैक क्लाइंट लॉन्च करता है, तो हम संसाधनों (HTML, JavaScript, CSS, फोंट और ध्वनियों) का एक पूरा सेट डाउनलोड करते हैं और उन्हें सेवा कर्मी के कैश में रख देते हैं। इसके अलावा, हम मेमोरी में स्थित Redux स्टोर की एक कॉपी बनाते हैं और इस कॉपी को IndexedDB डेटाबेस में लिखते हैं। जब कार्यक्रम अगली बार लॉन्च किया जाता है, तो हम संबंधित कैश की उपस्थिति के लिए जांच करते हैं। यदि वे हैं, तो हम एप्लिकेशन डाउनलोड करते समय उनका उपयोग करते हैं। यदि उपयोगकर्ता इंटरनेट से जुड़ा है, तो हम एप्लिकेशन लॉन्च करने के बाद नवीनतम डेटा डाउनलोड करते हैं। यदि नहीं, तो क्लाइंट चालू रहता है।

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


गर्म और ठंडे लोडिंग के बीच का विकल्प

सेवा कार्यकर्ता जीवन चक्र

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

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

▍ईवेंट घटना

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

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

▍Event fetch

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

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

 self.addEventListener('fetch', (e) => {  if (assetManifest.includes(e.request.url) {    e.respondWith(      caches        .open(cacheKey)        .then(cache => cache.match(e.request))        .then(response => {          if (response) return response;          return fetch(e.request);        });    );  } else {    e.respondWith(fetch(e.request));  } }); 

वास्तव में, ऐसे कोड में बहुत अधिक स्लैक-विशिष्ट तर्क होते हैं, लेकिन हमारे हैंडलर का मूल इस उदाहरण में उतना ही सरल है।


नेटवर्क इंटरैक्शन का विश्लेषण करते समय, डेटा की मात्रा का संकेत देने वाले कॉलम में सर्विस वर्कर द्वारा सेवा कार्यकर्ता से लौटी प्रतिक्रियाओं को पहचाना जा सकता है।

सक्रिय करें

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

नवीनतम रिलीज़ के बाद क्लाइंट कोड पिछड़ गया

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

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

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


कोड के नए संस्करण नियमित रूप से डाउनलोड किए जाते हैं, लेकिन प्रोग्राम डाउनलोड करते समय, केवल नवीनतम संस्करण का उपयोग किया जाता है

नई सुविधा झंडे सिंक

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

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

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

यह, वास्तव में, सेवा कार्यकर्ताओं के लिए डेवलपर के लिए उपलब्ध अवसरों के हिमखंड की नोक है। एक ऐसी समस्या जिसे AppCache तंत्र का उपयोग करके हल नहीं किया जा सकता है, या एक जिसे क्लाइंट और सर्वर तंत्र दोनों को हल करने की आवश्यकता होगी, सेवा कर्मियों और कैश एपीआई का उपयोग करके आसानी से और स्वाभाविक रूप से हल किया जा सकता है।

परिणाम

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

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


बाएं से दाएं: पुराने क्लाइंट को लोड करना, कोल्ड लोडिंग एक नया क्लाइंट, हॉट लोडिंग एक नया क्लाइंट (कम संकेतक, बेहतर)

प्रिय पाठकों! क्या आप अपनी परियोजनाओं में सेवा श्रमिकों का उपयोग करते हैं?