JAMStack چیست؟ یک معماری انقلابی؟

زمانی که بحث توسعه تحت وب مطرح میشه، ترکیب تکنولوژی و ابزارهای مختلفی هستند که میشه از بینشون انتخاب کرد. این ترکیب‌های مختلف رو به اسم Web Stack می‌شناسیم. هر وب استک شامل یک سیستم عامل، یک وب سرور ، یک نرم افزار مختص دیتابیس و زبان برنامه نویسی برای بخش فراند-اند و بک-اند میشه.

وب استک‌های زیادی هستند که توسعه دهنده می‌تونه با توجه به نیازش و مهارتش از بینشون انتخاب کنه:

LAMP Stack: Linux - Apache - MySQL - PHP (Pearl , Phython)

MEAN Stack: Mongo - Angular - Express - Node

MERN Stack: Mongo - React - Express - Node

اما مدتی میشه که انگار سر و کله ی یه تازه وارد پیدا شده و کلی هم سر و صدا به پا کرده، خیلی هم دوروبرش شلوغ شده و همه دارند در موردش سوال میپرسند و میخوان بدونند که چه فرقی با بقیه داره؟ توی چه چیزهایی بهتره و کجاها بهتر استفاده میشه؟

JAMStack دقیقا چیه؟

در واقع JAMStack بیشتر از اینکه یه ترکیبی از ابزار باشه، یک معماری جدید و مدرن برای ساخت وب سایت و وب اپلیکیشن هاست.

گذشت زمانی که وب‌سایت‌های استاتیک فقط یه فایل HTML بودند با یسری CSS و جاوا اسکریپت کنارشون که بهترین حالت فقط ازشون میشد برای سایت رزومه و وبلاگ شخصی استفاده کرد. امروزه ما وب‌سایت های استاتیکی داریم که به شکل Realtime با کاربر تبادل اطالاعات می‌کنند، میتونند فرایند خرید و پرداخت مالی رو انجام بدند و . . .

اینکه بخوایم همچنان این نوع وبسایت های جدید رو با اسم "استاتیک" صدا بزنیم، یجورایی انگار داریم ارزش واقعی کاری که دارند انجام میدند رو کمتر جلوه میدیم. برای همین شد که اولین بار Mathias Billmann بنیانگذار وبسایت Netlify از اصطلاح و کلمه ی JAMStack استفاده کرد.

الان شاید براتون سوال باشه، خب یعنی پس ما هر زمان داشتیم سایت استاتیک می‌نوشتیم تماما داشتیم با JAMStack سر و کله میزدیم؟

در واقع کلمه‌ی JAM ، از حروف اول سه کلمه‌ی JavaScript , API , Markup ساخته شده، جالب شد نه؟

جاوا اسکریپت: یک برنامه کامل که مسئولیت ارسال درخواست‌ها و دریافت جواب‌ها رو به شکل کامل انجام بده و "تماما" در سمت کاربر اجرا بشه.

یک API: تمام فعالیت‌های بخش سرور و دیتابیس، توسط یک API از طریق HTTPS و با کمک JavaScript انجام میشه. این API میتونه شخصا نوشته شده باشه، میتونه SaaS باشه یا برای هر شرکت سومی باشه.

فایل Markup: فایل‌های مارکاپ که در زمان نوشتن برنامه، پیش نویس میشند و زمان اجرای برنامه توسط یک Static Site Generator ( مثل Gatsby ) در سمت کاربر بازسازی و اجرا می‌شند.

خیلی هم عالی! اما خب یعنی چی؟

برای یه مدت خیلی طولانی، استفاده از CMS ها بین توسعه دهنده‌های وب خیلی رایج بود. مسیر طراحی و توسعه نسبتا سر راستی داشت و به مشتری‌ها هم این امکان رو میداد که راحتتر محتوای خودشون رو کنترل کنند.

اما خب این مسئله تقریبا برای 5 سال پیش بود! تعداد خیلی زیادی از توسعه دهنده‌ها از اون زمان سعی کردند مسیر خودشون رو از CMS ها جدا کنند. کم کم متوجه این موضوع شدند که CMS های سنتی ( مثل وردپرس و دراپال ) یجورای خب ... خیلی داستان رو شلوغش کردند .. ?

کم کم این موضوع بیشتر حس شد که چقدر سنگین و بدون انعطاف و خشک هستند و اون پیشخوان ادمین مثلا کاربرپسندشون به مرور زمان کمتر پسندیده می‌شد..

با تشکر از مرورگر‌های مدرن امروزی، میبینیم که با کمک CDN ها و API ها و Static Site Generator ها ، داریم از برنامه‌های داینامیک سمت سرور به سمت برنامه‌های ماژولار سمت کاربر میریم.

جم-استک یک انتقال اساسی نگاه و تمرکز از بخش انتزاعیه بک-اند به سمت قدرتمند فرانت-اند محسوب میشه

با کمک JAMStack ما دیگه در مورد تکنولوژی‌های مختلف و سیستم عامل‌ها و وب سرورها و برنامه‌های سمت سرور و دیتابیس صحبت نمیکنیم. این یه روش جدیده که میشه با کمکش وبسایت و اپلیکیشن‌هایی رو ساخت که سبکتر هستند و قدرت اجراییشون بالاست، امنیت بالاتری دارند و هزینه اجرا و توسعه ـشون بسیار کمتره.

در حال حاضر، بیشترین نوع توسعه وب اینجوریه که یک بخش فرانت-اند با سرور چفت شده، مثلا node.js و هر درخواستی که داده میشه باید از سرور رد بشه تا بتونه اطلاعات رو از دیتابیس بگیره، اونو به HTML تبدیل کنه و از طریق شبکه بفرسته.

درسته که میشه این فرایند رو بهتر کرد، ولی چرا برای هر درخواست هی صفحه رو دوباره بسازیم؟ حتی زمانی که یک صفحه دوبار فراخوانی میشه؟ نمیشه یکبار فایل HTML رو بازسازی کنیم و به تمام درخواست‌ها جواب بدیم؟

این دقیقا کاریه که JAMStack انجام میده! در معماری JAMStack، یک درخواست صفحه برای دریافت HTML به سرور نمیره، در عوض html ای که توسط Static Site Generator تولید شده رو از یک CDN "دانلود "میکنه و هیچ سروری توی این مسیر وجود نداره!

چرا JAMStack؟

چون سریعتره: از اونجایی که فایل های HTML از پیش ساختند، پس دیگه لازم نیست درگیر دریافت اطلاعات از دیتابیس و ساخت HTML حین runtime بشیم. فایل html روی یک CDN بازگذاری شده که "نزدیک" به محل کاربره و خیلی سریع میتونه "دانلود" بشه. از اونجایی که html یه فایل استاتیکیه که از یک لینک دانلود شده، خیلی راحت cache میشه و تا زمانی که توسط توسعه دهنده فایل آپدیت نشه، این فایل در cache میمونه.

چون امن‌تره: وب سایت‌ها و اپلیکیشن‌های JAMStack از نظر امنیت خیلی خیال مارو راحت می‌کنند. از اونجایی که هیچ سرور و دیتابیسی در کار نیست، لازم نیست نگران حمله و هک سرورها بخوایم بشیم. ( با فرض رعایت تمام نکات امنیتی به شکل صحیح حین نوشتن برنامه )

چون ساده‌تره: توسعه دهنده‌های فرانت-اند میتونند با خیال راحت تمرکزشون رو روی تجربه کاربری (UI) بذارند بدون اینکه بخوان درگیر دیتابیس و سرور بشند.

چون ارزونتره: از اونجایی که هیچ سروری لازم نیست! یک CDN میتونه خیلی خوب از پس تحویل فایل‌ها و اطلاعات بر بیاد و چون CDN ها فقط دستور "خوانش" رو انجام میدند و عمل "نوشتنی" وجود نداره میتونند تعداد درخواست بالاتری رو پاسخگو باشند و از طرف دیگه لازم نیست ما نگران ترافیک بالای وبسایت باشیم چون CDN ها مقیاس پذیر هستند.

جریان کار سنتی در مقابل JAMStack:

جریان کار سنتی/رایج:

--> ساختن و میزبانی چفت شدست و یکجا انجام میشه

--> کاربر درخواست یک صفحه رو میده. فایل ها بعد از یک سری فعل و انفعال (نسبتا طولانی) بین سرور و دیتابیس و کدهای بک-اند و مرورگر پردازش میشند.

--> اپدیت‌های اساسی هسته‌ی کد باید (غالبا) از طریق FTP به سرور ارسال بشند و خود دیتابیس نیاز به نگهداری و آپدیت داره.

--> تولید و مدیریت محتوا از طریق CMS های سنتی مثل Wordpress یا Drupal انجام میشه.

جریان کار JAMStack:

--> ساخت و میزبانی فایل‌ها از هم جداست.

--> کاربر درخواست یک صفحه رو میده. فایل به شکل کامل کامپایل شدست و مستقیما به مرورگر کاربر از طریق CDN ارسال میشه

--> آپدیت‌های اساسی هسته‌ی کد از طریق Git انجام میشه؛ کل سایت با کمک ابزارهای مدرن مثل SSG ها کاملا بازسازی میشه.

--> تولید و مدیریت محتوا از طریق Git و یا Headless CMS ها انجام میشه ( Headless CMS رو شاید بعدا یک مقاله براش نوشتم )

شروع کار با JAMStack:

اگر به تازگی با کل ایده‌ی JAMStack آشنا شدید، احتمالا الان حس سرگردونی خیلی زیادی دارید. اینکه متوجه بشید از کجا باید شروع کرد شاید سخت ترین قسمت قضیه باشه.

در درجه‌ی اول، یادتون باشه که ما داریم در مورد توسعه " فرانت-اند محور " صحبت می‌کنیم. اگر درکل در دنیای توسعه وب تازه کار هستید، حواستون باشه که باید توانایی جاوا اسکریپتتون رو تا جایی که می‌تونید بالا ببرید!

از طرف دیگه، تا جایی که می‌تونید در مورد API ها و ابزارهایی که میشه باهاشون کار کرد یاد بگیرید. قدرت مانورتون توی کار با API میتونه سطح پروژه هاتون رو به مرحله بالاتری منتقل کنه.

پروژه‌ی جدید:

شروع کردن از ابتدای داستان همیشه بهترین راه برای درک و ساخت یه JAMStack ـه "خالصه". اینجوری می‌تونید ذره ذره پیش برید و تیکه های ضروری که برای ساختن لازم دارید رو کنار هم قرار بدید. همونطور که قبلا گفتیم، ساخت و میزبانی از هم کاملا جداست، پس در قدم اول باید تصمیم بگیرید که سایت یا اپلیکیشنتون رو با چی میخواید بسازید؟

اکوسیستم‌های مدرنی که برای بخش فرانت-اند وجود داره یکم کارتون رو سخت می‌کنه. نه بخاطر کم بودن ابزارها، راستش دقیقا برعکس! هزاران هزار امکان مختلف وجود داره که میشه ازشون استفاده کرد؛ حتی با اینکه بعضی‌هاشون کمی بیشتر شناخته شدند.

فریمورک‌های معروف جاوا اسکریپت

جاوا اسکریپت امروزه دیگه همه جا هست! و بیشترین جایی که میشه این رو حس کرد، پیشرفتیه که این سه غول دنیای فرانت-اند توی چندسال اخیر داشتند. اونها دنیای وب سایت‌ها رو طوری پیشرفت دادند که الان ما داریم در مورد Single-page-app ها و Progressive Web App ها و نرم افزارهای موبایل تحت وب حرف میزنیم و فکر میکنیم.

بسیار بسیار تاکید میشه که قبل از انتخاب کردن یکی از این فریمورک‌ها، حتما جاوا اسکریپت رو بخوبی یاد بگیرید. و همچنین سعی کنید این فریمورک‌ها رو قبل از اینکه بخواید وارد دنیای Static Site Generator ها بشید یاد بگیرید.

برای مثال Gatsby با React کار میکنه و بهتر اینه که قبل از یادگیری گتسبی، به ری-اکت مسلط باشید.

تولید کننده‌ی سایت استاتیک

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

اون فریمورک‌های معروف جاوا اسکریپت که در بالاتر اشاره شد میشه گفت باعث تولید معروف ترین SSG های حال حاضر شدند. Gatsy و Next برای React و همچنین Next و Gridsome برای Vue. این SSG ها در حال حاضر دارند به طرز شگفت آوری قلمروی Static Site Generator ها رو پیشرفت میدند.

Headless CMS ها برای مدیریت بهتر

اینکه Headless CMS ها دقیقا چی هستند و چه تفاوتی های با CMS های سنتی مثل وردپرس دارند، خودش واقعا میتونه موضوع یک مقاله مفصل باشه، اما در کل بخوام بگم، این نوع CMS ها خوبی های یک سیستم کنترل محتوا رو دارند و بدی ‌هاش رو حذف کردند.

توی این نوع CMS ها بخش فرانت-اند و بک-اند کاملا از هم جداست و به هم از طریق API متصل هستند. سعی کردم خیلی ساده بگم .. ( آیا میشه Wordpress رو هم Headless کرد؟ آری .. ? )

با کمکشون، میشه خیلی راحت‌تر کاربرها رو مدیریت کرد، یکسری ادیت ها انجام داد و خب مسلما.. محتوا تولید کرد .. ?

انتشار و گسترش - امکانات بیشتر با کمک سرویس‌های SaaS

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

وبسایت‌های ساخته شده با این معماری خیلی خیلی هایپر-داینامیک‌تر از وبسایت‌های استاتیک هستند. با کمک اکونومی API ها و سرویس‌های مختلفی که وجود داره میتونید اپ/وبسایتتون رو با چند کلیک تبدیل به یک پروژه بزرگ کنید.

در این مقاله دیدیم که JAMStack چیه و چرا می‌تونیم از این معماری برای پروژه‌های بعدیمون استفاده کنیم. مسلما این معماری جای پیشرفت بسیار بسیار زیادی داره و روز به روز هم داره به تعداد مخاطب‌هاش اضافه میشه.

این معماری ابعاد زیادی داره که هرکدومش میتونه مبحث یه مقاله تمام عیار باشه، Headless CMS ها یا Static Site Generator ها ، یا حتی اینکه چطور وبسایت قدیمی حال حاضرمون رو تبدیل به این معماری کنیم؟

نوشته‌های دیگه‌ی من