💡🪐 مفهوم و کاربرد API Federation

سال‌هاست که معماری سیستم‌ها به سمت ریزشدن (fragmentation) رفته و
تعداد زیادی سرویس‌ها، APIها، دیتابیس‌ها و کانال‌های ارتباطی که هر کدوم یک گوشه‌ای از سیستم زنده‌اند و کار می‌کنند.

این آزادی و انعطاف‌پذیری خیلی خوبه… اما روی طرف دیگر سکه، تجربه مصرف API رو تبدیل کرده به چیزی شبیه یک هزارتوی پیچیده و گاها کابوس!

توی چنین شرایطی API Federation وارد می‌شه؛ یک الگوی معماری نسبتا مدرن که کمک می‌کنه تا مصرف‌کننده فقط یک نقطه ورودی ببینه؛ اما پشت صحنه هرچقدر دوست داریم API و سرویس مستقل داشته باشیم، بدون اینکه مجبور شیم یک monster gateway بسازیم (تفاوتش رو با API Gateway خواهم گفت) و بدون اینکه همه‌چیز رو hard-code کنیم، merge کنیم، rewrite کنیم یا به هم بچسبونیم.

به زبان ساده؛ API Federation یعنی یک لایه هوشمند که چندین API مستقل رو به شکل یک API واحد و یکپارچه در اختیار کاربر قرار می‌ده.

👁 پرسش مهم: تفاوت API Gateway و API Federation

تفاوت این دو تا رو خیلی ساده مرور کنیم، چون اکثر تیم‌ها اشتباه می‌کنن:

توصیف API Gateway:
نقش اصلی API Gateway عملا یک reverse proxy است که خاصه‌ی API هاست و درخواست‌ها رو route می‌کنه، و توانایی داره تا احراز هویت و محدودیت روی درخواست‌ها و logging رو اعمال کنه. عملا دیدگاهش متمرکز بر مدیریت ترافیک و امنیته. و معمولاً نمی‌دونه محتوای درخواست چیه، فقط اون رو به سمت درست هدایت می‌کنه
مثل Kong، Nginx، AWS API Gateway

توصیف API Federation:
نقش اصلی API Federation نقطه‌ی ورودی متمرکز برای یکپارچه‌سازی منطقی چندین API مستقل به صورت یک API واحد است. تمرکزش هم روی تجربه کاربری و یکپارچگی داده است تا صرفا هدایت ترافیک. و عملا می‌دونه schema و معنای داده‌ها چیه، می‌تونه داده‌ها رو از چند منبع aggregate کنه و به شکل یکپارچه برگردونه (مثلا اطلاعات هویتی مشتری رو از یه API بگیره، وضعیت حسابش رو از یه جا و وضعیت سفارشاتش رو از جای دیگه، و نهایتا در یک ساختار مشخص بچینه و برگردونه). معماریش داخلی‌اش هم عموما distributed/composable است و هر API می‌تونه در دامین خودش باقی بمونه و federation فقط اون‌ها را به هم نشون بده.

مثال: GraphQL Federation (Apollo), KrakenD Federation Mode, API Mesh (Solo.io), WunderGraph

به عبارت دیگه Gateway مثل یک دربون سختگیره که می‌گه "بیا اینجا، برو اونجا"، اما Federation مثل یک مترجم و هماهنگ کننده است که می‌گه "من می‌فهمم چی می‌خوای، از هر جایی که لازمه می‌گیرم و یکجا به زبون خوت بهت برمی‌گردونم".

🍴 کاربردهای عملی API Federation

مایکروسرویس‌های بزرگ
وقتی +۵۰ سرویس دارید، federation به جای یه گیت‌وی سنگین، یک schema یکپارچه می‌سازه.

جلوگیری از API Explosion
وقتی +۲۰ تا تیم داریم، معمولاً +۲۰ نوع API هم ساخته می‌شه؛ مصرف‌کننده هم نمی‌دونه باید به کدومش و چجوری وصل بشه (البته این آسیب آبشخور دیگه‌ای داره که جدای از این بحثه) اینجا می‌شه همه رو توی یک نقطه خلاصه کرد.

ادغام با سیستم‌های قدیمی (Legacy Integration)
وقتی انواع APIها از SOAP، REST، gRPC دارید، federation اون‌ها رو پشت یه facade یکسان پنهان می‌کنه. اینجوری با حداقل کردن couplingدیگه نیازمند تغییر در API اصلی نیستیم.

تیم‌های مستقل (Team Autonomy)
هر تیم API خودش رو deploy می‌کنه و federation به صورت داینامیک اون‌ها رو کشف و ترکیب می‌کنه (مثل service mesh + API).

محیط‌های ترکیبی (Multi-cloud / Hybrid Environments)
مثل وقتی که API توی AWS، Azure و on-prem دارین، اون‌وقت یک endpoint واحد خواهید داشت.


💬 این مقدمه کوتاهی در مورد API Federation بود، مبحث مفصلیه که پرداختن بهش از حوصله تلگرام خارجه، امیدوارم اگر براتون جذاب بوده باشه، پیگیرش باشین، اگر هم سوالی در موردش بود حتمن همینجا طرح کنین تا در موردش صحبت کنیم 😊