प्रैक्टिकल ब्लेज़र निर्णय मार्गदर्शिका

ब्लेज़र: सर्वर, वेबअसेंबली, या हाइब्रिड?

ब्लेज़र तब उपयोगी होता है जब आप जानते हैं कि कौन सा काम सर्वर पर रहता है, कौन सा काम ब्राउज़र में जाता है, और कौन से यूआरएल वास्तविक HTML लिंक के रूप में मौजूद होने चाहिए।

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

रेंडर-मोड विकल्प से पहले

ब्लेज़र वास्तव में क्या है Blazor

ब्लेज़र .NET वेब ऐप्स के लिए माइक्रोसॉफ्ट का घटक ढांचा है। आप रेजर घटकों से यूआई बनाते हैं, सी# में अधिकांश इंटरैक्शन लॉजिक लिखते हैं, और एएसपी.नेट कोर को उन घटकों को सर्वर पर, वेबअसेंबली में, या मूल ऐप शेल के अंदर प्रस्तुत करने देते हैं। ASP.NET WebAssembly Blazor

यह पुराने ASP.NET विचारों से विकसित हुआ। वेब फ़ॉर्म ने सर्वर नियंत्रण के पीछे वेब को छिपाने का प्रयास किया। एमवीसी और रेजर पेज ने अनुरोध-प्रतिक्रिया HTML को क्लीनर बनाया। ब्लेज़र पुन: प्रयोज्य इंटरैक्टिव घटकों को जोड़ता है, लेकिन यह एमवीसी या रेज़र पेज को सरल सामग्री पेज और फॉर्म के लिए अप्रचलित नहीं बनाता है। MVC Razor Pages Blazor

ब्लेज़र से पहले Blazor

वेब फॉर्म, एमवीसी और रेजर पेज ने विभिन्न समस्याओं का समाधान किया MVC Razor Pages

वेब फॉर्म उत्पादक लेकिन भारी और स्टेटफुल था। एमवीसी और रेजर पेज ने स्वच्छ HTML और सरल अनुरोध प्रबंधन प्रदान किया। वे तब भी अच्छे होते हैं जब कोई पेज अधिकतर डेटा पढ़ता है, फॉर्म पोस्ट करता है और HTML लौटाता है। MVC Razor Pages

ब्लेज़र क्या जोड़ता है Blazor

घटक यूआई तर्क को मार्कअप के करीब रखते हैं

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

आगे क्या हुआ

आधुनिक .NET आपको रेंडर मोड को मिश्रित करने की सुविधा देता है

नए ब्लेज़र ऐप्स स्थिर सर्वर-रेंडर HTML को इंटरैक्टिव घटकों के साथ जोड़ सकते हैं। यह मायने रखता है क्योंकि एक पृष्ठ को क्रॉल करने योग्य सामग्री की आवश्यकता हो सकती है, जबकि दूसरे भाग को लाइव घटक की आवश्यकता होती है। Blazor

यहां से प्रारंभ करें

उपयोगी लघु संस्करण

ब्लेज़र एक वास्तुकला नहीं है. यह कई रेंडर मोड वाला एक घटक मॉडल है। सही विकल्प सिंटैक्स पर कम और स्थिति, विलंबता, मेमोरी और क्रॉल करने योग्य लिंक कहां रहते हैं इस पर अधिक निर्भर करता है।

सर्वर

ब्लेज़र सर्वर स्टेटफुल है

यह पहले लोड पर तेज़ महसूस कर सकता है, लेकिन सर्वर लाइव सर्किट रखता है। ट्रैफ़िक बढ़ने से पहले मेमोरी की योजना बनाएं, व्यवहार को फिर से कनेक्ट करें और स्केल-आउट करें।

ब्राउज़र

WebAssembly अग्रिम भुगतान करता है

यह लाइव सर्वर सर्किट को हटा देता है, लेकिन पहली विज़िट रनटाइम और ऐप डाउनलोड करती है। कैश, ट्रिमिंग और प्रीरेंडरिंग मायने रखती है।

मूलनिवासी

हाइब्रिड एक उत्पाद निर्णय है

जब ऐप को वास्तव में डेस्कटॉप या मोबाइल शेल की आवश्यकता हो तो हाइब्रिड का उपयोग करें। सार्वजनिक सामग्री के लिए, वेब रेंडरिंग और वास्तविक यूआरएल का उपयोग करें।

Blazor सर्वर

ब्लेज़र सर्वर क्लिक के बीच काम को सक्रिय रखता है

ब्लेज़र सर्वर एक सामान्य स्टेटलेस अनुरोध-प्रतिक्रिया पृष्ठ नहीं है। कनेक्टेड ब्राउज़र टैब को एक सर्किट मिलता है। उपयोगकर्ता के कनेक्ट रहने के दौरान सर्वर उस सर्किट के लिए घटक स्थिति और स्कोप्ड सेवाओं को रखता है, और अक्सर डिस्कनेक्ट के बाद एक छोटी रीकनेक्ट विंडो के लिए भी।

सक्रिय सर्किट के साथ मेमोरी बढ़ती है

प्रत्येक कनेक्टेड टैब में एक सर्किट होता है। घटक स्थिति, स्कोप्ड सेवाएँ, सत्यापन स्थिति और लंबित यूआई कार्य सर्किट समाप्त होने तक मेमोरी में रह सकते हैं। लोड परीक्षणों में सक्रिय उपयोगकर्ताओं की गणना होनी चाहिए, न कि प्रति सेकंड केवल अनुरोधों की।

विलंबता यूआई का हिस्सा बन जाती है

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

स्केल-आउट के लिए एक योजना की आवश्यकता है

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

अच्छा फिट: नियंत्रित उपयोगकर्ता

ब्लेज़र सर्वर प्रमाणित टूल, एडमिन स्क्रीन, डैशबोर्ड और आंतरिक ऐप्स के लिए सबसे मजबूत है जहां उपयोगकर्ता, विलंबता और होस्टिंग क्षमता ज्ञात होती है।

Blazor WebAssembly

WebAssembly लागत को पहले लोड पर ले जाता है

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

पहला बोझ है टैक्स

ब्राउज़र .NET रनटाइम, ऐप असेंबली, संसाधन और स्थिर संपत्ति डाउनलोड करता है। ट्रिमिंग से मदद मिलती है. समय से पहले संकलन सीपीयू-भारी कार्य में सुधार कर सकता है लेकिन अक्सर डाउनलोड आकार बढ़ाता है।

ग्राहक में राज़ नहीं रह सकता

एक WebAssembly ऐप उपयोगकर्ता के ब्राउज़र में चलता है। इसे किसी भी सार्वजनिक फ्रंटएंड की तरह समझें: सर्वर पर रहस्य रखें, एपीआई की सुरक्षा करें और मान लें कि क्लाइंट कोड का निरीक्षण किया जा सकता है।

एसईओ को प्रस्तुत सामग्री की आवश्यकता है

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

अच्छा फिट: ऑफ़लाइन या क्लाइंट-भारी ऐप्स

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

हाइब्रिड और वेबव्यू

हाइब्रिड ऐप्स के लिए है, सार्वजनिक लैंडिंग पेजों के लिए नहीं

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

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

निर्णय मार्गदर्शिका

जिस बाधा को आप स्वीकार करते हैं उसके अनुसार चुनें

प्रत्येक रेंडर मोड दबाव को एक अलग स्थान पर ले जाता है। वह दबाव चुनें जिसे आप माप सकते हैं, होस्ट कर सकते हैं और टीम को समझा सकते हैं।

सर्वर चुनें

जब पहला लोड और .NET बैकएंड एकीकरण सबसे अधिक मायने रखता है

नियंत्रित प्रमाणित ऐप्स के लिए ब्लेज़र सर्वर चुनें जहां सर्वर मेमोरी, लाइव कनेक्शन और क्षेत्रीय विलंबता स्वीकार्य परिचालन लागत है।

वेबअसेंबली चुनें

जब क्लाइंट का काम और ऑफलाइन व्यवहार सबसे ज्यादा मायने रखता है

जब बार-बार विज़िट, कैशिंग, ऑफ़लाइन उपयोग, या स्थानीय सीपीयू कार्य सबसे छोटे पहले लोड से अधिक महत्वपूर्ण हो तो WebAssembly चुनें।

हाइब्रिड चुनें

जब उत्पाद वास्तव में एक देशी ऐप हो

जब एप्लिकेशन डेस्कटॉप या मोबाइल पर हो और सार्वजनिक वेब पहुंच से अधिक स्थानीय एकीकरण की आवश्यकता हो तो हाइब्रिड चुनें।

एमवीसी या रेजर पेज चुनें

जब साइट पर अधिकतर दस्तावेज़ और फॉर्म होते हैं

क्लासिक ASP.NET कोर MVC या रेज़र पेज अक्सर सामग्री-भारी साइटों, सार्वजनिक दस्तावेज़ीकरण और सीमित अन्तरक्रियाशीलता वाले फ़ॉर्म के लिए सरल होते हैं।

संदर्भ अनुभाग

जब आप इसे वास्तविक रूप से बनाएं तो इन्हें आगे पढ़ें

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

अक्सर पूछे जाने वाले सवाल

ब्लेज़र सर्वर को एमवीसी से अधिक मेमोरी की आवश्यकता क्यों हो सकती है?

एमवीसी एक अनुरोध पूरा कर सकता है और अधिकांश अनुरोध स्थिति जारी कर सकता है। ब्लेज़र सर्वर प्रत्येक कनेक्टेड ब्राउज़र टैब के लिए एक सर्किट रखता है, ताकि क्लिक के बीच घटक स्थिति और स्कोप्ड सेवाएं सक्रिय रह सकें।

क्या मैं एकाधिक ऐप इंस्टेंसेस पर ब्लेज़र सर्वर चला सकता हूँ?

हां, लेकिन सोच-समझकर इसकी योजना बनाएं। लाइव सर्किट और सिग्नलआर कनेक्शन को स्थिर रूटिंग, एक बैकप्लेन या प्रबंधित सिग्नलआर सेवा और एप्लिकेशन स्थिति की आवश्यकता होती है जो जीवित रहती है और सही ढंग से पुनः कनेक्ट होती है।

क्या ब्लेज़र वेबअसेंबली एसईओ-अनुकूल हो सकती है?

हाँ, लेकिन खाली शेल भेजकर और यह आशा करके नहीं कि क्रॉलर प्रतीक्षा करेगा। सार्वजनिक पृष्ठों को पहली प्रतिक्रिया से पहले या उसके दौरान HTML, मेटाडेटा, कैनोनिकल लिंक और संरचित डेटा प्रदान करने की आवश्यकता होती है।

बहुभाषी ब्लेज़र लिंक कैसे बनाए जाने चाहिए?

केंद्रीय मार्ग परिभाषाओं का उपयोग करें और प्रत्येक संस्कृति के लिए वास्तविक एंकर टैग प्रस्तुत करें। दृश्यमान लिंक, कैनोनिकल URL और hreflang डेटा को संरेखित रखें ताकि उपयोगकर्ता और क्रॉलर समान भाषा संरचना देख सकें।