danny
danny
خواندن ۴ دقیقه·۲ سال پیش

Cloud Design Patterns - Backends for Frontends

در این حالت backend servicesهای جداگانه ایجاد کنید تا توسط frontend applications یا interface های خاص مصرف شود. این الگو زمانی مفید است که بخواهید از سفارشی سازی یک Backend برای چندین interface یا رابط کاربری اجتناب کنید. این الگو اولین بار توسط Sam Newman توصیف شد.

صورت مسئله:

هدف گذاری تولید یک نرم افزار می تواند بر اساس یک رابط کاربری مبتنی بر desktop application
یا web ui باشد.معمولا، یک سرویس backend به طور همزمان با سرویس frontend توسعه می یابد که که هر دوی این سرویس ها ویژگی های وابسته هم را ایجاد می کنند به طوری که اجرای صحیح یکی به دیگری وابسته است. همانطور که توسعه برنامه رشد می کند، نیازمندی هایی جدیدی بوجود می آید که در روزهای اولیه طراحی نرم افزار در نظر گرفته نشده بودند مثلا یک برنامه mobile application هم در کنار دو سرویس قبلی شروع به توسعه می‌کند که باید با همان Backend تعامل داشته باشد. سرویس Backend به یک Backend همه منظوره تبدیل می‌شود که باید نیازهای رابط desktop/web UI و موبایل را برآورده کند.

اما قابلیت های یک دستگاه تلفن همراه از نظر اندازه صفحه نمایش، عملکرد و محدودیت های نمایش به طور قابل توجهی با یک مرورگر دسکتاپ متفاوت است. در نتیجه، الزامات یک برنامه mobile application با رابط کاربری desktop/web UI متفاوت است.

این تفاوت ها منجر به الزامات مختلفی برای backend می شود. سرویس backend نیاز به تغییرات منظم و قابل توجهی دارد تا هم به رابط کاربری وب دسکتاپ و هم به اپلیکیشن موبایل ارائه شود. اغلب، تیم‌های رابط جداگانه روی هر فرانت‌اند (موبایل و وب) کار می‌کنند و باعث می‌شوند که backend به گلوگاهی در فرآیند توسعه تبدیل شود. الزامات به‌روزرسانی متناقض، و نیاز به کارکردن سرویس برای هر دو فرانت‌اند، می‌تواند منجر به صرف تلاش زیادی برای سرویس backend شود.

از آنجایی که فعالیت توسعه بر روی سرویس Backend متمرکز است، ممکن است یک تیم جداگانه برای مدیریت و نگهداری Backend ایجاد شود. در نهایت، این منجر به قطع ارتباط بین تیم‌های توسعه رابط کاربری و Backend می‌شود و باری را بر دوش تیم Backend می‌گذارد تا بین نیازهای رقابتی تیم‌های مختلف UI تعادل برقرار کند. هنگامی که یک تیم frontend به تغییراتی در Backend نیاز دارد، این تغییرات باید قبل از اینکه بتوان آنها را در Backend ادغام کرد، با سایر تیم‌های frontend در mobile/web UI هماهنگ شود.

راه حل:

برای هر رابط کاربری یک backend ایجاد کنید. رفتار و عملکرد هر backend را طوری تنظیم کنید که به بهترین وجه با نیازهای frontend مطابقت داشته باشد، بدون اینکه نگران تأثیرگذاری بر سایر frontend های دیگر باشید.

از آنجایی که هر backend مخصوص یک frontend است، می توان آن را برای آن frontend بهینه کرد. در نتیجه، کوچک‌تر، پیچیده‌تر و احتمالاً سریع‌تر از یک Backend همه کاره است که سعی می‌کند الزامات همه frontend ها در mobile/web UI را برآورده کند. هر تیم رابط برای کنترل Backend خود استقلال دارد و به یک تیم توسعه بک‌اند متمرکز متکی نیست. این به تیم frontend انعطاف‌پذیری در انتخاب زبان، آهنگ انتشار، اولویت‌بندی حجم کار و یکپارچه‌سازی ویژگی‌ها در Backend خود می‌دهد. برای اطلاعات بیشتر دیدن این لینک توصیه می شود.

مسائل و ملاحظات:

  • در نظر بگیرید که چه تعداد Backend باید مستقر کنید.
  • اگر frontendهای مختلف (مانند کلاینت‌های موبایل) درخواست‌های یکسانی ارائه می‌دهند، در نظر بگیرید که آیا لازم است یک Backend برای هر frontend پیاده‌سازی شود یا اینکه یک Backend واحد کافی است.
  • هنگام پیاده سازی این الگو، احتمال تکرار کد در بین سرویس ها بسیار زیاد است.
  • همینطور backend services متمرکز بر frontend فقط باید logic و behavior مربوط به client-specific را پیاده سازی کند. منطق business logic و سایر global features ها باید در جای دیگری از برنامه مدیریت شوند.
  • به این فکر کنید که چگونه این الگو ممکن است در مسئولیت های یک تیم توسعه منعکس شود و تاثیرگذار باشد.
  • در نظر بگیرید که اجرای این الگو چقدر طول می کشد و هزینه زمانی ایجاد می کند. آیا تلاش برای ساخت بک‌اندهای جدید بدهی فنی بیشتری را به همراه داره نسبت به حالت یک backend همه منظوره؟

چه زمانی از این الگو استفاده کنیم؟

  • یک سرویس backend مشترک یا همه‌منظوره باید با سربار و مشکلات قابل توجهی هنگام توسعه حفظ شود.
  • شما می خواهید backend را برای نیازهای frontend های specific client بهینه کنید.
  • سفارشی‌سازی‌ها در یک backend همه‌منظوره برای تطبیق چندین frontend مختلف.


این الگو در حالت‌های زیر مناسب نیست:

  • هنگامی که frontend ها request های مشابهی را به backend ارسال و دریافت می کنند.
  • زمانی که تنها از یک frontend برای تعامل با backend استفاده می شود.
رابط کاربریkubernetesmicroservicecloud design patterndocker
شاید از این پست‌ها خوشتان بیاید