Blazor शुरू से: अध्याय 1 — Blazor क्या है?

· 7 मिनट पढ़ें
Blazor .NET Web Development Series
Available in: हिन्दी · English · Español · Français · Deutsch · Português · 한국어 · 日本語 · Русский · 中文 · العربية · Polski · Türkçe · Bahasa Indonesia · Nederlands

Blazor शुरू से के अध्याय 1 में आपका स्वागत है। यदि आपने परिचय पोस्ट को छोड़ दिया जहाँ मैंने बताया कि यह सीरीज़ किसके लिए है, तो पहले वहाँ से शुरू करें — यह छोटा है।

इस अध्याय में हम मूलभूत प्रश्न का उत्तर देंगे: Blazor क्या है? यह सरल लगता है, लेकिन उत्तर में कई परतें हैं — खासकर इसलिए क्योंकि वर्षों में “Blazor” के थोड़े अलग अर्थ हो गए हैं। इस पोस्ट के अंत तक आप जानेंगे कि Blazor क्या है, यह .NET इकोसिस्टम में कैसे फिट होता है, विभिन्न रेंडरिंग मॉडल क्या हैं, और आप JavaScript फ्रेमवर्क के बजाय इसे क्यों चुन सकते हैं — या नहीं।

एक संक्षिप्त इतिहास

Blazor लगभग 2017 में Microsoft में Steve Sanderson के एक प्रायोगिक प्रोजेक्ट के रूप में शुरू हुआ। विचार उत्तेजक था: WebAssembly का उपयोग करके ब्राउज़र में C# चलाना, JavaScript की आवश्यकता को पूरी तरह समाप्त करना। यह एक प्रूफ ऑफ कॉन्सेप्ट था, और नाम Blazer और Razor का जानबूझकर मिश्रण था — Razor वह टेम्प्लेटिंग इंजन है जिस पर Blazor अंततः बनाया गया।

इस प्रयोग ने इतना उत्साह उत्पन्न किया कि Microsoft ने इसे गंभीरता से लिया। Blazor सितंबर 2019 में ASP.NET Core 3.0 के हिस्से के रूप में शिप किया गया — पहले Blazor Server के रूप में: एक मॉडल जो सर्वर पर आपके C# कोड को चलाता है और ब्राउज़र को UI अपडेट भेजने के लिए रियल-टाइम SignalR कनेक्शन का उपयोग करता है। Blazor WebAssembly ASP.NET Core 3.1 के हिस्से के रूप में मई 2020 में आया, जिसने फ्रेमवर्क में वास्तविक क्लाइंट-साइड एक्जीक्यूशन लाया।

.NET 6 और 7 ने डेवलपर अनुभव को परिष्कृत किया। फिर नवंबर 2023 में रिलीज़ हुए .NET 8 ने रेंडरिंग मॉडल को मौलिक रूप से पुनर्विचार किया, जिसे Microsoft ने फुल-स्टैक वेब UI कहा। स्टैटिक सर्वर-साइड रेंडरिंग, स्ट्रीमिंग रेंडरिंग, इंटरएक्टिव सर्वर, इंटरएक्टिव WebAssembly, और एक नया Auto मोड सभी एक ही प्रोजेक्ट में एक ही छत के नीचे रहने लगे। .NET 9 ने इस आधार पर निर्माण किया और खुरदुरे किनारों को साफ किया।

आज हम यहाँ हैं।

Blazor वास्तव में क्या है

अपने मूल में, Blazor .NET के लिए एक कम्पोनेंट-आधारित UI फ्रेमवर्क है। आप कम्पोनेंट से अपना UI बनाते हैं — C# और HTML मार्कअप के स्व-निहित टुकड़े जो स्थिति बनाए रख सकते हैं, इवेंट्स का जवाब दे सकते हैं, और बड़ी संरचनाओं में बना सकते हैं। यदि आपने React या Vue के साथ काम किया है, तो वह मानसिक मॉडल परिचित लगेगा। मुख्य अंतर यह है कि JavaScript के बजाय आप C# लिखते हैं।

Blazor में कम्पोनेंट .razor फाइलों में लिखे जाते हैं। एक .razor फाइल HTML मार्कअप और C# कोड को Razor सिंटैक्स का उपयोग करके मिलाती है जिसे आप शायद ASP.NET MVC व्यूज़ से जानते हों। एक साधारण कम्पोनेंट इस तरह दिखता है:

@page "/counter"

<h1>काउंटर</h1>
<p>वर्तमान गिनती: @currentCount</p>
<button @onclick="IncrementCount">क्लिक करें</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

JavaScript नज़र नहीं आता। @onclick डायरेक्टिव बटन क्लिक को एक C# मेथड से जोड़ता है। @currentCount एक्सप्रेशन वर्तमान मान रेंडर करता है। जब स्थिति बदलती है, Blazor DOM में क्या अपडेट करना है यह पता लगाता है।

यही मूल है। बाकी सब — रूटिंग, डिपेंडेंसी इंजेक्शन, फॉर्म, HTTP कॉल — इस कम्पोनेंट मॉडल के ऊपर बना है।

रेंडरिंग मॉडल

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

स्टैटिक SSR

सबसे सरल मोड। आपके Razor कम्पोनेंट सर्वर पर HTML में रेंडर होते हैं और वह HTML ब्राउज़र को भेजा जाता है। कोई स्थायी कनेक्शन नहीं, कोई WebAssembly नहीं, और डिफ़ॉल्ट रूप से कोई क्लाइंट-साइड इंटरएक्टिविटी नहीं। यह मूल रूप से वही है जो Razor Pages करता है, लेकिन कम्पोनेंट मॉडल का उपयोग करके।

सामग्री-भारी पेजों, लैंडिंग पेजों, किसी भी चीज़ के लिए उपयोग करें जिसे लाइव इंटरएक्टिविटी की आवश्यकता नहीं है।

इंटरएक्टिव सर्वर

आपका कम्पोनेंट कोड सर्वर पर चलता है। ब्राउज़र और सर्वर के बीच SignalR WebSocket कनेक्शन स्थापित होता है। जब आप एक बटन क्लिक करते हैं या इनपुट में टाइप करते हैं, इवेंट WebSocket के माध्यम से सर्वर तक पहुँचता है, आपका C# चलता है, diff की गणना होती है, और DOM अपडेट ब्राउज़र को वापस भेजे जाते हैं।

लाभ: सर्वर संसाधनों तक पूर्ण पहुँच (डेटाबेस, फाइल सिस्टम, सीक्रेट)। तेज़ प्रारंभिक लोड। छोटा डाउनलोड आकार। WebAssembly सपोर्ट के बिना ब्राउज़र में काम करता है।

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

बिज़नेस-लाइन ऐप्स, इंटरनल टूल्स, ऐसे ऐप्स के लिए उपयोग करें जहाँ ऑफलाइन क्षमता से अधिक सर्वर-साइड डेटा एक्सेस मायने रखती है।

इंटरएक्टिव WebAssembly

.NET रनटाइम ब्राउज़र में डाउनलोड होता है और आपका ऐप पूरी तरह क्लाइंट पर चलता है। प्रारंभिक डाउनलोड के बाद, ऐप पूरी तरह ऑफलाइन काम करता है और हर इंटरएक्शन तुरंत है — UI लॉजिक के लिए कोई सर्वर राउंड-ट्रिप नहीं।

लाभ: वास्तविक क्लाइंट-साइड एक्जीक्यूशन। ऑफलाइन काम करता है। ऐप लोड होने के बाद सर्वर लोड कम।

नुकसान: बड़ा प्रारंभिक डाउनलोड (.NET रनटाइम + आपका ऐप)। धीमा पहला लोड। सर्वर-साइड डेटा तक पहुँचने के लिए API की आवश्यकता।

ऑफलाइन-सक्षम ऐप्स, तत्काल प्रतिक्रिया की आवश्यकता वाले टूल्स, ऐसे परिदृश्यों के लिए उपयोग करें जहाँ UI के लिए सर्वर प्रोसेसिंग की आवश्यकता नहीं है।

Auto मोड

.NET 8 में पेश किया गया। ऐप इंटरएक्टिव सर्वर मोड में शुरू होता है (तेज़ प्रारंभिक लोड, WebAssembly डाउनलोड का इंतज़ार नहीं)। एक बार जब WebAssembly फाइलें बैकग्राउंड में डाउनलोड हो जाती हैं, बाद की विज़िट स्वचालित रूप से WebAssembly मोड में स्विच हो जाती हैं।

यह आपको सर्वर मोड का तेज़ पहला लोड और अंततः WebAssembly का पूर्ण क्लाइंट-साइड एक्जीक्यूशन दोनों देता है। यह समझने में सबसे जटिल मॉडल है, लेकिन कई ऐप्स के लिए व्यावहारिक डिफ़ॉल्ट है।

एक ही ऐप में मोड मिलाना

.NET 8 और बाद में, आप पूरे ऐप के लिए एकल रेंडरिंग मोड तक सीमित नहीं हैं। मार्केटिंग लैंडिंग पेज स्टैटिक SSR हो सकता है; प्रमाणित डैशबोर्ड इंटरएक्टिव सर्वर हो सकता है; डेटा विज़ुअलाइज़ेशन विजेट इंटरएक्टिव WebAssembly हो सकता है। फ्रेमवर्क ट्रांज़िशन संभालता है।

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

Blazor की JavaScript फ्रेमवर्क से तुलना

यदि आपने React, Angular, या Vue से बनाया है, तो शायद यही तुलना आपको उत्सुक करती है।

समानताएं वास्तविक हैं। Blazor का कम्पोनेंट मॉडल जानबूझकर React के जैसा है। आपके पास props (Blazor में Parameters), लोकल स्टेट (@code ब्लॉक में फील्ड), लाइफसाइकल हुक, और वही कम्युनिकेशन पैटर्न है: डेटा नीचे / इवेंट ऊपर। यदि आप React जानते हैं, तो कुछ घंटों में घर जैसा महसूस होगा।

मुख्य अंतर भाषा है। Blazor में आप C# लिखते हैं। आपकी बिज़नेस लॉजिक, वैलिडेशन रूल्स, और डेटा मॉडल आपके Blazor फ्रंटएंड और ASP.NET Core बैकएंड के बीच सभी साझा किए जा सकते हैं। जब आपके पास C# में User क्लास है तो TypeScript में उसे डुप्लिकेट करने की आवश्यकता नहीं।

इकोसिस्टम की खाई वास्तविक है लेकिन कम हो रही है। npm इकोसिस्टम विशाल है। UI कम्पोनेंट के लिए NuGet इकोसिस्टम छोटा है, हालाँकि यह काफी बढ़ा है। किसी विशिष्ट चार्टिंग लाइब्रेरी या ड्रैग-एंड-ड्रॉप विजेट के लिए JavaScript के पास अभी भी अधिक विकल्प हैं। लेकिन अधिकांश बिज़नेस-लाइन एप्लिकेशन के लिए, .NET दुनिया में जो उपलब्ध है वह पर्याप्त से अधिक है।

JavaScript इंटरऑप तब मौजूद है जब आपको इसकी ज़रूरत हो। Blazor आपको C# से JavaScript और JavaScript से C# कॉल करने देता है। ब्राउज़र API के लिए जिनके पास .NET रैपर नहीं है, या जब आप किसी मौजूदा JS लाइब्रेरी का उपयोग करना चाहते हैं, इंटरऑप उपलब्ध है। यह एक परत जोड़ता है लेकिन दर्दनाक नहीं है।

ईमानदार उत्तर: यदि आपकी टीम पूरी तरह JavaScript डेवलपर्स हैं जो एक पब्लिक प्रोडक्ट बना रहे हैं जहाँ SEO, परफॉर्मेंस और npm इकोसिस्टम महत्वपूर्ण हैं, तो JavaScript के साथ रहें। यदि आपकी टीम .NET डेवलपर्स हैं, यदि आप इंटरनल या बिज़नेस-लाइन एप्लिकेशन बना रहे हैं, या यदि फ्रंटएंड और बैकएंड के बीच कोड शेयरिंग आपके लिए मायने रखती है, तो Blazor एक आकर्षक विकल्प है।

आगे बढ़ने के लिए क्या चाहिए

इस सीरीज़ के बाकी हिस्से के लिए आपको चाहिए:

  • .NET 9 SDK — dot.net से डाउनलोड करें
  • एक IDE — Visual Studio 2022 (Community एडिशन मुफ़्त है), C# Dev Kit एक्सटेंशन के साथ VS Code, या JetBrains Rider
  • C# की बुनियादी समझ — क्लास, प्रॉपर्टी, इंटरफेस, async/await

बस इतना। कोई Node नहीं, कोई npm नहीं, कोई webpack नहीं।

आगे क्या है

अध्याय 2 में हम आपका पहला Blazor ऐप स्कैफोल्ड करेंगे, प्रोजेक्ट स्ट्रक्चर देखेंगे, और सुनिश्चित करेंगे कि आप इसे लोकली रन कर सकते हैं। अंत में आपके पास एक काम करता ऐप और हर फाइल क्या कर रही है इसकी स्पष्ट तस्वीर होगी।

वहाँ मिलते हैं।