هرچند جامعه‌ی API ممکن است به ایده‌ی «API-first» (اولویت با API) علاقه‌ی زیادی داشته باشد، اما این رویکرد هنوز در همه‌ی بخش‌های توسعه‌ی نرم‌افزار نفوذ نکرده است. برای مثال، در مهندسی پلتفرم (Platform Engineering) بسیاری از پلتفرم‌های توسعه‌دهنده‌ی داخلی (IDPها – Internal Developer Platforms) بر اساس رابط کاربری (UI-first) ساخته می‌شوند، بدون اینکه از ابتدا به طراحی بک‌اند (Backend) یا نحوه‌ی دسترسی مهندسان به آن از طریق API فکر شود.
در مهندسی پلتفرم، نبود رابط‌های قابل برنامه‌نویسی برای توسعه‌دهندگان باعث می‌شود که پشتیبانی از چندین کلاینت هم‌زمان دشوار شود و همچنین نتوان سیاست‌های یکپارچه را صرف‌نظر از نقطه‌ی دسترسی یا رابط کاربری اعمال کرد.
در اجلاس پلتفرم ۲۰۲۵، از حضور ویکتور فارسیک (Viktor Farcic)، مدافع توسعه‌دهنده در شرکت Upbound و مجری کانال یوتیوب AI & DevOps Toolkit، هیجان‌زده‌ایم. او در این رویداد ارائه‌ای با عنوان «کنسول‌های پلتفرم توسعه‌دهنده باید احمق باشند» خواهد داشت.
پیش از این رویداد، با فارسیک درباره‌ی سخنرانی‌اش و دیدگاهش نسبت به روندهای جدید گفت‌وگو کردیم — از ضرورت API در پلتفرم‌ها گرفته تا اینکه چرا سرورهای MCP نباید بازتاب یک‌به‌یک APIها باشند.
مصاحبه با ویکتور فارسیک
برای یک پلتفرم توسعه‌دهنده‌ی داخلی، نبود API چه پیامدهایی دارد و چگونه مهندسی پلتفرم را محدود می‌کند؟
نمی‌توانم تصور کنم کسی نخواهد API داشته باشد. از زمان شکل‌گیری AWS بیش از بیست سال گذشته، که اساس آن بر این ایده بود که همه — انسان‌ها و فرایندها — از طریق APIها با یکدیگر تعامل کنند. ما اکنون آن‌قدر به APIها وابسته‌ایم که بدون آن‌ها تقریباً هیچ سیستمی کار نمی‌کند. هر کسی که از AWS، گوگل، Azure یا تقریباً هر سرویس ابری دیگری استفاده می‌کند، در واقع از API استفاده می‌کند، حتی اگر متوجه نباشد.
بسیاری از افراد فکر می‌کنند چون از Terraform یا AWS Console استفاده می‌کنند، دیگر نیازی به API ندارند، در حالی که تمام این ابزارها در اصل روی APIها ساخته شده‌اند. همه‌ی سرویس‌های محبوب امروز API-first هستند — یعنی API نخستین رابط ارتباطی آن‌هاست و باقی چیزها فقط لایه‌های ظاهری روی آن‌اند.
اگر شرکت‌ها در حال ساخت پلتفرم توسعه‌دهنده‌ی خود هستند، چرا از معماری و الگویی استفاده نکنند که بارها ثابت کرده مؤثر است؟ برای من، API-first بخشی حیاتی از طراحی هر پلتفرم توسعه‌دهنده است.
چرا برخی شرکت‌ها در ساخت پلتفرم‌های داخلی خود از رابط گرافیکی (GUI) استفاده می‌کنند و API طراحی نمی‌کنند؟
دلایل زیادی وجود دارد و به هر شرکت بستگی دارد، اما یکی از دلایل ممکن این است که برخی از افرادی که این پلتفرم‌ها را می‌سازند، هنوز اصول پایه‌ی مهندسی نرم‌افزار را درک نکرده‌اند.
فرض کنید در حال ساخت یک اپلیکیشن هستید و با UI شروع می‌کنید — بدون اینکه بدانید بک‌اند چه منطقی دارد یا قرار است با چه چیزی ارتباط بگیرد. این کار، تصمیمی کاملاً ناپخته است.
اما اگر از بک‌اند شروع کنید، ابتدا منطق کسب‌وکار را طراحی می‌کنید، سپس آن را از طریق API در دسترس قرار می‌دهید، و در نهایت رابط کاربری را روی آن می‌سازید تا API را مصرف کند. این روش استاندارد توسعه‌ی مدرن است و تقریباً هیچ توسعه‌دهنده‌ای با آن مخالف نیست.
با این حال، در مهندسی پلتفرم، بسیاری هنوز از این رویکرد پیروی نمی‌کنند. مثلاً با Backstage (به عنوان frontend) شروع می‌کنند و تمام منطق را در آن می‌ریزند، در حالی که باید آن را ساده و جدا از منطق اصلی نگه داشت.
اگر API طراحی کنید، فقط داده‌ها را از API می‌گیرید و روی صفحه نمایش می‌دهید — درست همان‌طور که هر وب‌اپلیکیشن بالغی کار می‌کند. واقعاً قابل درک نیست چرا در مهندسی پلتفرم هنوز این اصول به طور گسترده پذیرفته نشده‌اند.
در KubeCon سال گذشته اشاره کردی که حتی بسیاری از پلتفرم‌های داخلی ساخته‌شده توسط فروشندگان، API مناسبی ندارند. آیا هنوز همین‌طور است؟
در حال پیشرفت هستیم. Kubernetes اکنون به نوعی به ارکستر همه‌چیز تبدیل شده است. دیگر فقط اجرای کانتینرها در یک کلاستر نیست — بلکه بستری برای گسترش و یکپارچه‌سازی با ابزارهای شخص ثالث مثل Argo CD یا Flux است.
اکنون بسیاری متوجه شده‌اند که Kubernetes ابزارهای لازم برای ساخت APIهای جدید را از ابتدا در اختیار ما گذاشته است. تنها کافی است یک فایل YAML بنویسید و یک endpoint جدید بسازید.
من شخصاً در پروژه‌ی Crossplane فعالیت دارم که یکی از نمونه‌های موفق در این زمینه است. اما تنها پروژه نیست — ابزارهایی مثل Cluster API، KubeVela و Terragrunt نیز در حال رشد هستند.
می‌توانی مثالی بزنی از جایی که نبود API در یک IDP مانع توسعه شده است؟
معمولاً ابتدا با ابزارهایی مثل Terraform یا Ansible و چند اسکریپت شروع می‌کنند، که در ابتدا خوب است، اما بعداً محدودیت‌ها خودشان را نشان می‌دهند.
وقتی می‌خواهید رابط‌های بیشتری مثل وب یا حتی اپلیکیشن موبایل اضافه کنید، می‌فهمید که باید همه چیز را از نو بنویسید. اما اگر از همان ابتدا API داشتید، همه‌ی این رابط‌ها فقط مصرف‌کننده‌ی یک منبع واحد می‌بودند.
برای مثال، اگر بخواهید سیاست‌های سازمانی را در پلتفرم اعمال کنید، بهتر است آن‌ها را در سطح API تعریف کنید تا برای تمام مسیرها و رابط‌ها یکسان اعمال شوند، نه اینکه آن‌ها را داخل ابزارهایی مثل Jenkins بگذارید.
در سخنرانی «کنسول‌های پلتفرم توسعه‌دهنده باید احمق باشند» چه نکاتی را مطرح خواهی کرد؟
ایده‌ی اصلی این است که هر رابط کاربری که برای پلتفرم می‌سازید، فقط باید یک واسط ساده باشد — نه خود پلتفرم. منطق واقعی باید در بک‌اند (API و کنترلرها) قرار داشته باشد.
وقتی از پایین به بالا طراحی کنید، رابط کاربری فقط داده را نمایش می‌دهد و خودش تصمیمی نمی‌گیرد. این باعث می‌شود که رابط‌ها سبک، قابل توسعه و قابل نگهداری باشند.
برای مثال، اگر امروز تصمیم بگیرید سرویس جدیدی مثل Database-as-a-Service اضافه کنید، کنسول شما به‌صورت خودکار آن را تشخیص می‌دهد و نمایش می‌دهد، چون منطق اصلی از API گرفته می‌شود.
در مورد شرکت در اجلاس Nordic APIs، دنبال چه تجربه‌ای هستی؟
راستش، من بیشتر از «hallway track» لذت می‌برم — یعنی گفتگوهای آزاد با شرکت‌کنندگان. گاهی از سخنرانی‌ها کمتر، و از تعامل با افراد بیشتر یاد می‌گیرم.
با ظهور عامل‌های هوش مصنوعی (AI Agents) و MCP، فکر می‌کنی مهندسی پلتفرم و توسعه‌ی API چگونه تغییر می‌کند؟
به‌طور کامل. تا سال گذشته ابزارهای هوش مصنوعی بیشتر باعث افزایش کار می‌شدند تا کاهش آن. اما امسال، با ظهور Agents و MCPها (Model Context Protocols)، به نقطه‌ی عطفی رسیده‌ایم.
الگوهای جدیدی در حال ظهورند که نشان می‌دهند چطور هوش مصنوعی می‌تواند واقعاً مفید باشد. تغییرات در این حوزه به سرعتی رخ می‌دهند که از دوران Kubernetes یا AWS هم سریع‌تر است.
کسانی که امروز در برابر این موج مقاومت می‌کنند، ممکن است خیلی زود عقب بمانند — حتی تخصص انسانی هم اگر با این سرعت پیشرفت هماهنگ نشود، منسوخ خواهد شد.
در مورد MCP بیشتر بگو — چرا معتقدی بسیاری از سرورهای MCP فعلی اتلاف وقت هستند؟
چون اغلب آن‌ها فقط بازتاب (mirror) ساده‌ای از APIها هستند. در حالی که هدف MCP باید ارائه‌ی ارزش افزوده بر پایه‌ی نیت کاربر (user intent) باشد.
به‌عنوان مثال، یک سرور MCP برای Kubernetes نباید فقط endpointها را تکرار کند، بلکه باید بتواند کارهایی مثل راه‌اندازی کامل یک اپلیکیشن را با ترکیب چند منبع انجام دهد.
MCP زمانی واقعاً مفید است که کاری انجام دهد که یک عامل (Agent) یا مدل هوش مصنوعی به‌تنهایی از API برنمی‌آید — یعنی اجرای فرایندها و workflowهای معنادار، نه فقط تماس مستقیم با endpointها.
آیا MCPها در دنیای APIهای تجاری یا عمومی هم مفید هستند؟
قطعاً بله، اما فقط اگر صرفاً بازتاب API نباشند. برای مثال، در یک API بانکی، یک تابع ساده مثل withdraw_funds (برداشت وجه) به‌مراتب مؤثرتر از مجموعه‌ای از ۵۰ فراخوانی جداگانه‌ی endpoint است.
MCP باید همان نقشی را ایفا کند که رابط کاربری برای انسان‌ها دارد — ساده‌سازی، هدف‌محوری و جلوگیری از پیچیدگی غیرضروری.
