JavaScript फ़्रेमवर्क नेटवर्क का पालन
अपनी शुरुआती ब्लॉग पोस्ट में हमने बताया कि Google Search, Maps, Photos वगैरह जैसे बड़े पैमाने पर वेब ऐप्लिकेशन को डेवलप करने और उनका रखरखाव करने के लिए, फ़्रेमवर्क और टूल बनाते और इस्तेमाल करते समय हमने क्या सीखा. डेवलपर को उपयोगकर्ता अनुभव पर बुरा असर डालने वाले कोड लिखने से रोकने से, हमने यह साबित किया कि फ़्रेमवर्क, परफ़ॉर्मेंस और ऐप्लिकेशन की क्वालिटी के लिए नतीजों को बदलने में अहम भूमिका निभा सकते हैं.
Google में अंदरूनी तौर पर, हमने "नियम" शब्द का इस्तेमाल करके इस तरीके के बारे में बताया है. इस लेख में बताया गया है कि हम इस कॉन्सेप्ट को JavaScript फ़्रेमवर्क नेटवर्क के लिए ओपन-सोर्स कैसे बनाते हैं.
कन्फ़ॉर्मैंस क्या है?
Google में, कन्फ़ॉर्मैंस एक बेहतर बदलाव था. टीमें कुछ अनुभवी सदस्यों पर निर्भर थीं जिन्होंने कोड की बारीकी से समीक्षा की. उन्होंने ऐप्लिकेशन की क्वालिटी और रखरखाव पर असर डालने वाली चीज़ों को फ़्लैग किया. साथ ही, उन्हें ठीक करने में होने वाली समस्याओं को भी ठीक नहीं किया गया. इसे ऐप्लिकेशन डेवलपर की बढ़ती हुई टीमों तक पहुंचाने के लिए, एक कंफ़ॉर्मैंस सिस्टम डेवलप किया गया. ऐसा इसलिए किया गया, ताकि सबसे सही तरीकों को अपने-आप और लागू किया जा सके. इससे ऐप्लिकेशन की क्वालिटी और कोड बेस के रखरखाव को लगातार बेहतर बनाए रखने में मदद मिली, चाहे कोड में कितने भी कोड देने वाले लोग हों.
शर्तों का पालन करना एक ऐसा सिस्टम है जो पक्का करता है कि डेवलपर अच्छी रोशनी वाले रास्ते पर बने रहें. इससे, उनमें भरोसा पैदा होता है और उनका अनुमान लगाया जा सकता है. इससे टीम ज़्यादा काम करती है और स्केल के लिए, यह काफ़ी अहम हो जाता है. जैसे-जैसे टीम बढ़ती है और ज़्यादा सुविधाएं साथ-साथ बढ़ती जाती हैं. इससे डेवलपर को प्रॉडक्ट की सुविधाएँ बनाने, उन्हें छोटे-छोटे कामों से छुटकारा दिलाने, परफ़ॉर्मेंस, सुलभता, सुरक्षा वगैरह जैसे अलग-अलग क्षेत्रों में होने वाले बदलावों पर ध्यान देने में मदद मिलती है. कोई भी किसी भी समय शर्तों के पालन से ऑप्ट-आउट कर सकता है. साथ ही, इसे अपनी पसंद के मुताबिक बनाया जा सकता है.
नियमों का पालन, मज़बूत डिफ़ॉल्ट सेटिंग पर किया जाता है. साथ ही, इसमें कार्रवाई करने वाले नियम मिलते हैं, जिन्हें ऑथराइज़ेशन के समय पर लागू किया जा सकता है. इसे तीन सिद्धांतों में बांटा गया है.
1. मज़बूत डिफ़ॉल्ट
शर्तों के पालन का एक बुनियादी पहलू यह पक्का करना है कि डेवलपर जिन टूल का इस्तेमाल करते हैं उनमें डिफ़ॉल्ट सेटिंग लागू हों. इसका मतलब है कि सलूशन सिर्फ़ फ़्रेमवर्क के मुताबिक नहीं बनाए जाते. साथ ही, डिज़ाइन पैटर्न से सही काम करना आसान हो जाता है और एंटी-पैटर्न को फ़ॉलो करना मुश्किल हो जाता है. यह फ़्रेमवर्क, ऐप्लिकेशन के डिज़ाइन और कोड स्ट्रक्चर की सुविधा देने वाले डेवलपर की मदद करता है.
लोड होने की परफ़ॉर्मेंस के लिए, हर संसाधन (फ़ॉन्ट, सीएसएस, JavaScript, इमेज वगैरह) को ऑप्टिमाइज़ किया जाना चाहिए. यह एक मुश्किल चुनौती है जिसमें बाइट को ट्रिम करना, राउंड ट्रिप को कम करना, और पहली रेंडर, विज़ुअल रेडीनेस, और यूज़र इंटरैक्शन के लिए ज़रूरी चीज़ों को अलग-अलग करना शामिल है. उदाहरण के लिए, ज़रूरी सीएसएस को निकालना और ज़रूरी इमेज को प्राथमिकता सेट करना.
2. कार्रवाई करने लायक नियम
बुनियादी ऑप्टिमाइज़ेशन के बावजूद, डेवलपर को भी फ़ैसले लेने होते हैं. अगर यह तय होता है कि डेवलपर के इनपुट की कितनी ज़रूरत है, तो इसे ऑप्टिमाइज़ करने की कई संभावनाएं हैं:
- ऐसी डिफ़ॉल्ट सेटिंग जिनके लिए डेवलपर के इनपुट की ज़रूरत नहीं होती. जैसे, ज़रूरी सीएसएस को इनलाइन करना.
- डेवलपर ऑप्ट-इन करना ज़रूरी है. उदाहरण के लिए, इमेज के साइज़ और स्केल के लिए, फ़्रेमवर्क के साथ मिले इमेज कॉम्पोनेंट का इस्तेमाल करना.
- डेवलपर ने ऑप्ट-इन करना और पसंद के मुताबिक बनाना ज़रूरी है. उदाहरण के लिए, अहम इमेज को जल्दी लोड करने के लिए टैग करना.
- कोई खास सुविधा नहीं है, लेकिन ऐसी चीज़ें जिनके लिए डेवलपर के फ़ैसले की ज़रूरत होती है. उदाहरण के लिए, ऐसे फ़ॉन्ट या सिंक्रोनस स्क्रिप्ट को शामिल न करें जो जल्दी रेंडर होने में देरी करती हैं.
जिन ऑप्टिमाइज़ेशन के लिए डेवलपर को फ़ैसला लेना ज़रूरी होता है उनसे ऐप्लिकेशन की परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. जैसे-जैसे सुविधाएं जोड़ी जाएंगी और आपकी टीम बेहतर बनेगी, सबसे ज़्यादा अनुभवी डेवलपर भी लगातार बदलते रहने वाले सबसे सही तरीकों के हिसाब से काम नहीं कर पा रहे हैं और न ही उनके समय का सही इस्तेमाल हो पा रहा है. शर्तों के पालन के लिए, कार्रवाई करने लायक सही नियम, मज़बूत डिफ़ॉल्ट बनाने की तरह ही ज़रूरी हैं. इससे यह पक्का होता है कि डेवलपर के बदलाव जारी रखने के बावजूद, ऐप्लिकेशन एक तय मानकों को पूरा करता रहे.
3. लेखन का समय
डेवलपमेंट की लाइफ़साइकल की शुरुआत में, परफ़ॉर्मेंस की समस्याओं को पकड़ना और उन्हें रोकना ज़रूरी है. कोड तय करने से पहले, लिखने का समय, समस्याओं को पहचानने और उन्हें हल करने के लिए बेहतर होता है. बाद में कोई समस्या डेवलपमेंट लाइफ़साइकल में फंस जाती है, इसे हल करना उतना ही ज़्यादा मुश्किल और खर्चीला हो जाता है. हालांकि, यह सही होने से जुड़ी समस्याओं पर लागू होता है, लेकिन परफ़ॉर्मेंस की समस्याओं के लिए भी ऐसा होता है, क्योंकि कोड बेस से जुड़ने के बाद, इनमें से कई समस्याओं को पहले से हल नहीं किया जा सकेगा.
फ़िलहाल, परफ़ॉर्मेंस से जुड़े ज़्यादातर सुझाव, दस्तावेज़ों या एक बार के ऑडिट के ज़रिए आउट-ऑफ़-बैंड से जुड़े हैं या प्रोडक्शन में डिप्लॉय किए जाने के बाद, मेट्रिक रिग्रेशन के ज़रिए काफ़ी देर से दिखाए जाते हैं. हम इसे ऑथरिंग टाइम में शामिल करना चाहते हैं.
फ़्रेमवर्क का पालन
परफ़ॉर्मेंस लोड करने के दौरान, उपयोगकर्ता अनुभव को बेहतर बनाए रखने के लिए, आपको यहां दिए गए सवालों के जवाब देने होंगे:
- सबसे सही तरीके से लोड होने के लिए क्या बनाया जाता है और ऐसी कौनसी सामान्य समस्याएं हैं जिनकी वजह से साइट पर बुरा असर पड़ सकता है?
- ऐसे कौनसे समाधान बेक किए जा सकते हैं जिनमें डेवलपर के इनपुट की ज़रूरत न हो?
- हम यह कैसे पक्का करें कि डेवलपर इन समाधानों का इस्तेमाल करे और बेहतर तरीके से उनका इस्तेमाल करे?
- ऐप्लिकेशन लोड होने की परफ़ॉर्मेंस पर, डेवलपर किन अन्य विकल्पों का असर डाल सकता है?
- ऐसे कौनसे कोड पैटर्न हैं जो हमें लिखने के समय की शुरुआत में ही इन विकल्पों (#3 और #4 ऊपर) के बारे में बता सकते हैं?
- इन कोड पैटर्न का आकलन करने के लिए, हम कौनसे नियम बना सकते हैं? उन्हें वर्कफ़्लो में आसानी से इंटिग्रेट होने के दौरान, डेवलपर को ऑथराइज़ेशन के समय कैसे दिखाया जा सकता है?
ओपन-सोर्स फ़्रेमवर्क के लिए Google में आंतरिक रूप से मौजूद कंफ़ॉर्मैंस मॉडल को लाने के लिए, हमारी टीम ने Next.js में काफ़ी प्रयोग किए हैं. साथ ही, हम अपने बेहतर विज़न और प्लान को शेयर करते हुए बहुत उत्साहित हैं. हमने महसूस किया है कि कोड पैटर्न का आकलन करने वाले सबसे अच्छे नियमों को स्टैटिक कोड विश्लेषण और डाइनैमिक जांच का कॉम्बिनेशन बनाना होगा. ये नियम कई प्लैटफ़ॉर्म के लिए इस्तेमाल किए जा सकते हैं. जैसे:
- ESLint
- TypeScript
- उपयोगकर्ता के डेवलपमेंट सर्वर में डाइनैमिक जांच (डीओएम बनाने के बाद)
- मॉड्यूल बंडलर (वेबपैक)
- सीएसएस टूलिंग (अब भी एक्सप्लोरेट्री)
अलग-अलग टूल की मदद से नियम उपलब्ध कराने से, हम यह पक्का कर सकते हैं कि वे एक-दूसरे से जुड़ी हों. हालांकि, उपयोगकर्ता अनुभव से जुड़ी ऐसी सभी समस्याएं भी शामिल हो जाती हैं जो लोड होने की परफ़ॉर्मेंस पर सीधे तौर पर असर डालती हैं. इसके अलावा, ये नियम डेवलपर को अलग-अलग समय पर भी दिखाए जा सकते हैं:
- डेवलपमेंट सर्वर में लोकल डेवलपमेंट के दौरान, ब्राउज़र और उपयोगकर्ता के IDE में चेतावनियां दिखेंगी और डेवलपर को कोड में छोटे बदलाव करने के लिए कहा जाएगा.
- बिल्ड के समय, जो समस्याएं हल नहीं होंगी वे उपयोगकर्ता के टर्मिनल में फिर से दिखेंगी
कम शब्दों में कहें, तो टीमें अपनी पसंद के नतीजे चुनेगी. जैसे, वेबसाइट की परफ़ॉर्मेंस की जानकारी या कॉन्टेंट लोड होने की परफ़ॉर्मेंस से जुड़े नियम. साथ ही, कोड इस्तेमाल करने वाले सभी लोगों को लागू करने के लिए, काम के नियम सेट करने होंगे.
हालांकि, यह नए प्रोजेक्ट के लिए वाकई बहुत अच्छा काम करता है, लेकिन पूरे नियमों का पालन करने के लिए, बड़े कोडबेस को अपग्रेड करना आसान नहीं है. Google में अलग-अलग लेवल पर ऑप्ट-आउट करने के लिए हमारे पास एक व्यापक सिस्टम है. जैसे, सोर्स कोड की अलग-अलग लाइनें, पूरी डायरेक्ट्री, लेगसी कोडबेस या ऐप्लिकेशन के ऐसे हिस्से जिनका अभी डेवलपमेंट चल रहा है. हम ओपन-सोर्स फ़्रेमवर्क का इस्तेमाल करके, इन टीमों को लाने के लिए असरदार रणनीतियां बनाने की कोशिश कर रहे हैं.
Next.js में नियमों का पालन
JavaScript डेवलपर में ESLint का ज़्यादातर इस्तेमाल किया जाता है. साथ ही, Next.js के 50% से ज़्यादा ऐप्लिकेशन, अपने बिल्ड वर्कफ़्लो के कुछ हिस्से में ESLint इस्तेमाल करते हैं. Next.js v11 में कुछ अलग तरह की ESLint सहायता दी गई है. इसमें कस्टम प्लगिन और शेयर किया जा सकने वाला कॉन्फ़िगरेशन शामिल है. इससे, डेवलपमेंट के दौरान और बनाते समय, फ़्रेमवर्क से जुड़ी सामान्य समस्याओं को आसानी से ठीक किया जा सकता है. इससे डेवलपर को ऑथराइज़ेशन के समय होने वाली अहम समस्याओं को ठीक करने में मदद मिल सकती है. उदाहरण के लिए, जब किसी खास कॉम्पोनेंट को इस तरह से इस्तेमाल किया जाता है या नहीं किया जाता है, जिससे परफ़ॉर्मेंस को नुकसान पहुंच सकता है. जैसे, पेज के लिए कोई एचटीएमएल लिंक नहीं. इसके अलावा, अगर कोई खास फ़ॉन्ट, स्टाइलशीट या स्क्रिप्ट, पेज के रिसॉर्स लोड होने पर बुरा असर डाल सकता है. उदाहरण के लिए, कोई सिंक्रोनस स्क्रिप्ट नहीं.
ESLint के अलावा, डेवलपमेंट और प्रोडक्शन दोनों में इंटिग्रेट की गई टाइप-चेकिंग की सुविधा Next.js में, v9 से टाइपस्क्रिप्ट समर्थन के साथ काम करती है. फ़्रेमवर्क (इमेज, स्क्रिप्ट, लिंक) के ज़रिए दिए गए कई कॉम्पोनेंट को एचटीएमएल एलिमेंट (<img>, <script>, <a>) के एक्सटेंशन के तौर पर बनाया गया है, ताकि डेवलपर को किसी वेब पेज में कॉन्टेंट जोड़ने का बेहतर तरीका मिल सके. टाइप-चेकिंग सुविधा यह पक्का करके इन सुविधाओं का सही इस्तेमाल करती है कि प्रॉपर्टी और असाइन किए गए विकल्प, इस्तेमाल की जा सकने वाली वैल्यू और टाइप के उचित दायरे में हैं. उदाहरण के लिए, इमेज की चौड़ाई और ऊंचाई ज़रूरी है देखें.
टोस्ट और ओवरले की मदद से गड़बड़ियां दिखाना
जैसा कि पहले बताया गया है, शर्तों का पालन करने के नियम कई इलाकों में लागू किए जा सकते हैं. फ़िलहाल, टोस्ट और ओवरले को इस तरह एक्सप्लोर किया जा रहा है कि उपयोगकर्ता के लोकल डेवलपमेंट एनवायरमेंट में, सीधे ब्राउज़र में गड़बड़ियों को दिखाया जा सके.
गड़बड़ी की जांच करने और ऑडिट करने वाले ऐसे कई टूल जिन पर डेवलपर भरोसा करते हैं (Lighthouse, Chrome DevTools समस्याएं टैब) हैं, वे काम नहीं करते हैं. इन्हें जानकारी पाने के लिए, किसी तरह के उपयोगकर्ता इंटरैक्शन की ज़रूरत होती है. जब डेवलपर के मौजूदा टूल में गड़बड़ियां सीधे तौर पर दिखती हैं, तब उनके काम करने की संभावना ज़्यादा होती है. साथ ही, उन्हें समस्या को ठीक करने के लिए सटीक और खास कार्रवाइयां करने की ज़रूरत पड़ती है.
अन्य फ़्रेमवर्क का पालन
सबसे पहले, Next.js में नियमों के पालन को एक्सप्लोर किया जा रहा है. इसका मकसद, अन्य फ़्रेमवर्क (Nuxt, Angular वगैरह) का इस्तेमाल करना है. ESLint और TypeScript पहले से ही, कई फ़्रेमवर्क में अलग-अलग तरीकों से इस्तेमाल किए जा रहे हैं, लेकिन ब्राउज़र के लेवल पर चलने वाले रनटाइम सिस्टम को बारीकी से एक्सप्लोर किया जा रहा है.
नतीजा
कंफ़ॉर्मैंस, सबसे सही तरीकों को ऐसे नियमों के सेट में बांटती है जो डेवलपर के लिए आसान कोड पैटर्न के तौर पर कार्रवाई करने लायक होते हैं. ऑरोरा की टीम ने लोड होने की परफ़ॉर्मेंस पर ध्यान दिया है, लेकिन सुलभता और सुरक्षा जैसे दूसरे सबसे अच्छे तरीके भी उसी तरह लागू होते हैं.
नियमों का पालन करने से, उम्मीद के मुताबिक नतीजे मिल सकते हैं. साथ ही, बहुत ज़्यादा उपयोगकर्ता अनुभव हासिल करने से, आपके टेक्नोलॉजी स्टैक को बेहतर बनाने पर बुरा असर पड़ सकता है. नियमों का पालन करने से, टीमें बेहतर परफ़ॉर्म करती हैं. साथ ही, यह पक्का करता है कि ऐप्लिकेशन को अच्छी क्वालिटी का बार मिले. समय के साथ टीम और कोडबेस में भी बढ़ोतरी होती रहती है.