Island Architecture - یه معماری جدید برای توسعه وبسایت

سلام به همه، این اولین مقاله ی منه و سعی دارم به زبان خودمونی و ساده این معماری رو توضیح بدم، خوشحال میشم نظراتتون رو برای بهتر شدن کارم بدونم.
خب قبل از اینکه در مورد این معماری صحبت کنیم بیاید ببینیم اصن چرا باید بریم سمتش. خیلی خلاصه بخوام بگم این معماری اومده که نقض های Server Side Rendering (ssr) رو حل کنه .

مشکلات SSR:

خب همونطور که میدونید این روش میاد صفحه ی html رو سمت سرور generate میکنه و اون رو به همراه javascript مورد نیازش به کلاینت میفرسته تا اونجا hydrate بشه. یعنی این html خشکی که داریم رو بشه باهاش تعامل کرد.مشکلی که اینجا هست اینه که این فرآیند hydrate برای ما یه هزینه ای داره: کاربر نمیتونه با صفحه تعامل داشته باشه تا وقتی که کل js لود و hydrate بشه. اگر این عملیات زمان زیادی طول بکشه، از دید کاربر دکمه ها کار نمیکنن و ui فریز شده (uncanny valley). اگر با next کار کرده باشین احتمالا این مورد رو زیاد تجربه کردین.

خب 18 react و next خودشون اومدن دوتا راه برای این مشکل دادن:

1. به جای فرستادن کل html اون رو به کاربر استریم کنند (streaming ssr)
2. به لطف concurrent mode و suspence ری اکت ۱۸ الان میتونیم به جای hydrate کردن کل سایت اون رو به قسمتای مختلف تقسیم و براساس اینتراکشن کاربر سایت رو به مرور لود و هیدریت کنیم و بخشای مهم تر سایت نیازی نیست منتظر بمونن تا کل js سایت لود و hydrate بشه. (Selective Hydration)

خب این دو تا راه خیلی از مشکلات ssr رو حل کردن اما با این حال بازم حجم js که در نهایت لود میشه هیچ تغییری نمیکنه. در صورتی که خیلی از قسمت های سایت ممکنه اصلا نیازی به js نداشته باشن.

اینجاست که معماری Island Architecture راه حل میده.

بریم سراغ Island Architecture:

به زبان ساده بخوایم بگیم این معماری حرفش اینه : کل html رو استاتیک جنریت میکنه، یعنی دقیقا با صفر کیلوبایت js و داخل این html یه سری placeholder در نظر میگیره برای بخش هایی از سایت که اینتراکشن دارن و نیازه هیدریت بشن.یعنی درواقع میاد تیکه های سایت رو به دو بخش دسته بندی میکنه : بخش های استاتیک و بخش های داینامیک.

بزارین چنتا مثال بزنم:

1. تو یه وبلاگ متن و عنوان یه مقاله کاملا استاتیکه . حتی لیست مقالات هم لینک های html هستند، این بخش ها استاتیک هستند. اما دکمه ی اشتراک یا لایک اون مقاله نیاز به تعامل با کاربر داره پس داینامیک هستند.
2. در یه سایت فروشگاهی، عنوان محصول به همراه توضیحات استاتیک هستند، اما کروسل عکس های محصول، دکمه ی افزودن یه سبد خرید و ... داینامیک هستند.

به بیان دقیق تر این معماری برروی ساخت سایت های استاتیکی که چانک های کوچک js برای تعامل کاربر دارند تمرکز داره.

چطوری با این معماری شروع کنم؟

اگر یه فریم وورک بخواد این معماری رو ساپورت کنه باید دارای سه شرط باشه:

1. بتونه صفحه ی html بدون هیچ جاوااسکرپتی لود کنه.
2. بتونه در این صفحه ی html فضاهایی برای محتوای داینامیک در نظر بگیره
3. قابلیت رندر به صورت isomorphic داشته باشه یعنی بتونه هم سمت سرور و هم سمت کلاینت اجرا بشه.

چند مثال:

1. Marko
2. Astro
3. Eleventy + Preact

آیا این معماری جایگزین SSR میشه ؟

این معماری مزایای زیادی رو به دنیای وب اضافه میکنه مزایایی مثل:

1. پرفورمنس بالاتر :
   js کمتر به معنی TTI (زمان اولین تعامل) کمتر و این به معنی عملکرد بهتره، در مقایسه با فریم وورک ها next یا nuxt این معماری عملکرد خیلی بهتری داره.
2. سئو :
   چون صفحات استاتیک ساخته میشن راحت کراول میشن و در نتیجه این روش عملکرد خوبی در سئو داره.

اما با وجود تمام این خوبی ها این معماری یه نقطه ضعف داره، اگر تعاملات کاربر با بخش های زیادی از سایت باشه -یعنی میزان جاوااسکریپت سایت تو بخش های مختلف اونقدر زیاد باشه که چیزی از بخش های استاتیک نمونه- در اون صورت این معماری عملکرد خوبی نخواهد داشت و شاید استفاده از next گزینه ی خیلی بهتری باشه.همچنین این معماری نسبتا جدیده و شاید نیاز به کار داشته باشه.

در نتیجه هنوز گزینه ی بهتر یا بدتر وجود نداره، ssr و island architecture هردو مزایا و معایب خودشون رو دارن که باید در حین انتخابشون اون ها رو در نظر گرفت.

در ادامه:

در این مقاله سعی کردم به صورت ساده در مورد این معماری صحبت کنم، تو مقاله ی بعدی میخوام یکی از فریم وورک هایی که بهش اشاره شد رو باز کنم و بیشتر در موردش توضیح بدم.

همچنین اگر سوالی داشتید میتونید با ایمیل (r.heydarii98@gmail.com) در ارتباط باشیم. ممنون از همراهیتون