webhooks مقابل الاستطلاع

عندما نقوم ببناء تطبيقات الويب، غالبًا ما يكون لدينا خدمات متعددة. في الغالبية العظمى من الحالات، تتكون من العديد من خدمات الويب المختلفة التي تعمل معًا. في هذا النوع من تطبيقات الويب التي تتكون من خدمات متعددة، يعد كيفية نقل البيانات أمرًا يحتاج كل مطور إلى النظر فيه.

عندما يتعلق الأمر بحل هذه المشكلة، أصبح هناك نهجان سائدان: webhooks والاستطلاع. يوفر كل منهج طريقة فريدة لجلب وإرسال البيانات من خدمة إلى أخرى. قد يكون لاختيار واحد على الآخر تأثير كبير على كفاءة التطبيق وقدراته في الوقت الحقيقي وتجربة المستخدم العامة. ستقارن هذه المقالة بين webhooks والاستطلاع، وتحلل المزايا والعيوب لكل منهما، وتناقش متى يجب استخدام كل منهما.

ما هو الاستطلاع؟#

الاستطلاع (يشار إليه غالبًا باستطلاع API) هو العملية التي يطلب فيها العميل بيانات محددة على فترات منتظمة (لنفترض، كل x ثانية)، ويستجيب الخادم بالبيانات المطلوبة.

تفكر فيها كأنك تسأل، "هل هناك أي بيانات جديدة؟" على فترات منتظمة. يمكن تنفيذ الاستطلاع عبر طلبات HTTP، حيث يرسل العميل طلب GET إلى الخادم والخادم يستجيب بالبيانات المطلوبة.

تخيل أن جون أنشأ منتج وثائق AI اسمه Doc.AI ويستخدم Logto لإدارة هوية المستخدم.

فرانك هو مستخدم قام بالتسجيل في منتج جون وأنشأ حسابه الخاص. في يوم من الأيام، ينضم فرانك إلى مساحة عمل أنشأها صديقه ديفيد. في تلك اللحظة، يريد جون إرسال بريد إلكتروني إلى فرانك ليطلب منه تشغيل المصادقة متعددة العوامل (MFA) لتعزيز أمان حسابه قبل أن يمنحه جون الوصول إلى موارد حساسة إضافية.

يحتاج الواجهة الخلفية لمنتج جون إلى استطلاع API ذات الصلة باستمرار لمعرفة متى ينضم فرانك إلى مساحة عمل ديفيد.

ما هو webhook؟#

الويبهوك (أي "استدعاء HTTP") هو آلية للتواصل في الوقت الحقيقي، حيث يرسل الخادم بيانات إلى العميل عند وقوع حدث. بدلاً من طلب العميل للبيانات، يقوم الويبهوك بدفعها إلى العميل في كل مرة يكون هناك تحديث.

تفكر فيه كأنه صندوق بريد لتطبيقك. عندما تحدث أحداث معينة - على سبيل المثال، قيام مستخدم جديد بالتسجيل أو إجراء دفع - سيلقي الويبهوك رسالة في صندوق البريد لإعلام تطبيقك بما يحدث.

دعنا نستمر مع مثالنا Doc.AI الذي استخدمناه سابقًا لشرح الاستطلاع. إليك كيف سيبدو مخطط التسلسل إذا كنا نستخدم webhooks لمعرفة ما إذا كان فرانك قد انضم إلى مساحة عمل ديفيد:

الاختلافات المهمة#

• أصل الطلب يتم بدء الاستطلاع من قبل العميل (في مثالنا، Doc.AI هو العميل وLogto هو الخادم) ويتم تفعيل الويبهوك بواسطة الحدث ويبدأ من قبل الخادم.
• استهلاك الموارد يعتبر الاستطلاع إهدارًا للموارد الحسابية لأنه يرسل طلبات على فترات منتظمة، مما يؤدي إلى انخفاض كفاءة الموارد الحسابية. من ناحية أخرى، يتم بدء الويبهوك من قبل الخادم "عند الطلب". مقارنة بالاستطلاع، يستهلك كل من العميل والخادم موارد أقل بكثير.
• التوقيت يتم بدء الاستطلاع من قبل العميل، لذا يمكن للعميل التحكم في توقيت الحصول على البيانات؛ ومع ذلك، يتم بدء الويبهوك من قبل الخادم، ويمكن للعميل فقط استقبال ومعالجة البيانات. ومع ذلك، بسبب الاختلاف في الآليات بين الاثنين، يمكن للويبهوك تحقيق مزامنة البيانات في الوقت الحقيقي، وهو ما لا يمكن تحقيقه بواسطة الاستطلاع.

أيهما يجب أن أختار؟#

استنادًا إلى آليتي الاستطلاع والويبهوك، فإن الممارسة الشائعة هي اختيار الاستطلاع فقط عندما يتم تحديث البيانات بشكل متكرر ولا تكون متطلبات الوقت الفعلي للبيانات صارمة. في الحالات الأخرى، يكون الويبهوك هو الخيار الأفضل.

ومع ذلك، عند اختيار استخدام الويبهوك، يحتاج المطورون إلى الانتباه إلى المخاوف التالية:

1. إذا كان النظام يعتمد بشكل كبير على البيانات المكتسبة، فمن الضروري النظر في وجود خطة احتياطية لاكتساب البيانات عند فشل الويبهوك وعدم القدرة على مزامنة البيانات، بما في ذلك ولكن لا يقتصر على الاستطلاع أو طلب من الويبهوك أن يكون لديه آلية إعادة إرسال، وما إلى ذلك.
2. في نقطة النهاية من جانب العميل التي تستقبل الويبهوك، يجب تطبيق التحقق من سرية API وتوقيع المحتويات، وما إلى ذلك، لمنع المتسللين من مهاجمة العميل بتزوير الويبهوك.
3. بما أن الويبهوك قد يرسل طلبات مكررة، يتطلب في هذا الوقت معالجة مماثلة لمنع تكرار البيانات وعدم التناسق.

يقدم Logto، كحل شائع بشكل كبير لتحديد هوية المستخدم، مشاهد ويبهوك غنية وأمانًا ممتازًا. باستخدام Logto كنظام هوية لمنتجاتك، يمكن دمجه بسهولة ليناسب مختلف مشاهد التطبيقات.