نرمافزارها برخلاف سیستمهای فیزیکی، ذاتاً پیچیده و غیرقابلپیشبینی هستند. شاید بتوان یک پل را با دقت میلیمتری طراحی کرد، اما طراحی کامل و دقیق یک سیستم نرمافزاری بزرگ، آن هم قبل از پیادهسازی، تقریبا غیرممکن است.
همین موضوع باعث میشود طراحی اولیهی نرمافزارها معمولاً همراه با چالشهایی باشد که تا زمان اجرا و استفاده واقعی، شناسایی نمیشوند. اما وقتی معماری پروژه به شکلی باشد که ایجاد تغییرات اساسی در آن بسیار دشوار یا پرهزینه باشد، توسعهدهندهها چارهای تغییرات سطحی ندارند و حل مسئله ، بدون تغییرات اساسی شکل میگیرد! این نقطه را میتوان همان بخشی دانست که پیچیدگی سیستم آنقدر زیاد میشود که تقریبا هیچ تغیری اساسی بدون هزینه نمی باشد !
یکی از راهکارهایی که در سالهای اخیر برای مواجهه با چنین چالشهایی مطرح شده، الگوی Backends for Frontends (BFF) است. اما آیا این الگو همیشه بهترین گزینه است؟
در دومین اپیزود پادکست کدشناسی، دقیقتر به این موضوع پرداختم، اما در اینجا میخواهم خلاصهای از آن را با شما به اشتراک بگذارم!
سال ۲۰۱۲، شرکت SoundCloud با افزایش استفاده کاربران از اپلیکیشنهای موبایل مواجه شد. در آن زمان، تمام بخشهای پروژه (از اپلیکیشنهای موبایل تا APIهای عمومی) از طریق یک API واحد مدیریت میشدند. نتیجه؟ افزایش شدید پیچیدگی و کاهش انعطافپذیری.
با رشد پروژه و افزایش کاربران، مدل مونولیتیک دیگر پاسخگو نبود. آنها تصمیم گرفتند به سمت معماری میکروسرویس مهاجرت کنند. اما این تصمیم یک مشکل جدید به وجود آورد: حالا اپلیکیشنها باید با چندین سرویس مستقل در ارتباط باشند و این یعنی پیچیدگی بیشتر در سمت کلاینت.
در پاسخ به این چالش، ایدهی BFF متولد شد. لایهای بین کلاینت و بکاند که میتواند تجربهی کاربر را ساده کند، بدون اینکه فشار اضافهای به کلاینت وارد شود.
من هم چند سال پیش روی پروژهای کار میکردم که بهطرز نگرانکنندهای پیچیده شده بود. نه اسکیل کردن سیستم راحت بود، نه نگهداری آن. از طرف دیگر، تیم محصول نیازهای جدیدی را مطرح میکرد که سیستم فعلی از پس آنها برنمیآمد.
تصمیم گرفتیم بخشی از پروژه را به عنوان یک سرویس مستقل دوباره بازنویسی کنیم. اما این سرویس باید با چندین منبع داده (سرویسهای third-party، سرویسهای قدیمی، و موقعیت جغرافیایی کاربران) تعامل میداشت. نیاز به لایهای احساس میشد که تمام این تعاملها را مدیریت و مشکلاتی را که ما برای نیازمندیهای جدیدمان داشتیم مرتفع سازد !
BFF به ما این امکان را داد که:
جواب کوتاه: نه.
با تمام مزایایی که دارد، BFF هم چالشهای خاص خودش را دارد:
اجرای BFF در پروژهی ما آسان نبود. اما نتیجه ارزشش را داشت. توانستیم عملکرد و ساختار سیستم را بهبود بدهیم، بدون اینکه کاربران چیزی متوجه شوند و شاید این، یکی از نشانههای یک راهحل درست باشد.
اگر فقط به دنبال "پیادهسازی" بدون درک "مسئله" باشیم، شاید آنچه امروز به نظر راهحل میرسد، فردا خودش تبدیل به مشکل جدیدی شود.
🎧 اگر دوست دارید این ماجرا را با جزئیات بیشتر و تجربههای عمیقتر بشنوید، حتما به اپیزود دوم پادکست کدشناسی با عنوان «به دنبال یک راهحل…» گوش کنید.
