اپیزود شش - Headless

در این اپیزود از پادکست، به یکی از مهم‌ترین اصول طراحی نرم‌افزار، یعنی "جداسازی نگرانی‌ها" (Separation of Concern) می‌پردازیم. این اصل بنیادی، هر بخش از یک سیستم نرم‌افزاری را مکلف می‌کند تا تنها بر یک دغدغه‌ی مشخص تمرکز کند. در ادامه، به بررسی چگونگی اعمال این اصل در معماری‌های مدرن نرم‌افزاری، به ویژه تفکیک لایه‌های Business Logic و Presentation، خواهیم پرداخت. سپس، وارد دنیای Headless CMSها می‌شویم که تجلی استاندارد این رویکرد در پروژه‌های نرم‌افزاری امروزی هستند. در طول اپیزود، به بررسی انواع headless cms ها و بررسی سوال های زیر میپردازیم :

Headless CMS چیست و چه کاربردی دارد؟

چگونه این سرویس‌ها می‌توانند به افزایش سرعت پیاده‌سازی پروژه‌های نرم‌افزاری کمک کنند؟

و در نهایت، چه قابلیت‌ها و محدودیت‌هایی را می‌توانند برای یک پروژه به ارمغان بیاورند؟ با ما همراه باشید تا درک عمیق‌تری از این معماری نوین به دست آورید.

متن اپیزود :

مقدمه

یکی از مهم‌ترین اصول در طراحی نرم‌افزار، اصلی است با نام Separation of Concern یا «جداسازی نگرانی‌ها». هدف این اصل آن است که هر بخش از یک سیستم نرم‌افزاری، تنها بر یک دغدغه‌ی مشخص متمرکز باشد.

در معماری‌های مدرن نرم‌افزاری، جداسازی لایه‌ی Business Logic (منطق کسب‌وکار) از لایه‌ی Presentation (رابط کاربری که مستقیماً با کاربر نهایی در تعامل است)، دقیقاً در راستای همین اصل عمل می‌کند.

این رویکرد امروز به یک استاندارد در توسعه‌ی نرم‌افزار تبدیل شده و معمولاً با اصطلاح Headless Architecture از آن یاد می‌شود.

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

1. Headless CMSها دقیقاً چه هستند و چه کاری انجام می‌دهند؟

2. این سرویس‌ها چگونه می‌توانند به افزایش سرعت پیاده‌سازی یک پروژه نرم‌افزاری کمک کنند؟

3. و در نهایت، این سرویس‌ها چه قابلیت‌ها و چه محدودیت‌هایی را به یک پروژه اعمال می‌کنند؟

بخش اول – معرفی اپیزود

سلام، من محمد هستم و این اپیزود ششم از پادکست کُدشناسی است.

در هر اپیزود از این پادکست، معمولاً به یک چالش، موقعیت یا جستار فکری در دنیای مهندسی نرم‌افزار می‌پردازم و کمی روی آن مکث می‌کنم.

موضوع این اپیزود سرویس‌هایی‌ است که با عنوان Headless CMS شناخته می‌شوند.

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

بخش دوم – مقدمه‌ای بر مفهوم Headless

اصطلاح "هدلس" نخستین بار در دهه‌ی ۱۹۹۰ میلادی برای اشاره به سرورهایی بدون رابط گرافیکی استفاده شد. این سرورها که با نام Headless Server شناخته می‌شدند، بدون مانیتور، کیبورد یا ماوس کار می‌کردند و معمولاً تنها از طریق SSH قابل کنترل بودند. هدف از این طراحی نیز دستیابی به عملکردی بهینه در محیط‌های سروری بود، از طریق حذف کامل واسط کاربری.

در ده پانزده سال گذشته، با رشد سریع استفاده از موبایل و سایر دستگاه‌های هوشمند، شرکت‌ها و پروژه‌های نرم‌افزاری بزرگ دنیا مثل Amazon، Netflix و بسیاری دیگر، متوجه شدند که در حال از دست دادن بخشی از کاربران هستند؛ کاربرانی که دیگر ترجیح می‌دادند با گوشی‌های هوشمند کار کنند.

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

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

اینجا بود که اصطلاح Headless بیش از گذشته شنیده شد.

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

این ساختار، علاوه بر ایجاد تجربه‌ی کاربری یکپارچه در کانال‌های مختلف، گامی اساسی در جهت جداسازی نگرانی‌ها (Separation of Concern) به حساب می‌آید.

معماری Headless امروز به‌صورت گسترده در پروژه‌های نرم‌افزاری مدرن به کار گرفته می‌شود. اما ماجرا همین‌جا تمام نمی‌شود!

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

حالا برویم سراغ پرسش‌هایی که در ابتدای اپیزود مطرح کردم.

بخش سوم – Headless CMSها دقیقاً چه هستند و چه کاری می‌کنند؟

Headless CMSها سیستم‌هایی برای مدیریت محتوا هستند، مشابه سیستم‌های قدیمی مثل WordPress یا WooCommerce. اما تفاوت کلیدی آن‌ها این است که Headless CMSها تنها روی مدیریت و ذخیره‌ی محتوا تمرکز دارند و هیچ رابط نمایشی به‌صورت پیش‌فرض ارائه نمی‌کنند.

این یعنی توسعه‌دهندگان می‌توانند از طریق APIهای ارائه‌شده توسط CMS – چه RESTful چه GraphQL – به محتوا دسترسی داشته باشند و آن را در هر نوع فرانت‌اندی (React، Vue، Angular، Next.js و ...) نمایش دهند.

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

بخش چهارم – سرعت در توسعه با کمک Content Types

برای پاسخ به پرسش دوم، که Headless CMSها چگونه به افزایش سرعت توسعه کمک می‌کنند، باید به یکی از مهم‌ترین قابلیت‌های آن‌ها اشاره کنم: Content Types.

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

اما با قابلیت Content Types، شما می‌توانید از طریق پنل مدیریتی Headless CMS، دقیقاً مانند طراحی جدول در پایگاه داده، ساختار دلخواه خود را بدون نیاز به کدنویسی ایجاد کنید.

برای مثال، برای راه‌اندازی یک بخش وبلاگ، کافی است جدول "پست‌ها" را تعریف کنید و انواع فیلدها از جمله متنی، مدیا، عددی یا حتی ارتباط بین جدول‌ها را به آن اضافه کنید. سپس محتوا را در قالب این Content Type وارد کنید و از طریق API در دسترس داشته باشید.

این قابلیت، به‌ویژه برای پروژه‌های محتوا محور، بسیار کارآمد است و امکان پیاده‌سازی یک محصول کاملاً سفارشی‌سازی‌شده را بدون نیاز به تیم بک‌اند فراهم می‌کند. همچنین نیازی به توسعه‌ی پنل فرانت‌اند برای مدیریت محتوا نیز نخواهید داشت.

این ویژگی می‌تواند تأثیر چشم‌گیری بر کاهش هزینه‌ها و افزایش سرعت توسعه‌ی محصول داشته باشد.

اما ماجرا باز هم به اینجا ختم نمی‌شود...

بخش پنجم – ادغام Headless CMS با معماری‌های مدرن

اگر اپیزود «به دنبال یک راه‌حل…» را شنیده باشید، آنجا درباره‌ی یک پترن معماری به‌نام Backends for Frontends (BFF) صحبت کردم. ما در آن پروژه، بخشی از سیستم را که وظیفه‌ی مدیریت صفحات لندینگ پیج را بر عهده داشت، جدا کرده و یک سرویس BFF جدید برای آن تعریف کردیم.

اما مشکلی که داشتیم این بود که مدیریت محتوای لندینگ پیج‌ها نیز از سیستم قدیمی جدا شده بود و باید به سرویس جدید منتقل می‌شد. این انتقال نیاز به طراحی یک پنل مدیریتی جدید داشت که طبیعتاً زمان‌بر بود.

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

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

این روزها، ترکیب سرویس‌های داخلی با Headless CMS به‌عنوان یکی از رویکردهای مدرن در معماری نرم‌افزار مورد استفاده قرار می‌گیرد و می‌تواند در کاهش هزینه، زمان و پیچیدگی پروژه‌ها بسیار مؤثر باشد.

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

بخش ششم – قابلیت‌ها و محدودیت‌های Headless CMS

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

در حال حاضر ما با دو دسته اصلی از هدلس CMSها طرفیم: یکی سرویس‌های SaaS (مثل: Contentful، Sanity، [Strapi Cloud)) و یکی هم سرویس‌های Self-Hosted یا اپن‌سورس (مثل: Strapi، Directus، KeystoneJS).

سرویس‌های SaaS معمولاً آماده‌ به کار هستند، نیاز به نصب و نگهداری خاصی ندارند و امکاناتی مثل مقیاس‌پذیری، امنیت، بکاپ‌گیری و غیره رو به صورت پیش‌فرض ارائه میدن. این سرویس‌ها برای تیم‌هایی که دنبال سرعت بالا و کمترین نیاز به زیرساخت هستن، گزینه‌ی خیلی جذابی‌ان.

از اون‌طرف، سیستم‌های Self-Hosted یا اپن‌سورس، به شما این امکان رو میدن که کل سرویس رو روی سرور خودتون یا روی زیرساخت دلخواهتون بالا بیارید، تغییرش بدید و کامل با معماری و نیازمندی‌هاتون سازگارش کنید. این سیستم‌ها بیشتر مناسب تیم‌هایی هستن که کنترل کامل، نیاز به سفارشی‌سازی بالا یا ملاحظات خاص امنیتی دارن.

حالا برگردیم به سوال اصلی:

قابلیت‌ها و مزایای Headless CMSها چیه؟

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

1. توسعه‌ سریع‌تر فرانت‌اند: تیم فرانت‌اند نیازی نداره منتظر آماده شدن بخش بک‌اند بمونه. فقط کافیه APIها از هدلس CMS تعریف بشن و باقی‌ کار رو خودشون انجام می‌دن.

2. همکاری مستقل تیم‌ها: تیم محتوا، تیم فرانت و حتی تیم بک‌اند می‌تونن مستقل از هم کار کنن. این باعث میشه توسعه همزمان و سریع‌تر انجام بشه.

3. کاهش هزینه‌ها در پروژه‌های MVP و استارتاپی: شما بدون نیاز به توسعه‌ی بک‌اند کامل، می‌تونید خیلی سریع یه محصول اولیه با ساختار محتوامحور بالا بیارید.

4. قابلیت سفارشی‌سازی Content Types، سطوح دسترسی، نقش‌ها و…: اغلب این سرویس‌ها پنل‌های قوی‌ای برای تعریف نقش‌های کاربری، مدل‌های داده، دسترسی‌ها و حتی گردش کار محتوا دارن.

اما حالا محدودیت‌ها یا چالش‌های Headless CMSها چیه؟

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

۲. هزینه‌های مربوط به سرویس‌های SaaS در مقیاس بالا: ممکنه استفاده از سرویس‌های SaaS برای پروژه‌های بزرگ یا پرترافیک، در بلندمدت هزینه‌بر باشه. چون تعرفه‌ها معمولاً بر اساس حجم دیتا و تعداد درخواست‌ها محاسبه می‌شن.

1. چالش در زمان مهاجرت از سیستم‌های قدیمی به هدلس CMS: اگر پروژه‌ای از قبل روی یک سیستم سنتی ساخته شده باشه، مهاجرت به مدل هدلس ممکنه زمان‌بر و پیچیده باشه. باید هم دیتا رو انتقال بدید، هم ساختار جدید تعریف کنید، هم فرانت جدید طراحی بشه.

2. نیاز به اتصال و ادغام با دیگر سرویس‌ها: برای پروژه‌هایی که چند سرویس مختلف دارن (مثل احراز هویت، درگاه پرداخت، یا تعامل با سیستم‌های ERP)، باید APIهای جداگانه‌ای برای اتصال به هدلس CMS طراحی بشه. این یعنی نیاز به هماهنگی و بعضاً پیاده‌سازی‌های اضافی.

جمع‌بندی:

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

اما انتخاب اینکه از کدوم نوع هدلس CMS استفاده کنیم – SaaS یا Self-hosted – و اینکه اصلاً این مدل مناسب پروژه‌مون هست یا نه، بستگی زیادی به ماهیت محصول، اندازه تیم، نیاز به سفارشی‌سازی، منابع مالی و مسیر رشد پروژه داره.