SaaS and Micro-SaaS Proliferation Requires a New Type of Web API
کاملاً برای هر کسی که اخبار فناوری را دنبال می‌کند روشن است که صنعت IT در حال تجربه یک انفجار کامبریایی در حوزه اپلیکیشن‌های تجاری است؛ تعداد فزاینده‌ای از سرویس‌های SaaS و Micro-SaaS بسیار تخصصی در حال تأمین سرمایه و عرضه هستند. این روند نه تنها توسط سرمایه‌گذاری خطرپذیر و پیشرفت‌های اخیر هوش مصنوعی، بلکه همچنین توسط اخراج‌های گسترده در صنعت نرم‌افزار تقویت شده است.
در اینجا استدلال می‌کنم که بخش IT برای این چشم‌انداز فوق‌العاده تکه‌تکه‌ی جدید آماده نیست. من ادغام را پاشنه آشیل این دنیا می‌دانم، زیرا کاستی‌های پروتکل ۲۴ ساله REST و دیگر پروتکل‌ها—مانند فقدان ترکیب‌پذیری و تعاملی بودن—هر روز آشکارتر می‌شوند.
با توجه به این محدودیت‌های ادغام، فروشندگان مجموعه‌های نرم‌افزاری بزرگ همچنان مزیت رقابتی دارند، زیرا می‌توانند برنامه‌هایی با ادغام نزدیک ارائه کنند که بر زیرساخت داخلی مشترک متکی هستند. مسئولیت بر دوش فروشندگان فناوری ادغام است تا میدان را میان مجموعه‌های نرم‌افزاری و برنامه‌های بهترین-در-نوع خود برابر کنند و نوآوری جمعی را آزاد سازند. خبر خوب این است که این کار ممکن است.
تغییر صنعت نرم‌افزار یک فرصت برای صنعت API است
امروزه کسب‌وکارها بیش از هر زمان دیگری به SaaS وابسته‌اند و کارکنان باید بین تعداد رو‌به‌رشدی از برنامه‌ها جابه‌جا شوند. یک بررسی توسط Better Cloud نشان داد که سازمان‌ها در سال ۲۰۲۱ به‌طور متوسط از ۱۱۰ اپلیکیشن SaaS استفاده کرده‌اند—افزایشی ۳۸ درصدی نسبت به سال قبل.
و اما وضعیت کارکنان در این محیط چگونه است؟ بررسی Gartner نشان داد که تعداد متوسط برنامه‌هایی که یک کارگر دانشی در سال ۲۰۲۳ استفاده می‌کرد، ۱۱ برنامه بوده است، در مقایسه با ۶ برنامه در سال ۲۰۱۹. چهل درصد از کارکنان دیجیتال بیش از میانگین برنامه استفاده می‌کنند، و ۵٪ از کارکنان از ۲۶ برنامه یا بیشتر در محل کار استفاده می‌کنند.
در مقایسه با ارائه‌دهندگان مجموعه‌های نرم‌افزاری بزرگ، مزیت بزرگ استفاده از نرم‌افزارهای SaaS تخصصی این است که کسب‌وکارها می‌توانند بهترین راهکار را در هر دسته نرم‌افزاری انتخاب کنند. اما یکی از معایب این رویکرد این است که یکپارچه‌سازی سیستم IT اکنون به مشکلی دشوار تبدیل می‌شود. ادغام یک نتیجه ارزشمند تجاری است، زیرا از یک طرف کسب‌وکارها نمای یکپارچه از IT خود را ترجیح می‌دهند و از طرف دیگر کارکنان نمی‌خواهند برای انجام یک کار میان چند برنامه مختلف تغییر زمینه دهند. بنابراین موضوع تنها ادغام IT نیست، بلکه ادغام تجربه کاربری نیز هست.
چه چیزی در چشم‌انداز فعلی Web API کم است؟
برای درک اینکه چرا ادغام یکی از مشکلات حل‌نشده SaaS است، مفید است وضعیت فعلی را بررسی کنیم. اول اینکه این واقعیت که اکثریت برنامه‌های SaaS یک REST API ارائه می‌دهند، نشانه‌ای واضح از آن است که خود فروشندگان SaaS ادغام‌ها را مأموریتی حیاتی می‌دانند. دوم اینکه اتکا به یک پروتکل API ۲۴ ساله نشان می‌دهد که در لایه پایه همه نرم‌افزارهای شبکه‌ای، نوآوری بسیار کم بوده است.
نکته مهمی که REST و سایر پروتکل‌ها فاقد آن هستند، ترکیب‌پذیری است. این بدان معناست که یک API نمی‌تواند در پشت صحنه API دیگری را فراخوانی کند، اگر احراز هویت کاربر نهایی لازم باشد.
در نتیجه، REST و پروتکل‌های مشابه تنها زمانی اجازه تماس API-به-API می‌دهند که احراز هویت کاربر ضروری نباشد. برای مثال، REST همچنان برای ارتباط سرور-به-سرور مناسب است، اگر APIها تنها نیاز داشته باشند سرور فراخوان را تأیید کنند نه کاربر نهایی را.
مشکل دیگر این است که وقتی APIها مجاز به فراخوانی یکدیگر پشت صحنه هستند، در برخی موارد توسعه‌دهندگان API دیگر نمی‌توانند تضمین کنند که پاسخ API به‌موقع خواهد بود، زیرا دیدی نسبت به زنجیره وابستگی APIها ندارند. این وضعیت حتی ممکن است به timeout شبکه و قطع شدن فراخوانی منجر شود.
اما چرا ترکیب‌پذیری برای یک اکوسیستم سالم API ضروری است؟ برای پاسخ، مفید است بین APIهای درگیر در فرایندهای کاربرمحور و APIهایی که در backend فراخوانی می‌شوند و از فرایندهای کاربرمحور جدا هستند تفاوت قائل شویم. برای دسته دوم، خطر timeout قابل کنترل است، اما برای دسته اول، احراز هویت کاربر و در نتیجه ترکیب‌پذیری ضروری است.
حال بیایید معماری‌هایی را بررسی کنیم که صنعت IT در نبود APIهای ترکیب‌پذیر ایجاد کرده است. نخست، micro-frontend ها. این‌ها API نیستند بلکه بخش‌هایی از صفحات وب‌اند و نمی‌توان آنها را بیش از چند سطح تو در تو کرد. همچنین معمولاً تنها برای سناریوهای درون‌سازمانی مناسب‌اند نه میان‌سازمانی.
دوم، معماری MACH. این معماری از APIهای غیرترکیب‌پذیر مانند REST برای برنامه‌های کاربرمحور استفاده می‌کند. در این معماری، frontend اپلیکیشن هم گلوگاه عملکرد است (زیرا باید لایه UI تمام APIها را پیاده‌سازی کند و تمام ادغام‌های API-به-API نیز باید از طریق frontend انجام شود) و هم یک ریسک امنیتی (زیرا APIها باید به یک frontend ثالث اعتماد کنند که اطلاعات هویتی کاربران را سوءاستفاده نکند).
عصر Web API ترکیب‌پذیر
حال تصور کنیم یک پروتکل API ترکیب‌پذیر چگونه خواهد بود. واضح است که داشتن دسترسی مستقیم به کاربر نهایی امن‌ترین روش احراز هویت است، بدون اینکه نیاز باشد به هیچ شخص ثالثی اعتماد شود، پس باید این قابلیت در فهرست نیازمندی‌ها قرار گیرد.
همچنین مشخص است که وقتی یک API تعاملی باشد، این قابلیت تعامل را می‌توان برای فرایندهای مختلفی به‌کار گرفت، نه فقط برای احراز هویت. APIهای تعاملی اساساً نوع جدیدی از API هستند که در سطح منطق تجاری عمل می‌کنند و علاوه بر آن، رابط کاربری خود را نیز ارائه می‌دهند.
در این سناریو می‌توان یک پلتفرم عمومی برای برنامه‌های توزیع‌شده ایجاد کرد، جایی که کاربر نهایی بر اساس نیازهای وظیفه از APIیی به API دیگر هدایت می‌شود. تجربه کاربری بسیار شبیه استفاده از یک برنامه تک‌سایتی باقی می‌ماند. این موضوع و حذف نیاز به جابه‌جایی میان برنامه‌ها باعث کاهش بار شناختی کاربر می‌شود.
این پلتفرم API را می‌توان ارتقایی برای پلتفرم وب تصور کرد، و بلافاصله مشخص می‌شود که برنامه‌های توزیع‌شده یک توانایی کاملاً جدید هستند که نه پلتفرم وب کنونی و نه پلتفرم‌های بومی دسکتاپ یا موبایل قادر به ارائه آن نیستند.
چه قابلیت‌هایی توسط چنین پلتفرمی باز می‌شود؟ برنامه‌های توزیع‌شده می‌توانند روی برنامه‌های داخلی، برنامه‌های شرکای تجاری و SaaS ساخته شوند تا سیستم‌های IT یکپارچه و UXهای کارمندی ایجاد کنند. هر ترکیبی از برنامه‌های داخلی، شریکی و SaaS می‌تواند با یکدیگر ادغام شود. لایه رابط کاربری معماری‌های microservice می‌تواند روی چندین وب‌سایت پخش شود و گلوگاه‌های بهره‌وری برای تیم‌هایی که به‌صورت موازی کار می‌کنند حذف شود.
در نهایت، پیاده‌سازی ادغام‌ها بسیار آسان‌تر از REST و APIهای مشابه خواهد بود، زیرا بخش زیادی از رابط کاربری و تمام احراز هویت توسط خود API انجام می‌شود. همچنین نیازی به API key نخواهد بود، زیرا فراخوانی API شبیه بازنشانی‌های معمولی صفحات وب خواهد بود.
نتیجه‌گیری
عصر جدیدی از گسترش SaaS و Micro-SaaS آغاز شده است. این مسیری درست برای صنعت IT است، حتی با وجود چالش‌های جدیدی که اکنون آشکار می‌شوند.
