انتخاب رابط کاربری وب (Web UI) برای Asp.Net Core

سه رویکرد کلی برای ایجاد رابط کاربری وب مدرن با ASP.NET Core وجود دارد:

1.برنامه هایی که UI را از سرور ارائه می کنند (SSR) :

• ASP.NET Core Razor Pages
• ASP.NET Core MVC

2.برنامه‌هایی که UI را روی کلاینت در مرورگر ارائه می‌کنند(CSR) :

• Blazor

شما همچنین می توانید برنامه های ASP.NET Core را با استفاده از فریم ورک های محبوب جاوا اسکریپت مانند Angular یا React بسازید. ASP.NET Core قالب های پروژه را برای Angular و React ارائه می دهد و می تواند با سایر فریم ورک های جاوا اسکریپت نیز استفاده شود.

3.برنامه های ترکیبی که از هر دو رویکرد ارائه رابط کاربری سرور و کلاینت بهره می برند(Hybrid) :

• ASP.NET Core MVC plus Blazor

مزایا و معایبی وجود دارد که باید هنگام رندر UI روی سرور، کلاینت و Hybrid در نظر گرفت.

بحث در مورد رندر صفحه وب تنها در سال های اخیر مطرح شده است. پیش از این، وب‌سایت‌ها و برنامه‌های کاربردی تحت وب استراتژی مشترکی برای دنبال کردن داشتند. آنها محتوای HTML را برای ارسال به مرورگرهای سمت سرور آماده می کردند. سپس این محتوا به عنوان یک HTML با یک استایل مبتنی بر CSS در مرورگر ارائه می شد.

با ظهور فریمورک های جاوا اسکریپت(از قبیل Angular،React و Vue.js) رویکردی کاملاً متفاوت برای توسعه وب ایجاد شد. فریمورک های جاوا اسکریپت این امکان را فراهم می کنند که بار سرور را از بین ببرند.

با قدرت فریمورک های جاوا اسکریپت، امکان ارائه محتوای پویا مستقیماً از مرورگر با درخواست فقط برای محتوای مورد نیاز فراهم شد. این تغییر یک تجربه کاربری یکپارچه را به بازدیدکنندگان داد زیرا زمان بسیار کمی برای بارگذاری صفحه وب صرف می شود. علاوه بر این، پس از بارگیری، صفحه وب خود را دوباره بارگیری نمی کند.

رندر سمت سرور (SSR) چیست؟

رندر سمت سرور یا SSR روش مرسوم رندر صفحات وب در مرورگر است. همانطور که در بالا توضیح داده شد، روش سنتی ارائه محتوای وب پویا مراحل زیر را دنبال می کند:

• کاربر درخواستی را به یک وب سایت ارسال می کند (معمولاً از طریق مرورگر)

نمی تواند بر روی CDN  منتشر شود

• سرور پس از عبور از اسکریپت های سمت سرور که در داخل صفحه قرار دارند، منبع را بررسی می کند، محتوای HTML را کامپایل و آماده می کند.
• این HTML کامپایل شده برای رندر و نمایش بیشتر به مرورگر کلاینت ارسال می شود.
• مرورگر HTML را دانلود می کند و سایت را برای کاربر نهایی قابل مشاهده می کند
• سپس مرورگر جاوا اسکریپت (JS) را دانلود می کند و با اجرای JS، صفحه را تعاملی می کند.
  

در این فرآیند تمام بار دریافت محتوای پویا، تبدیل آن به HTML و ارسال آن به مرورگر بر عهده سرور باقی می ماند. از این رو، این فرآیند رندر سمت سرور (SSR) نامیده می شود.

این مسئولیت ارائه HTML کامل از قبل، با باری بر حافظه و قدرت پردازش در سرور همراه است. از این رو، رندر سمت سرور زمان بارگذاری صفحه را در مقایسه با زمان بارگذاری صفحه برای یک سایت استاتیک که در آن محتوای پویا برای رندر وجود ندارد، افزایش می دهد.

رندر سمت مشتری (CSR) چیست؟

رندر سمت مشتری یا CSR یک رویکرد متفاوت برای نحوه پردازش صفحه وب برای نمایش در مرورگر است. در CSR، بار کامپایل محتوای پویا و تولید HTML برای آنها به مرورگر کلاینت منتقل می شود.
این رویکرد با فریمورک ها و کتابخانه های جاوا اسکریپت مانند React، VueJS و Angular پشتیبانی می شود. جریان عادی رندر صفحه وب برای سناریوی رندر سمت کلاینت مراحل زیر را دنبال می کند:

• کاربر درخواستی را به یک وب سایت ارسال می کند (معمولاً از طریق مرورگر)

می تواند بر روی CDN  منتشر شود

• مرورگر HTML و سپس JS را دانلود می کند، در همین حین کاربر نماد بارگیری(loading) را می بیند
• پس از اینکه مرورگر JS را واکشی کرد، درخواست های API را از طریق AJAX برای واکشی محتوای پویا و پردازش آن برای ارائه محتوای نهایی انجام می دهد.
• پس از پاسخ سرور، محتوای نهایی با استفاده از پردازش DOM در مرورگر مشتری ارائه می شود

از آنجایی که این فرآیند شامل واکشی و پردازش داده ها در سمت مشتری است، به این فرآیند رندر سمت مشتری گفته می شود.

از آنجایی که هر دو رویکرد در نحوه پردازش محتوا متفاوت هستند، هر روش مزایای خود را دارد که تصمیم گیری در مورد انتخاب CSR یا SSR را دشوار می کند.

تفاوت بین رندر SSR و رندر CSR از دیدگاه یک کاربر و همچنین وب

تفاوت شماره 1 - زمان بارگذاری صفحه وب
زمان بارگذاری صفحه وب زمانی است که بین ارسال درخواست به سرور و زمان ارائه آن در مرورگر صرف می شود. این یک جنبه مهم در مورد تجربه کاربری (UX) برای وب سایت یا برنامه وب شما است. زمان بارگذاری صفحه وب برای CSR و SSR در دو سناریو متفاوت است:

• زمان بارگذاری اولین صفحه
  زمان بارگذاری اولین صفحه میانگین زمانی است که کاربر برای اولین بار وب سایت شما را بارگذاری می کند. در اولین بارگذاری ، در CSR، مرورگر، HTML پایه، CSS و تمام اسکریپت های مورد نیاز را به یکباره بارگیری می کند و سپس HTML را برای محتوای قابل استفاده در مرورگر کامپایل می کند.
  
  این زمان معمولا بیشتر از دریافت یک HTML از پیش کامپایل شده و اسکریپت های مربوطه از سرور است. بنابراین، SSR زمانی که به زمان بارگذاری صفحه اول می رسد، معمولاً زمان کمتری می گیرد.
• زمان بارگذاری دومین، سومین صفحه و ....
  زمان بارگذاری دومین صفحه میانگین زمان صرف شده برای پیمایش از یک صفحه به صفحه دیگر است. در این سناریو، از آنجایی که همه اسکریپت های پشتیبانی از قبل برای CSR بارگذاری می شوند، زمان بارگذاری برای دومین صفحه و به بعد برای CSR کمتر است (و در نتیجه عملکرد بهتر). درخواستی را به سرور ارسال نمی کند مگر اینکه یک ماژول lazy جاوا اسکریپت بارگذاری شود.

در معنای عام و کلی، لودِ تنبل (Lazy Loading) یا «بارگذاری غیر همگام» به بارگذاری تصاویر به صورت غیر همگام نسبت به بقیه ی محتوای وب سایت گفته می شود. این یعنی تنها پس از آن که قسمت «چشم انداز اولیه» ی وب سایت شما کاملا بارگذاری شد و محتوا به مخاطب نمایش داده شد، مرورگر شروع به دانلود تصاویر کند.

با این حال، برای SSR، چرخه درخواست کامل دنبال شده در بارگذاری اولین صفحه تکرار می شود. این بدان معناست که وقتی صحبت از SSR به میان می‌آید، تقریباً تأثیری بر زمان بارگذاری صفحه وب وجود ندارد. بنابراین، در این سناریو، CSR سریعتر پاسخ می دهد.

در اینجا ذکر این نکته ضروری است که استنتاج فوق جنبه های شبکه (پهنای باند سرویس گیرنده و سرور و ... )را به طور عمیق در نظر نمی گیرد.

تفاوت شماره 2 - تأثیر ذخیره سازی
ذخیره سازی اطلاعات در حافظه پنهان(Cache) به نیاز روز تبدیل شده است. برای سرعت بخشیدن به برنامه های کاربردی وب سنگین، هر مرورگر و همچنین وب سرور از مکانیسم های Cache برای ذخیره اسکریپت های قابل استفاده مجدد در دستگاه کلاینت استفاده می کند. این به طور کلی زمان بارگذاری را برای CSR و همچنین SSR بهبود می بخشد. با این حال، یک مزیت عمده برای CSR در دسترس است.

در CSR، تا زمانی که بارگذاری ماژول Lazy Loading مورد نیاز نباشد، عملاً برنامه های وب مبتنی بر CSR می توانند بدون اینترنت نیز اجرا شوند! (مگر اینکه یک API برای دریافت داده ها صدا زده شود). پس از بارگذاری، برنامه دیگر نیازی به ارسال درخواست به سرور ندارد. این اجازه می دهد تا برنامه وب، درست مانند یک برنامه دسکتاپ ساده، پیمایش شود.

اما در SSR، درخواست به سرور همیشه ارسال می شود. از این رو، زمان بارگذاری صفحه بدون شک برای SSR در مقایسه با CSR بیشتر است. حافظه پنهان سرعت رندر محتوا را حتی برای SSR بهبود می بخشد زیرا اسکریپت ها توسط مرورگر از حافظه پنهان بازیابی می شوند.

تفاوت شماره 3 - تأثیر بر سئو
برای یک وب سایت تجاری، بهینه سازی آن برای موتورهای جستجو ضروری است. موتورهای جستجو وب سایت های شما را با استفاده از ربات های خودکار به نام خزنده می خوانند و درک می کنند. این خزنده ها بیشتر به ابرداده های(MedaData) وب سایت شما علاقه مند هستند تا محتوای واقعی. از این رو، بسیار مهم است که صفحه وب شما منعکس کننده ابرداده مناسب برای موتورهای جستجو باشد.

با CSR، محتوای صفحه وب به صورت پویا با استفاده از جاوا اسکریپت تولید می شود. این بدان معناست که تغییر ابرداده از یک صفحه به صفحه دیگر به اجرای جاوا اسکریپت بستگی دارد. در گذشته موتورهای جستجو ترجیح می دادند که جاوا اسکریپت را در حالی که خزنده ها در سایت ها خزیده بودند اجرا نکنند. با این حال، با پذیرش گوگل برای اجرای جاوا اسکریپت، روند در حال تغییر است.

با CSR، باید تلاش بیشتری کنید تا مطمئن شوید که ابرداده صفحه از یک صفحه به صفحه دیگر تغییر می کند. این امر مستلزم استفاده از پلاگین هایی مانند React Helmet برای ReactJS و استفاده از ماژول های کتابخانه مانند Meta از @angular/browser library برای فریم ورک Angular است. شما باید تلاش بیشتری کنید تا متادیتا برای هر صفحه تنظیم شود و آن را در سمت کلاینت ارائه دهید.

با SSR، صفحه کامل با ابرداده مناسب کامپایل می‌شود و تنها پس از دریافت محتوای نهایی HTML به فرانت‌اند ارسال می‌شود. این تضمین می کند که ابرداده صفحه همیشه دقیق است، صرف نظر از اینکه خزنده اجازه استفاده از جاوا اسکریپت را می دهد یا خیر. این امر SSR را در مقایسه با CSR راه حل بهتری برای صفحات بهینه شده برای موتورهای جستجو می کند.

چه زمانی از رندر سمت کلاینت و رندر سمت سرور استفاده کنیم؟

انتخاب های کمتر همیشه ساده ترین هستند. سال ها شما یک انتخاب واحد داشتید : SSR. با ورود CSR این سوال مطرح می شود که کدام یک برای برنامه یا وب سایت شما مناسب است. اجازه دهید بفهمیم که هر یک از آنها در کجا مفید است.

سناریوی شماره 1 - بارگذاری محتوای پویا
یک سرور معمولاً روی دستگاهی با قدرت محاسباتی بالاتر و سرعت شبکه به طور قابل توجهی بالاتر قرار دارد. با این سرعت و قدرت، واکشی محتوا در سمت سرور نسبتا سریعتر می شود.

از طرف دیگر، ماشین‌های کلاینت قدرت محاسباتی محدودی دارند و ممکن است برای واکشی و ارائه محتوای پویا در سمت کلاینت زمان بیشتری طول بکشد. این بدان معناست که زمان کلی صرف شده برای ارائه محتوا بیشتر خواهد بود. بنابراین، اگر وب سایت شما شامل رندر محتوای پویای مکرر است، SSR انتخاب بهتری نسبت به CSR است.

سناریوی شماره 2 - UX برنامه کاربردی وب(Web Application) در مقابل UX وب سایت(Web Site)
اگرچه آنها تقریباً یکسان به نظر می رسند، برنامه های کاربردی وب و وب سایت ها دو قالب متفاوت از محتوای وب هستند. Web Application یک برنامه کاربردی کامل است که می تواند برای اهدافی مانند حسابداری، CRM، مدیریت منابع انسانی، مدیریت پروژه، داشبورد مدیریت و غیره مورد استفاده قرار گیرد. از طرف دیگر یک Web Site مثلا با محتوای آموزشی در مورد یک کسب و کار است.

یک برنامه کاربردی وب یا همان Web Application شامل تعامل بسیار بیشتری با کاربر در مقایسه با یک وب سایت است زیرا کاربر وارد کردن داده ها و تولید گزارش در یک Web Application را انجام می دهد. در سناریویی که تعامل کاربر بیشتر است، اطمینان از اینکه کلیک‌ها طولانی نمی‌شوند بسیار مهم است. بنابراین، CSR در مقایسه با SSR برای برنامه های کاربردی وب بهتر عمل می کند.

از سوی دیگر، برای یک وب‌سایت، اگر صفحه وب جدید با هر کلیک بارگیری شود، کلاینت مشکلی ندارد زیرا حافظه پنهان معمولاً سرعت رندر را افزایش می‌دهد. علاوه بر این، SSR همچنین متادیتای مناسب را برای خزنده‌ها تضمین می‌کند – این امر SSR را برای وب‌سایت‌ها در مقایسه با CSR بهتر می‌کند.

بهترین های هر دو جهان(Hybrid) !!!
پس از بررسی موارد بالا، ممکن است تعجب کنید که آیا راهی برای دریافت مزایای بارگیری سریع SSR و عملکرد بهتر SEO با احساس تقریباً بومی CSR وجود دارد؟ فریمورک هایی وجود دارند که روی یک رویکرد ترکیبی مانند گتسبی(Gatsby) کار می کنند.

کاری که Gatsby اساسا انجام می دهد این است که در حالی که صفحه اول همیشه با SSR بارگذاری می شود، صفحات دیگر را پس از بارگیری در حافظه پنهان ذخیره می کند. بنابراین، بقیه صفحات از قبل رندر شده و ذخیره شده اند و این احساس را به شما می دهد که از رویکرد CSR در صفحات بعدی استفاده می کنید!

گتسبی یک فریمورک Open Source مبتنی بر React برای ایجاد وب سایت ها و وب اپلیکیشن ها است.

اما با Gatsby دقیقا چه اتفاقی می افتد؟

اول بیایید با مفهوم SSG(Static Site Generator/Server Side generator) آشنا شویم

با استفاده از SSG صفحات HTML از یک منبع محتوای مشخص ایجاد می شود. از این وب سایت تکمیل شده، به یک سایت ایستا یاد می شود. این بدان معناست که صفحات وب سایت در زمان ساخت (build) ایجاد می شوند و محتوای آنها تغییر نمی کند مگر اینکه محتوای جدید را به آن اضافه کنید و سپس آن را بازسازی (rebuild) کنید.

یکی از معروف ترین SSG ها، فریمورک Gatsby است.

نقاط قوت

• سرعت : از آنجایی که تمام صفحات و محتوای وب سایت شما در زمان ساخت تولید می شود، لازم نیست نگران تماس های API به سرور برای محتوا باشید، که وب سایت شما را بسیار سریع می کند.
• گسترش : هنگامی که سایت استاتیک شما ایجاد شد، فایل های ثابت برای شما باقی می ماند. از این رو، می توان آن را به راحتی در پلتفرمی مانند Netlify مستقر کرد.
• امنیت : یک سایت تولید شده استاتیک فقط شامل فایل های ثابت است، بدون هیچ پایگاه داده ای که مهاجم بتواند با تزریق کد مخرب از آن بهره برداری کند. بنابراین، آسیب پذیری در برابر یک حمله سایبری حداقل است.
• کنترل نسخه : می توانید از نرم افزارهای کنترل نسخه (مانند Git) برای مدیریت و ردیابی تغییرات محتوای خود استفاده کنید. هنگامی که می خواهید تغییرات ایجاد شده در محتوا را به عقب برگردانید، این کار مفید است.
• به راحتی بر روی CDN  ها منتشر می شود

نقاط ضعف

• اگر محتوا خیلی سریع تغییر کند، ادامه دادن به آن دشوار است.
• برای به روز رسانی محتوا، باید وب سایت را بازسازی کنید.
• زمان ساخت با توجه به اندازه برنامه افزایش می یابد.

جمع بندی خیلی خلاصه و کلی

از SSR زمانی استفاده کنید که :

• سرعت(تنها در لود اولیه سریعتر از CSR است) و سئو مهم باشد (برای ساخت وب سایت ها مثلا با محتوای آموزشی در مورد یک کسب و کار)

شما اساساً برنامه خود را دو بار رندر می کنید، یک بار در سرور و یک بار در کلاینت، بنابراین اگر برنامه شما بسیار بزرگ باشد، این می تواند بر زمان بارگذاری بین صفحات تأثیر بگذارد.

• انتشار بر روی CDN مهم نباشد.
• ایحاد صفحات ومحتوای بروز آن در هر ریکوئست مهم باشد
• وب سایت شما شامل رندر محتوای پویای بصورت مکرر است(محاسبات بالا)

تاخیر : از آنجایی که سرور در حال انجام کار رندر است، اگر کاربران زیادی به طور همزمان به برنامه دسترسی داشته باشند، ممکن است در بارگذاری برنامه با تاخیر مواجه شوند.

از CSR زمانی استفاده کنید که :

• سرعت مهم(بصورت میانگین بیشتر از SSR) اما سئو مهم نیست (ساخت وب اپلیکشین ها برای اهدافی مانند حسابداری، CRM، مدیریت منابع انسانی، مدیریت پروژه، داشبورد مدیریت و ... )
• انتشار بر روی CDN مهم باشد.
• برای Single Page Application یا همان SPA عالی است. هیچ مدل دیگری از SPA پشتیبانی نمی کند.(به ما امکان می دهد تا از اجزای UI در سراسر برنامه خود استفاده مجدد کنیم، بدون اینکه دوباره آنها را از سرور درخواست کنیم. این به ماهیت سریع و کارآمد CSR مرتبط است.)

نکته امنیتی : در مقایسه با صفحات سنتی Single Page Application ها به دلیل اسکریپت بین سایتیCross-site scripting (XSS) امنیت کمتری دارند. مراقب آن باشید!

• نمی خواهید درگیر مشکلات سازگاری UI که در تولید سمت سرور(SSR/SSG) وجود دارد شویم.

نکته Memory Leak (نشت حافظه): نشت حافظه در جاوا اسکریپت حتی می تواند باعث کند شدن سیستم قدرتمند شود. مراقب آن باشید!

از SSG زمانی استفاده کنید که :

• سرعت(فوق العاده سریع) و سئو مهم باشد (برای ساخت وب سایت ها)

اگر سایت شما خیلی بزرگ و پیچیده باشد، زمان ساخت صفحات می تواند بسیار طولانی باشد.

• انتشار بر روی CDN مهم باشد.
• ایحاد صفحات ومحتوای بروز آن در هر ریکوئست مهم نباشد( همه چیز در زمان build و نهایتا با انجام زمانبدی ساخته می شوند)

نتیجه

حالا می دانیم که CSR و SSR و SSG برای UXی که قصد دارید به کاربر خود ارائه دهید بسیار مهم هستند. امیدوارم این مطلب به شما در درک این مفاهیم از دیدگاه کاربردی کمک کرده باشد. انتخاب نهایی در نهایت با شماست. با در نظر گرفتن عوامل فوق عاقلانه انتخاب کنید. انتخاب نادرست ممکن است برای شما هزینه ایجاد مجدد کل وب سایت یا برنامه وب را نیز در پی داشته باشد.

بیشتر بخوانید : نقشه راه توسعه دهندگان Asp.NET Core

https://zarinp.al/farshidazizi