مقصدهای رویداد: روشی بهتر برای ارسال Webhookها
در توسعه همزمان API، سبک غالب REST است که در آن یک کلاینت درخواست یک منبع را از سرور می‌فرستد و پاسخ دریافت می‌کند. با این حال، معماری نرم‌افزارها روزبه‌روز رویدادمحور (event-driven) می‌شود و به رویدادهای خارجی تکیه می‌کند تا تغییرات را به صورت غیرهمزمان به کلاینت ارسال کند.
رویدادها نیاز به بررسی مداوم سرور برای تغییرات را از بین می‌برند و برای به‌روزرسانی‌های زمان واقعی مانند قیمت سهام، وضعیت پرواز خطوط هوایی، هشدارهای هواشناسی و غیره یا برای فعال‌سازی جریان‌های کاری بر اساس رویدادهای پلتفرم‌هایی مثل Stripe، GitHub، Shopify و Twilio ایده‌آل هستند.
برای سال‌ها، Webhookها به فرمت غالب برای ارسال رویدادهای رویدادمحور در پلتفرم‌های API تبدیل شده‌اند تا این رویدادها را به سایر پلتفرم‌ها، ادغام‌ها یا اپلیکیشن‌ها منتقل کنند. Webhookها همه‌جا رایج هستند — طبق گزارش The 2024 State of Webhooks توسط Svix، ۸۵٪ از ۱۰۰ شرکت برتر API از Webhook استفاده می‌کنند.
با این حال، Webhookها هرگز واقعاً استاندارد نشده‌اند. با وجود تلاش‌ها، هنوز نسخه‌های مختلفی از Webhookها با نوع payload و روش‌های احراز هویت متفاوت وجود دارند. این باعث ناسازگاری در عملکرد و تفاوت‌های امنیتی در پیاده‌سازی‌ها شده است.
طبق گفته Phil Leggetter، رئیس روابط توسعه‌دهندگان در Hookdeck، نبود رویکردهای جهانی برای ارسال رویداد باعث می‌شود هم تولیدکنندگان و هم مصرف‌کنندگان رویداد در کوتاهی باشند. اکثر اوقات، ارائه‌دهندگان API بسیاری از مسئولیت‌های مربوط به رویدادها را به مصرف‌کنندگان واگذار می‌کنند، که منجر به ناکارآمدی و تجربه ضعیف توسعه‌دهنده می‌شود. برخی تولیدکنندگان رویداد اقداماتی مانند تلاش‌های خودکار و دستی مجدد، ابزارهای اشکال‌زدایی و مشاهده‌پذیری، و ارائه انواع مختلف مقصدهای رویداد را انجام می‌دهند، اما پذیرش آن‌ها پراکنده و بسیار سلیقه‌ای است.
ابتکار Event Destinations
ابتکار Event Destinations یک پروژه جامعه‌ای است که توسط Hookdeck هدایت می‌شود و به عنوان «مدلی برای همکاری رویداد بین تولیدکنندگان و مصرف‌کنندگان رویداد» توصیف شده است. این پروژه به جای ارائه یک مشخصه رسمی، مجموعه‌ای از دستورالعمل‌ها و راهنمایی‌ها برای تولیدکنندگان رویداد ارائه می‌دهد.
در ادامه وضعیت فعلی ارسال رویدادها و نحوه عملکرد Event Destinations بررسی شده و برخی مزایا و روش‌های پیاده‌سازی آن توضیح داده می‌شود.
وضعیت فعلی ارسال رویدادها
در توسعه با Webhookها، معمولاً وضعیت فعلی این است که یک اپلیکیشن رویداد را دریافت کرده و قبل از timeout درخواست HTTP واردشده، منطق خود را اجرا کند. Leggetter می‌گوید: «این روش شکننده است و به تایم‌اوت معقول ارائه‌دهنده API وابسته است.»
بهترین روش پیشنهادی استفاده از ترکیبی از سرویس‌ها برای اعتبارسنجی، ذخیره و پردازش Webhookها است تا قابلیت اطمینان و مشاهده‌پذیری بهبود یابد. این ترکیب می‌تواند شامل load balancerها، HTTP ingest workerها، صف‌های پیام، یا مکانیزم‌های blob storage باشد.
با Webhookها، بخش‌هایی مانند امنیت و بهینه‌سازی عملکرد اختیاری هستند و مسئولیت اصلی به کلاینت منتقل می‌شود. همچنین قابلیت اطمینان نگرانی است — نقاط پایانی HTTP عمومی اغلب نرخ شکست بالایی دارند و تحویل‌ها به دفعات متعدد تکرار می‌شوند، طبق گفته Leggetter. مشکلات معمولاً از نقطه پایانی HTTP دریافت‌کننده رخ می‌دهد، نه از خود درگاه‌ها.
برای تولیدکنندگان رویداد، محدود شدن به پشتیبانی از نقاط پایانی HTTP ساده هزینه دارد. Leggetter می‌گوید: «در سمت تولیدکننده، مجبورید زیرساختی برای حداقل امکانات بسازید: منابع سرور وب ناکافی که رویدادها را دریافت می‌کنند.»
چگونگی تغییر Event Destinations
به جای انتشار رویدادها به نقاط پایانی HTTP و تکیه بر توسعه‌دهنده مصرف‌کننده برای مسیردهی آن‌ها از طریق message bus، Event Destinations مدل را تغییر می‌دهد و نقاط اشتراک مختلف برای رویدادها ارائه می‌کند. سایت Event Destination می‌پرسد:
«چرا به نقاط پایانی HTTP عمومی ناکارآمد وابسته باشیم؟ چرا رویدادها را مستقیماً به مقصدهای امن و کارآمد نفرستیم؟»
این مقصدهای رویداد شامل پلتفرم‌های محبوب مانند Amazon EventBridge, Kafka, Google Cloud Pub/Sub, AWS SQS, Hookdeck Event Gateway, RabbitMQ و دیگران هستند. اگرچه همه از HTTP یا ingest Webhook استفاده نمی‌کنند، معمولاً تجربه توسعه‌دهنده بهتری و قابلیت اطمینان بالاتر فراهم می‌کنند.
پیاده‌سازی Event Destinations
Event Destinations به دنبال افزایش قابلیت اطمینان و پیش‌بینی‌پذیری مدیریت رویدادها برای تولیدکنندگان و مصرف‌کنندگان است. چهار حداقل الزام برای Event Destinations شامل موارد زیر است:
-
حداقل دو نوع مقصد رویداد، شامل Webhook
-
تلاش‌های خودکار برای تحویل با exponential backoff
-
APIهایی برای ایجاد، به‌روزرسانی و حذف مقاصد
-
اعلان‌ها برای خطاهای مقصد
همچنین توصیه‌هایی برای تضمین تحویل، داشتن موضوعات اشتراک، مدیریت تلاش‌های متعدد، فیلترینگ و تجربه توسعه‌دهنده ارائه شده است. Hookdeck همچنین از Outpost، پیاده‌سازی متن‌باز Event Destinations پشتیبانی می‌کند.
استفاده واقعی و مزایا
Event Destinations تنها یک مفهوم نظری نیست — از کاربردهای واقعی الهام گرفته شده است. برای مثال:
-
Stripe اجازه می‌دهد مصرف‌کننده API به‌روزرسانی‌ها را از طریق چند نوع مقصد، مانند Amazon EventBridge و Webhook دریافت کند.
-
Shopify از چندین مقصد رویداد پشتیبانی می‌کند.
-
Twilio منابع مختلفی برای تحویل رویداد ارائه می‌دهد.
مزایای این مدل برای تولیدکنندگان شامل کاهش شکست‌ها و تلاش‌های مجدد، کاهش سربار عملیاتی، انعطاف‌پذیری پروتکل و بهبود تجربه توسعه‌دهنده است. Leggetter می‌گوید: «این مدل شامل Webhookها هم می‌شود، اما تشویق به استفاده از جایگزین‌های بهتر در مقیاس بالاست.»
برای مصرف‌کنندگان، کارایی و تجربه توسعه‌دهنده بهبود می‌یابد، زیرا می‌توان از راهکارهای صف‌بندی موجود استفاده کرد و نیازی به اضافه کردن زیرساخت برای مدیریت HTTP ingestion نیست.
افزودن ارزش در ارسال رویدادها
Webhookها هنوز در مقیاس بزرگ سخت مدیریت می‌شوند و با میلیاردها تحویل غیر استاندارد در هر ماه، «کشتی قبلاً حرکت کرده است»، طبق گفته Leggetter.
Event Destinations به جای ایجاد یک استاندارد جهانی جدید، به شناخت تفاوت‌های انواع رویداد و پلتفرم‌ها و بازاندیشی در تحویل رویداد با توجه به تجربه توسعه‌دهنده می‌پردازد. Leggetter می‌گوید:
«به جای تشویق به روش متفاوت، این روش ارزش می‌افزاید.»
