هنگامی که میکروسرویس‌ها خود را توسعه می‌دهید یک مسئله مهم پیش روی شما قرار دارد. چگونه clientهای شما با میکروسرویس‌های شما تعامل خواهند کرد؟ هنگامی که از روش Monolithic برای توسعه نرم‌افزارهای خود استفاده می‌کنید نهایتا یک Endpoint خواهید داشت و در صورت نیاز همین یک Endpoint برای تقسیم بار روی چند سرور نصب می‌شود و به کمک یک Load balancer بار روی این سرورها توزیع می‌شود. اما زمانیکه میکروسرویس توسعه می‌دهید مجموعه‌ای از endpointها خواهید داشت که باید بتوانید با آن‌ها تعامل کنید.

برای تعامل بهتر clientها با میکروسرویس‌ها روش API Gateway وجود دارد. در این روش تنها نقطه ورود برنامه ما یک Gateway است و راه ارتباطی Clientها با microserviceها همین Gateway است. در صورتی که با الگوی facade آشنایی داشته باشید API Gateway عملکردی شبیه به این الگو دارد. در این الگو به جای اینکه برای انجام یک کار با چندین API مختلف تعامل کنیم به سادگی با یک API تعامل می‌کنیم و پیچیدگی‌ها و معماری داخلی ما از چشم استفاده کننده پنهان می‌ماند. صدا زدن چندین سرویس مختلف و ترکیب نتنیجه و بازگرداندن نتیجه نهایی مواردی است که باید داخل API Gateway ما کپسوله شود و استفاده کننده نهایی به سادگی و با صدا زدن یک API نتیجه دلخواه خود را دریافت کند.

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

یکی دیگر از کارهای خوبی که در این زمینه می‌توان انجام داد پیاده سازی Gatewayهای تخصصی برای هر Client است. مسلما تمام داده‌هایی که در صفحه مانیتور نمایش داده می‌شود مناسب نمایش در صفحه یک گوشی موبایل نیست. پس بهتر است به ازای هر Client یک Gatewayتخصصی داشته باشیم که صرفا داده‌های آن Client را فراهم کند.

در یک API Gateway نیاز است با سرویس‌های مختلف تعامل انجام شود و اصطلاحا Inter-Process Communication انجام شود. سرویس‌های مختلف ممکن است راهکارهای متفاوتی برای تعامل در اختیار ما قرار دهند. ممکن است از روش‌های Async مثل AMQP یا روش‌های sync مثل HTTP و Thrift استفاده شود. به هر حال بدون توجه به روش‌های تعامل API Gateway مورد نظر ما باید بتواند با تمامی این روش‌ها ارتباط برقرار کند.

مشکل دیگری که هنگام توسعه یک API Gateway باید به آن بیاندیشیم partial failure است. یعنی زمانی که یک درخواست کلی می‌آید و بخشی از درخواست قابل پاسخ گویی نیست. مثلا در سیستم فروشگاه و صفحه جزئیات فروشگاه یکی از سرویس‌ها در دسترس نباشد. مثلا سرویس پیشنهاد کالا در دسترس نباشد. API Gateway باید این قابلیت را داشته باشد که در این شرایط به جای اینکه کل درخواست را لغو کند،داده‌های بخش‌های صحیح را به دست آورد و برای بخش‌های مشکل دار خطا را مدیریت کند. برای مثال داده‌های کش شده داشته باشد که در این شرایط جایگزین داده‌های آنلاین شود. یا مثلا در صورتی که سرویس پیشنهاد کالا قطع باشد 10 کالای پرفروش را بازگرداند.