अपने वेब एप्लिकेशन को ऑफ़लाइन कैसे काम करें

जावास्क्रिप्ट की शक्ति और ब्राउज़र एपीआई

दुनिया अधिक अंतर्संबंधित होती जा रही है - इंटरनेट तक पहुंच वाले लोगों की संख्या 4.5 बिलियन हो गई है ।


लेकिन यह डेटा उन लोगों की संख्या को प्रतिबिंबित नहीं करता है जिनके पास धीमा या टूटा हुआ इंटरनेट कनेक्शन है। संयुक्त राज्य अमेरिका में भी 4.9 मिलियन घरों में प्रति सेकंड 3 मेगाबिट से अधिक की गति से वायर्ड इंटरनेट का उपयोग नहीं किया जा सकता है।

शेष विश्व - विश्वसनीय इंटरनेट एक्सेस वाले - अभी भी कनेक्टिविटी खोने का खतरा है। आपके नेटवर्क कनेक्शन की गुणवत्ता को प्रभावित करने वाले कुछ कारकों में शामिल हैं:

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

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

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

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

सेवा कर्मी

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

यदि वेब एप्लिकेशन लोड करने में विफल रहता है, तो हमें ब्राउज़र के लिए संसाधन कहीं (HTML / CSS / JavaScript) लेने होंगे। यदि नेटवर्क अनुरोध नहीं तो ये संसाधन कहां से आते हैं? कैश के बारे में कैसे। ज्यादातर लोग इस बात से सहमत होंगे कि एक खाली पृष्ठ की तुलना में संभावित रूप से पुराने उपयोगकर्ता इंटरफ़ेस प्रदान करना बेहतर है।

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



सेवा कार्यकर्ता सिर्फ एक जावास्क्रिप्ट फ़ाइल है जिसमें हम घटनाओं की सदस्यता ले सकते हैं और नेटवर्क विफलताओं को रोकने और संभालने के लिए अपने स्वयं के नियम लिख सकते हैं।
चलिए शुरू करते हैं।

कृपया ध्यान दें: हमारा डेमो आवेदन

इस पोस्ट के दौरान, हम डेमो एप्लिकेशन में स्टैंड-अलोन फ़ंक्शन जोड़ेंगे। लाइब्रेरी में किताबें लेने / किराए पर लेने के लिए डेमो एप्लिकेशन एक सरल पेज है। प्रगति को GIF की एक श्रृंखला के रूप में प्रस्तुत किया जाएगा, और ऑफ़लाइन Chrome DevTools सिमुलेशन का उपयोग किया जाएगा।

यहाँ प्रारंभिक अवस्था है:

कार्य 1 - स्थैतिक संसाधन कैशिंग

स्थैतिक संसाधन वे संसाधन हैं जो अक्सर बदलते नहीं हैं। HTML, CSS, JavaScript और चित्र इस श्रेणी में आ सकते हैं। ब्राउज़र अनुरोधों का उपयोग करके स्थिर संसाधनों को लोड करने का प्रयास करता है जो सेवा कार्यकर्ता द्वारा अवरोधित किया जा सकता है।

आइए हमारे सेवा कार्यकर्ता को पंजीकृत करके शुरू करें।

if ('serviceWorker' in navigator) { window.addEventListener('load', function() { navigator.serviceWorker.register('/sw.js'); }); } 

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

 var CACHE_NAME = 'my-offline-cache'; var urlsToCache = [ '/', '/static/css/main.c9699bb9.css', '/static/js/main.99348925.js' ]; self.addEventListener('install', function(event) { event.waitUntil( caches.open(CACHE_NAME) .then(function(cache) { return cache.addAll(urlsToCache); }) ); }); 

चूंकि हम स्थैतिक संसाधनों के URL को नियंत्रित करते हैं, इसलिए हम कैश Cache Storage का उपयोग करते हुए सेवा कार्यकर्ता के आरंभ के तुरंत बाद उन्हें कैश कर सकते हैं।



अब जब हमारा कैश सबसे हाल ही में अनुरोध किए गए स्थिर संसाधनों से भरा हुआ है, तो आइए इन संसाधनों को अनुरोध विफलता की स्थिति में कैश से लोड करें।

 self.addEventListener('fetch', function(event) { event.respondWith( fetch(event.request).catch(function() { caches.match(event.request).then(function(response) { return response; } ); ); }); 

ब्राउज़र द्वारा अनुरोध किए जाने पर हर बार fetch घटना को निकाल दिया जाता है। हमारे नए fetch ईवेंट हैंडलर में अब नेटवर्क आउटेज के मामले में कैश्ड प्रतिक्रियाओं को लौटाने के लिए अतिरिक्त तर्क हैं।

डेमो नंबर 1

हमारे डेमो आवेदन अब स्थिर संसाधनों ऑफ़लाइन सेवा कर सकते हैं! लेकिन हमारा डेटा कहां है?

टास्क 2 - कैशिंग डायनामिक रिसोर्स

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

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

हमारे fetch हैंडलर पर एक नज़र डालें:

 self.addEventListener('fetch', function(event) { event.respondWith( fetch(event.request).catch(function() { caches.match(event.request).then(function(response) { return response; } ); ); }); 

हम सफल कार्यान्वयन और प्रतिक्रियाओं को कैश करने वाले कुछ कोड जोड़कर इस कार्यान्वयन को अनुकूलित कर सकते हैं। यह सुनिश्चित करता है कि हम लगातार अपने कैश में नए अनुरोध जोड़ते हैं और कैश्ड डेटा को लगातार अपडेट करते हैं।

 self.addEventListener('fetch', function(event) { event.respondWith( fetch(event.request) .then(function(response) { caches.open(CACHE_NAME).then(function(cache) { cache.put(event.request, response); }); }) .catch(function() { caches.match(event.request).then(function(response) { return response; } ); ); }); 

हमारे Cache Storage वर्तमान में कई प्रविष्टियाँ हैं।

डेमो नंबर 2

हमारा डेमो अब हमारे नेटवर्क की स्थिति की परवाह किए बिना बूट पर समान दिखता है!

बहुत बढ़िया। आइए अब हमारे एप्लिकेशन का उपयोग करने का प्रयास करें।



दुर्भाग्य से, त्रुटि संदेश हर जगह हैं। ऐसा लगता है कि इंटरफ़ेस के साथ हमारे सभी इंटरैक्शन काम नहीं करते हैं। मैं किताब को चुन या सौंप नहीं सकता! क्या तय करना होगा?

कार्य 3 - एक आशावादी उपयोगकर्ता इंटरफ़ेस बनाएँ

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

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

आशावादी दृष्टिकोण का उपयोग कर नेटवर्क से हमारे एप्लिकेशन को डिस्कनेक्ट करना अपेक्षाकृत आसान है।

 case CHECK_OUT_SUCCESS: case CHECK_OUT_FAILURE: list = [...state.list]; list.push(action.payload); return { ...state, list, }; case CHECK_IN_SUCCESS: case CHECK_IN_FAILURE; list = [...state.list]; for (let i = 0; i < list.length; i++) { if (list[i].id === action.payload.id) { list.splice(i, 1, action.payload); } } return { ...state, list, }; 

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

डेमो नंबर 3

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

अच्छा है! आशावादी ऑफ़लाइन प्रतिपादन के साथ केवल एक छोटी सी समस्या है ...

क्या हम अपना बदलाव नहीं खोते?

टास्क 4 - तुल्यकालन के लिए उपयोगकर्ता क्रियाओं को कतारबद्ध करें

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

• अतुल्यकालिक गैर-अवरुद्ध संचालन
• महत्वपूर्ण रूप से उच्च भंडारण सीमा
• लेन-देन प्रबंधन

हमारे पुराने reducer कोड को देखें:

 case CHECK_OUT_SUCCESS: case CHECK_OUT_FAILURE: list = [...state.list]; list.push(action.payload); return { ...state, list, }; case CHECK_IN_SUCCESS: case CHECK_IN_FAILURE; list = [...state.list]; for (let i = 0; i < list.length; i++) { if (list[i].id === action.payload.id) { list.splice(i, 1, action.payload); } } return { ...state, list, }; 

आइए FAILURE इवेंट के दौरान IndexedDB में चेक-इन और चेक-आउट ईवेंट को संग्रहीत करने के लिए इसे संशोधित करें।

 case CHECK_OUT_FAILURE: list = [...state.list]; list.push(action.payload); addToDB(action); // QUEUE IT UP return { ...state, list, }; case CHECK_IN_FAILURE; list = [...state.list]; for (let i = 0; i < list.length; i++) { if (list[i].id === action.payload.id) { list.splice(i, 1, action.payload); addToDB(action); // QUEUE IT UP } } return { ...state, list, }; 

यहां AddToDB addToDB के साथ IndexedDB बनाने का कार्यान्वयन है।

 let db = indexedDB.open('actions', 1); db.onupgradeneeded = function(event) { let db = event.target.result; db.createObjectStore('requests', { autoIncrement: true }); }; const addToDB = action => { var db = indexedDB.open('actions', 1); db.onsuccess = function(event) { var db = event.target.result; var objStore = db .transaction(['requests'], 'readwrite') .objectStore('requests'); objStore.add(action); }; }; 

अब जब हमारे सभी ऑफ़लाइन उपयोगकर्ता क्रियाएं ब्राउज़र की मेमोरी में संग्रहीत हैं, तो कनेक्शन बहाल होने पर हम डेटा को सिंक्रनाइज़ करने के लिए online ब्राउज़र इवेंट श्रोता का उपयोग कर सकते हैं।

 window.addEventListener('online', () => { const db = indexedDB.open('actions', 1); db.onsuccess = function(event) { let db = event.target.result; let objStore = db .transaction(['requests'], 'readwrite') .objectStore('requests'); objStore.getAll().onsuccess = function(event) { let requests = event.target.result; for (let request of requests) { send(request); // sync with the server } }; }; }); 

इस स्तर पर, हम उन सभी अनुरोधों की कतार को साफ कर सकते हैं, जिन्हें हमने सफलतापूर्वक सर्वर पर भेजा था।

डेमो नंबर 4

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



यह स्पष्ट है कि ऑफ़लाइन किए गए अनुरोधों को कतार में भेज दिया गया और उपयोगकर्ता द्वारा ऑनलाइन लौटते समय एक बार भेजा गया।

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

बस इतना ही

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

ब्लॉग भी पढ़ें
EDISON कंपनी:

के लिए 20 पुस्तकालय
शानदार iOS आवेदन