طراحی یک برنامه وب پویا با Astro

به عنوان یک متا‑فریمورک، Astro.js رویکرد متفاوتی برای توسعه برنامه‌های وب اتخاذ می‌کند. از اینجا با چند تصمیم طراحی بحرانی آغاز کنید.

Astro.js یکی از محبوب‌ترین متا‑فریم‌ورک‌ها برای توسعه‌دهندگان جاوااسکریپت است و این به‌دلیل دلیل منطقی است. Astro ساخت برنامه‌های وب را برای حداکثر اثر با کم‌ترین تلاش نسبتاً آسان می‌سازد. با این حال درک چگونگی کار Astro می‌تواند دشوار باشد، چون از فریم‌ورک‌های جاوااسکریپت سمت‌کلاینت سنتی متفاوت است.

در این مقاله، ما رویکرد عملی به Astro را اتخاذ می‌کنیم. هدف من این است که درک کلی خوبی از نحوه‌ی مدیریت اجزای اساسی توسعه وب توسط این فریم‌ورک مانند صفحات، نقطه‌های پایانی، مسیرها و استقرار برای شما باقی بگذارم. برای مرور کلی بر فریم‌ورک، به معرفی اخیر من دربارهٔ توسعه وب Plug-and-Play با Astro مراجعه کنید.

برنامهٔ نمونه

برنامهٔ لیست کارها یک روش کلاسیک برای بررسی یک پشته فناوری جدید و مشاهده نحوهٔ مدیریت الزامات استاندارد توسعه است. فهرست آنلاین کارها نیاز به مجموعهٔ کوچکی از ویژگی‌ها دارد اما به شما امکان می‌دهد تمام عناصر پایهٔ فهرست‌کردن داده‌ها و انجام عملیات CRUD را بررسی کنید. پس از درک این اصول پایه، امکان افزودن ویژگی‌های جدید بسیار گسترده می‌شود. چه‌طور است ستون‌های کشویی و اسکرول نامحدود اضافه کنیم، یا فهرست کارها را به عنوان یک فید RSS ارائه دهیم؟ این مشکلی نیست به‌محض اینکه نحوهٔ کار پشته فناوری را بفهمید.

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

SPA، MPA، یا چیزی میانی؟

چندین نکته برای طراحی برنامهٔ لیست کارها با استفاده از Astro وجود دارد. یک تصمیم فوری این است که آیا می‌خواهید یک برنامهٔ تک‌صفحه‌ای (SPA) یا برنامهٔ چندصفحه‌ای (MPA) داشته باشید. نوع برنامه‌ای که انتخاب می‌کنید تعیین می‌کند که برنامه چگونه داده‌ها را در سمت کاربر بارگذاری می‌کند.

ویژگی اصلی برنامه‌های تک‌صفحه‌ای (SPA) این است که اکثر (اگر نه تمام) تعاملات توسط کلاینت از طریق ارسال درخواست‌های API در پس‌زمینه هدایت شده و رابط کاربری به‌صورت متناسب به‌روز می‌شود. ایدهٔ برنامهٔ تک‑صفحه‌ای این است که تمام موارد مورد نیاز، از جمله جاوااسکریپت، را بارگذاری کنید و سپس کار را از همانجا انجام دهید. نتیجه در مرورگر در واقع یک کلاینت سنگین یا پرحجم است.

برنامه‌های چندصفحه‌ای (MPA) بیشتر در سنت وب ۱.۰ قرار دارند: مجموعه‌ای از صفحات ایستا که با لینک‌های هیپرتکی متصل می‌شوند. در حالی که برنامه‌های تک‌صفحه‌ای (SPA) مدرن‌تر و پویا هستند، MPA می‌توانند قابل‌اعتمادتر باشند. اگرچه این دو سبک اغلب در مقابل یکدیگر قرار می‌گیرند، واقعیت این است که بسیاری از برنامه‌های مدرن ترکیبی از این دو سبک هستند. هدف این است که نقاط قوت هر یک را به حداکثر برسانیم و ضعف‌های آن‌ها را به حداقل. معمول است که تا حد ممکن محتوا به‌صورت ایستا بارگذاری شود و سپس عناصر پویا در نقاطی که تأثیر دارند اعمال شوند. در هر دو حالت، باید بهترین شیوه‌های مربوط به سبک مورد استفاده را به‌کار ببرید.

به‌هرحال این همان ایده است. اما هر کسی که سعی کرده یک برنامه ترکیبی بنویسد می‌گوید که کار به‌سرعت پیچیده می‌شود! Astro از معماری «جزیره‌ها» (islands) استفاده می‌کند تا فرمت ترکیبی را قابل‌مدیریت‌تر کند. جزیره‌ها به‌صورت اساسی طرح برنامه را به بخش‌های جداگانه تقسیم می‌کنند که سپس می‌توانند با استفاده از بهترین شیوه‌ها برای نوع محتوا بارگذاری شوند.

با در نظر گرفتن برنامهٔ لیست کارها به عنوان مثال، منطقی است که هر محتوای چارچوبی (مانند عناوین) را به‑گونه‌ای رندر کنیم که حداکثر سرعت و سازگاری با سئو را فراهم کند. سپس برای فهرست پویا، گزینه‌های متعددی داریم. می‌توانیم از یک فریم‌ورک واکنشی مانند React در حالت کامل SPA استفاده کنیم؛ در این صورت دارایی‌های مورد نیاز برای کلاینت ارسال می‌شود و سپس داده‌ها از یک API سرور بارگذاری می‌شوند. گزینهٔ دیگر استفاده از همان مؤلفه و پیش‑رندر کردن آن در سرور است که حالت میانی بین SPA و MPA است. گزینهٔ سوم به‌طور کامل استفاده از جاوااسکریپت ساده یا HTMX برای ایجاد و رندر لیست است.

صرف‌نظر از سبکی که انتخاب می‌کنید، Astro بخش زیادی از تفکرات اولیه را برای شما انجام می‌دهد. این ابزار شما را در تصمیم‌گیری دربارهٔ نحوه رندر کردن بخش‌های رابط کاربری راهنمایی می‌کند و سپس امکان استفاده از همان فرایند برای ساخت APIهای سمت‌سرور را می‌دهد.

رندر ثابت یا سمت‌سرور؟

Astro هر دو نوع رندر ثابت و رندر سمت‌سرور را برای صفحات و مؤلفه‌های برنامه‌های وب ارائه می‌دهد. در حالت ثابت، محتوا پیشاپیش در سرور رندر می‌شود و برای کارایی حداکثری در تحویل و نمایش در سمت کلاینت بسته‌بندی می‌شود. در رندر سمت‌سرور (SSR) محتوا به‌صورت زنده برای هر درخواست رندر می‌شود. (رندر ثابت گاهی به عنوان SSG یا تولید سمت‌سرور شناخته می‌شود، در مقایسه با SSR.)

Astro به‌خاطر توانایی خود در تولید نماهای سمت‌کلاینت با استفاده از فریم‌ورک‌های واکنشی مانند React شناخته شده است، اما می‌تواند نیازهای سمت‌سرور مانند نقاط انتهایی API را نیز پشتیبانی کند. در هر دو حالت سؤال ثابت در مقابل SSR مطرح می‌شود. یک نقطهٔ انتهایی یا صفحهٔ تولید شده به‌صورت ثابت در واقع فایلی سخت‌کد شده است که در زمان اجرا ساخته می‌شود و برای هر درخواست همان محتوا را ارائه می‌دهد.

در Astro، صفحات و نقاط انتهایی به‌طور پیش‌فرض بر روی سرور تولید می‌شوند. این پیش‑رندر هدفتان را در ارائه حداکثر کارایی از نظر انتقال داده‌ها و کاهش پردازش سمت کلاینت برآورده می‌کند.

برای یک صفحه یا نقطهٔ انتهایی دستور رندر دینامیک را به‌صورت زیر می‌گویید:

export const prerender = false;

تنظیم هدف استقرار

در نظر داشته باشید که هنگام اجرا در حالت توسعه، به‌دلیل بارگذاری مداوم تغییرات، اثر بارگذاری ثابت را نمی‌بینید. به همین دلیل مهم است که مفهوم «آداپتور» در Astro را ذکر کنیم، که برای آماده‌سازی برنامه شما برای استقرار استفاده می‌شود.

آداپتورها ممکن است ابتدا پیچیده به‌نظر برسند، زیرا شما را مجبور می‌کنند تا مسألهٔ دیگری را در میانهٔ ساخت برنامه خود مدیریت کنید. اما آداپتورها می‌توانند سؤال استقرار را به‌طرزی بسیار ساده کنند. (SvelteKit یک چارچوب دیگر است که از آداپتورها استفاده می‌کند.)

Astro شامل چندین هدف استقرار در ارائه‌دهندگان آداپتور خود است، از جمله Netlify، Vercel و Node. اگر به آن فکر کنید، فقط مؤلفه‌های SSR به آداپتور نیاز دارند. اگر مؤلفه‌ای SSG باشد، در نهایت به یک دارایی ثابت تبدیل می‌شود—یعنی یک صفحهٔ HTML بسته‌بندی‌شده یا یک فایل جاوااسکریپت در مورد نقاط انتهایی.

آداپتورها مسیر واضحی برای استقرار و انعطاف‌پذیری در هدف‌ها فراهم می‌کنند، مشابه انعطاف‌پذیری که Astro هنگام انتخاب یک فریم‌ورک سمت‌کلاینت به شما می‌دهد.

مسیر‌یابی

مانند Next.js، Astro مسیر‌یابی مبتنی بر فایل را فراهم می‌کند. این کار خوب است چون نگاشت URL شما به سادگی با محل قرارگیری فایل‌ها و نام آن‌ها تعریف می‌شود. طبیعتاً Astro همچنین از موارد دیگری مانند پارامترهای مسیر پشتیبانی می‌کند.

در Astro، پوشهٔ /src/pages مسیرهای شما را نگه می‌دارد. بنابراین صفحهٔ اصلی شما به‌صورت زیر تعریف می‌شود:

/src/pages/index.astro

در حالی که URL /test در اینجا خواهد بود:

/src/pages/text.astro

به‌همین ترتیب، مسیرهای نقطهٔ انتهایی شما نیز از همان قرارداد پیروی می‌کنند. می‌توانید یک نقطهٔ انتهایی /data.json به‌صورت زیر تعریف کنید:

/src/pages/data.json.ts

توجه داشته باشید که پسوند .ts در URL حذف خواهد شد. Astro از تمایز .astro در مقابل .ts برای تشخیص اینکه آیا می‌خواهید یک صفحه وب یا یک نقطهٔ انتهایی داشته باشید استفاده می‌کند. Astro همچنین خوشحال است که به‌صورت زیر از جاوااسکریپت بدون نوع استفاده کند:

/src/pages/data.json.js

گاهی اوقات، من جاوااسکریپت بدون نوع را دوست دارم. پس می‌توانید به من شکایت کنید.

HTMX در سمت‌کاربر

خوانندگان دائم می‌دانند که من طرفدار HTMX هستم. حتی می‌توانم پیش‌بینی کنم که این فناوری در آینده‌ای نه‌چندان دور به‌عنوان بخشی از مشخصات HTML اضافه شود.

قبلاً استفاده از Astro همراه با فریم‌ورک‌های سمت‌کلاینت مانند Svelte و React را بررسی کرده‌ام. این بار، علاقمندم ببینم که چگونه با ترکیب HTMX کار می‌کند.

این باید روشی مناسب برای مشاهده هر دو HTMX و چندین قابلیت Astro باشد، مانند صفحات SSG و نقاط انتهایی SSR. البته React، Svelte یا Vue نیز می‌توانند بسیار خوب کار کنند. بخش جذاب HTMX این است که تعاملات مورد نیازمان مانند درخواست‌های AJAX و به‌روزرسانی‌های جزئی نما را بدون خروج از HTML فراهم می‌کند.

ترکیب با قابلیت‌های سمت‌سرور و استقرار Astro، HTMX باید پایهٔ محکمی برای انجام تمام نیازهای ما فراهم کند. امیدواریم بتوانیم چیزهای پیشرفته‌تری همچون اسکرول نامحدود نیز اضافه کنیم. هفتهٔ آینده را برای مقالهٔ بعدی این مجموعه دنبال کنید.