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

Web Application Design Pattern
Web Application Design Pattern

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

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

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

Backend For Frontend (BFF)
Backend For Frontend (BFF)

لایه میانی BFF مسئول انجام امور زیر است:

  • ارتباط با apiهای سرور و گرفتن اطلاعات از آن‌ها
  • تغییر قالب (format) اطلاعات بر اساس نیاز کلاینت (frontend)
  • ارسال اطلاعات قالب‌بندی (formatted data) شده کلاینت

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

آیا الگوی BFF باعث تاخیر در دریافت اطلاعات نمی‌شود؟
پاسخ این سوال قطعا مثبت است! اما باید این تاخیر را در مقایسه‌ با تاخیر قالب‌بندی مجدد اطلاعات در سمت کاربر در نظر گرفت. در نظر بگیرید ممکن است یا اپلیکیشن موبایل شما زمان زیادی صرف قالب‌بندی مجدد اطلاعات کند یا وب‌سایت شما. چون اطلاعات ارسالی توسط سرور در بهترین حالت مناسب برای یکی از نسخه‌ها خواهد بود. یا باید این تاخیر را بین همه نسخه‌ها به صورت جزئی تقسیم کرد یا در موثرترین روش یکی از نسخه‌ها با سرعت مناسب‌تری کار کند و دیگر نسخه‌ها با تاخیر خیلی بیش‌تر. باید در نظر بگیرید که در این حالت ما منابع زیادی هم از مرورگر و مشتریان را مصرف می‌کنیم! طبیعتا یک تاخیر جزئی و نامحسوس قابل اغماض خواهد بود.

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

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

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

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

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

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