مقدمه‌ای بر الگوی Backend For Frontend یا BFF قسمت دوم (نهایی)

در مقاله قبل که با عنوان مقدمه‌ای بر الگوی Backend For Frontend یا BFF قسمت اول منتشر شد به کلیات الگوی BFF و شرایط استفاده از آن پرداختیم. به طور کلی هدف BFF ایجاد راه‌حلی بود که frontend بر روی پیاده‌سازی ظاهر(interface) متمرکز باشد، نه تسویه و قالب‌بندی اطلاعات دریافتی از سمت سرور. در این مقاله قصد داریم کمی تخصصی‌تر به آن نگاه کنیم:

آیا امکان استفاده از چند BFF هم هست؟

اصلا بهترین روش استفاده از BFF همین‌گونه خواهد بود. در روش‌های سنتی api نویسی چه اتفاقی رخ می‌داد؟ ما تنها یک درگاه api داشتیم برای پاسخ به همه پلتفرم‌ها(اعم از وب، android, ios و...).

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

در شکل بالا نحوه پیاده سازی چند BFF که هر کدام قرار است یک نوع از پلتفرم‌ها را پشتیبانی کند می‌بینیم.

برخی از مزایای الگوی BFF

• تفکیک دغدغه: همواره یکی از دغدغه‌های مهم تیم سرور(backend team)، نیازهای تیم کلاینت (frontend team) بابت قالب‌بندی‌ها، سورت کردن‌ها، تجمیع کردن چند پاسخ در یک درخواست و ... است که عموما باعث می‌شود دغدغه‌های کلاینت و سرور تلفیق شوند. با این الگو امکان تفکیک این دغدغه‌ها تا حدود زیادی حاصل می‌شود و همچنین نگهداری و پشتیبانی از هر دو سمت سرور و کلاینت را بسیار راحت‌تر خواهد کرد.
• سهولت بیشتر در تغییرات apiها: خیلی مواقع تیم سرور مجبور به تغییراتی در apiها بنا بر ملاحضات امنیتی یا راندمان و ... است. عموما این تغییرات باعث می‌شود تیم کلاینت هم مجبور شود خود را با قالب‌بندی جدید اطلاعات هماهنگ کند. از طریق این الگو می‌توان تغییرات سمت سرور را راحت‌تر پیش برد و در نهایت هنگام ارسال اطلاعات به کلاینت در لایه BFF کمی تغییرات داشت و اطلاعات را به شکل سابق به کلاینت ارسال کرد.
• بهینه‌تر کردن مدیریت خطاها (error handling) در سمت کاربر: خیلی مواقع ارورهای سمت سرور به صورت مستقیم برای کاربر ارسال می‌شوند و در اکثر موارد هم صورت خوشی ندارند. مثلا پیام server error دریافت می‌شود. در صورتی هم که سیستم پاسخ‌دهی به ارورها سمت سرور پیاده‌سازی شده باشد، این بار اضافی به سرور اصلی تحمیل می‌کند. ماژول مدیریت خطاها می‌تواند در لایه BFF پیاده سازی شود و از سرور صرفا یک کد خطای مشخص بگیرد، در BFF بسته به زبان کاربر (مثلا انگلیسی، فارسی یا ...) پیام مناسب را برای کلاینت ارسال کند و کلاینت هم آن را به کاربر نمایش دهد.
• امنیت بیشتر: بعضا پیش آمده که تیم سرور اطلاعاتی غیر ضروری را ارسال کرده که به درد کلاینت هم نخورده و همان امنیت سیستم را با خطر مواجه کرده. در لایه BFF یک‌بار اطلاعات چک می‌شود و صرفا اطلاعات ضروری برای کلاینت ارسال می‌گردد. همچنین همواره سرورهای اصلی شما و پایگاه‌داده پشت BFF قرار گرفته و در صورت حمله، همه اطلاعات در پشت BFF قرار دارد. با این الگو کار برای مهاجمان سخت‌تر خواهد شد.

برخی از نکات مهم هنگام پیاده‌سازی BFF

• حواستان باشد BFF یک لایه میانی و صرفا یک مترجم است! ممکن است برخی اشتباها برنامه خود را از پیاده‌سازی BFF شروع کنند. دقت کنید شما قرار است ابتدا میکروسرویس‌ها و apiها خود را با دقت پیاده‌سازی کنید و بعدا به پیاده‌سازی BFF بر اساس نیاز‌های کلاینت بپردازید. نحوه ورود اشتباه به مسئله باعث می‌شود از آرمان‌های این الگو باز بمانیم.
• از پیاده سازی منطق‌های یکسان پرهیز کنید. همیشه ممکن است ما یک سری درخواست با منطق مشترک بین کاربران پلتفرم‌های مختلف داشته باشیم. طبیعتا باید یک BFF عمومی هم داشته باشیم تا موارد مشترک به آن درخواست بدهدند و نیازی نباشد مثلا برای android و ios همواره دو BFF داشته باشند که همه end pointها را به صورت تکراری در بر بگیرند.
• دقت کنید BFF قرار نیست باعث شود از امنیت سمت سرورهای اصلی غافل شویم. BFF صرفا یک لایه مترجم هستند و قرار نیست باعث به وجود آمدن احساس امنیت کاذب در سرور شوند. سرور باید بدون در نظر گرفتن وجود لایه BFF تمام ملاحظات امنیتی را در نظر بگیرد و از اعتماد بی‌جا به BFF اجتناب کند.