जटिलता को मैनेज करना

किसी वेब ऐप्लिकेशन को आसान बनाना बहुत ही मुश्किल हो सकता है. इस मॉड्यूल में, आपको पता चलेगा कि वेब एपीआई, थ्रेडिंग के साथ कैसे काम करते हैं. साथ ही, आपको यह भी पता चलेगा कि स्टेट मैनेजमेंट जैसे सामान्य PWA पैटर्न के लिए इसका इस्तेमाल कैसे किया जा सकता है.

रिच हिकी ने अपने विषय सिंपल मेड ईज़ी में, आसान और जटिल चीज़ों के बारे में चर्चा की है. वे आसान चीज़ों को इन चीज़ों पर फ़ोकस करते हैं:

"एक भूमिका, एक टास्क, एक कॉन्सेप्ट या एक डाइमेंशन."

हालांकि, इस बात पर ज़ोर दिया जाता है कि सादगी का यह मतलब नहीं है:

"एक बार या एक ही कार्रवाई करना."

कोई चीज़ आसान है या नहीं, इस बारे में सोचें कि यह आपस में कितना जुड़ा हुआ है.

मुश्किल शब्दों का इस्तेमाल, चीज़ों को जोड़ने, बुनाई करने या रिच शब्द का इस्तेमाल करने से होता है. एल्गोरिदम की जटिलता का हिसाब लगाने के लिए, इसे मैनेज की जाने वाली भूमिकाओं, टास्क, कॉन्सेप्ट या डाइमेंशन की संख्या गिन लें.

सॉफ़्टवेयर के डेवलपमेंट में आसान होना ज़रूरी है, क्योंकि आसान कोड को समझना और उसे बनाए रखना आसान होता है. वेब ऐप्लिकेशन के लिए आसान होना भी ज़रूरी है, क्योंकि यह हमारे ऐप्लिकेशन को हर संभव संदर्भ में तेज़ और ऐक्सेस करने लायक बनाने में मदद कर सकता है.

PWA की जटिलता को मैनेज करना

हम वेब के लिए जो भी JavaScript लिखते हैं वह मुख्य थ्रेड को एक ही जगह पर छू लेती है. हालांकि, मुख्य थ्रेड में बहुत सारी जटिलताएं थीं, जिन पर डेवलपर के तौर पर आपका कोई कंट्रोल नहीं होता.

मुख्य थ्रेड है:

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

जैसा कि सुरमा ने 2019 के Chrome Dev Summit के बारे में अपने भाषण में बताया. उन्होंने कहा कि मुख्य थ्रेड में बहुत ज़्यादा काम नहीं हुआ है और इसके लिए कम पैसे भी देने पड़ते हैं.

फिर भी, ज़्यादातर ऐप्लिकेशन कोड मुख्य थ्रेड में भी मौजूद होते हैं.

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

जब इंटरैक्शन इनपुट से कनेक्ट नहीं होते हैं, फ़्रेम कम हो जाते हैं या किसी साइट को इस्तेमाल करने में बहुत ज़्यादा समय लगता है, तो उपयोगकर्ता हताश हो जाते हैं, उन्हें लगता है कि ऐप्लिकेशन काम नहीं कर रहा है, और इस बारे में उनका भरोसा कम हो जाता है.

बुरी खबर है? मुख्य थ्रेड में जटिलता जोड़ना, इन लक्ष्यों को पूरा करने में मुश्किल काम करने का करीब-करीब पक्का तरीका है. खुशखबरी यह है कि मुख्य थ्रेड को साफ़ तौर पर बताया जाना चाहिए: इसका इस्तेमाल गाइड के तौर पर किया जा सकता है, ताकि बाकी ऐप्लिकेशन के लिए इस पर निर्भरता कम हो सके.

समस्याओं को अलग-अलग हिस्सों में बांटें

वेब ऐप्लिकेशन कई तरह के काम करते हैं, लेकिन मोटे तौर पर, आप इसे ऐसे काम में बांट सकते हैं जो सीधे यूज़र इंटरफ़ेस (यूआई) को छुएं और जो काम नहीं करते. यूज़र इंटरफ़ेस (यूआई) का काम ऐसा काम है जिसमें:

  • DOM को सीधे टच करता है.
  • यह ऐसे एपीआई का इस्तेमाल करता है जो डिवाइस की क्षमताओं, जैसे कि सूचनाएं या फ़ाइल सिस्टम ऐक्सेस को छूते हैं.
  • पहचान को छूता है. उदाहरण के लिए, उपयोगकर्ता कुकी, लोकल या सेशन का स्टोरेज.
  • इनके ज़रिए इमेज, ऑडियो या वीडियो जैसे मीडिया को मैनेज किया जाता है.
  • इसमें सुरक्षा से जुड़े ऐसे नतीजे होते हैं जिन्हें मंज़ूरी देने के लिए उपयोगकर्ता की ज़रूरत होती है, जैसे कि वेब सीरियल एपीआई.

जो काम यूज़र इंटरफ़ेस (यूआई) नहीं है उसमें ये चीज़ें शामिल हो सकती हैं:

  • पूरी तरह से गिनती.
  • डेटा ऐक्सेस (फ़ेच, IndexedDB वगैरह).
  • क्रिप्टो.
  • मैसेज सेवा.
  • ब्लॉब या स्ट्रीम बनाना या उसमें बदलाव करना.

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

सिर्फ़ एक टास्क पर फ़ोकस करें

कोड को आसान बनाने का सबसे आसान तरीका, फ़ंक्शन को तोड़ना है, ताकि हर एक टास्क किसी एक काम पर फ़ोकस कर सके. टास्क तय करने के लिए, शुरू से अंत तक के चरणों को देखें:

  • सबसे पहले, लोगों के इनपुट का जवाब दें. यह यूज़र इंटरफ़ेस (यूआई) का काम है.
  • इसके बाद, एपीआई के लिए अनुरोध करें. यह नॉन-यूज़र इंटरफ़ेस (यूआई) वाला काम है.
  • इसके बाद, एपीआई अनुरोध को पार्स करें. यह काम यूज़र इंटरफ़ेस (यूआई) के अलावा किया जाने वाला काम है.
  • इसके बाद, डीओएम में हुए बदलावों को तय करें. यह यूआई का काम हो सकता है या अगर वर्चुअल डीओएम लागू करने जैसी किसी चीज़ का इस्तेमाल किया जा रहा है, तो हो सकता है कि यह यूज़र इंटरफ़ेस (यूआई) का काम न हो.
  • आखिर में, डीओएम में बदलाव करें. यह यूज़र इंटरफ़ेस (यूआई) का काम है.

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

कंपोज़ेबिलिटी

बड़े एंड-टू-एंड वर्कफ़्लो को छोटे-छोटे हिस्सों में बांटने के लिए, आपको कोड बेस की कंपोज़ेबिलिटी के बारे में सोचना होगा. फ़ंक्शनल प्रोग्रामिंग से संकेत लेते हुए, इन बातों पर विचार करें:

  • आपका ऐप्लिकेशन जिस तरह के काम करता है उसे अलग-अलग कैटगरी में रखना.
  • उनके लिए सामान्य इनपुट और आउटपुट इंटरफ़ेस बनाना.

उदाहरण के लिए, एपीआई को वापस लाने के सभी टास्क, एपीआई एंडपॉइंट में होते हैं और स्टैंडर्ड ऑब्जेक्ट का कलेक्शन दिखाते हैं. साथ ही, सभी डेटा-प्रोसेसिंग फ़ंक्शन, स्टैंडर्ड ऑब्जेक्ट का अरे लेते हैं और दिखाते हैं.

JavaScript में एक स्ट्रक्चर्ड क्लोन एल्गोरिदम होता है, जिसका इस्तेमाल जटिल JavaScript ऑब्जेक्ट को कॉपी करने के लिए किया जाता है. वेब वर्कर, मैसेज भेजते समय इसका इस्तेमाल करते हैं और IndexedDB इसका इस्तेमाल ऑब्जेक्ट को स्टोर करने के लिए करता है. स्ट्रक्चर्ड क्लोनिंग एल्गोरिदम के साथ इस्तेमाल किए जा सकने वाले इंटरफ़ेस चुनने से, उन्हें चलाने में ज़्यादा आसानी होगी.

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

कंपोज़ेबल कोड मिलने के बाद, मुख्य थ्रेड से इसमें से कुछ कॉपी को दूर करने का समय आ गया है.

जटिलता को कम करने के लिए वेब वर्कर का इस्तेमाल करना

वेब वर्कर, जो अक्सर कम इस्तेमाल की जाती है, लेकिन बड़े पैमाने पर उपलब्ध होती है. इसकी मदद से, काम को मुख्य थ्रेड से अलग किया जा सकता है.

वेब वर्कर, मुख्य थ्रेड के बाहर PWA को (कुछ) JavaScript चलाने देते हैं.

कर्मचारी तीन तरह के होते हैं.

वेब वर्कर के बारे में जानकारी देते समय, काम के लिए खास तौर पर काम करने वाले वर्कर का इस्तेमाल, PWA के एक ही इंस्टेंस में किसी एक स्क्रिप्ट के लिए किया जा सकता है. जब भी संभव हो, तो जो काम DOM के साथ सीधे इंटरैक्ट नहीं करता उसे परफ़ॉर्मेंस को बेहतर बनाने के लिए वेब वर्कर पर ले जाया जाना चाहिए.

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

उदाहरण के लिए, शेयर किया गया वर्कर, PWA के IndexedDB के लिए ऐक्सेस और लेन-देन को मैनेज कर सकता है. साथ ही, कॉल करने वाली सभी स्क्रिप्ट में लेन-देन के नतीजों को ब्रॉडकास्ट कर सकता है, ताकि वे बदलावों के हिसाब से प्रतिक्रिया दे सकें.

इस कोर्स में, फ़ाइनल वेब वर्कर को बड़े पैमाने पर कवर किया गया है: सर्विस वर्कर, जो नेटवर्क अनुरोधों के लिए प्रॉक्सी के रूप में काम करते हैं और PWA के सभी इंस्टेंस के बीच शेयर किए जाते हैं.

खुद आज़माकर देखें

कोड का समय आ गया है! इस मॉड्यूल में आपने जो कुछ भी सीखा है उसके आधार पर नए PWA बनाएं.

रिसॉर्स