كل المقالات

لماذا يبدو الـ⁨API⁩ بطيئًا: القصة كاملة في رسمتين

الباك اند · 3 دقيقة قراءة ·

قال لي أحد العملاء ذات مرة: "زر التسجيل يستغرق 4 ثوانٍ، يجب إصلاح قاعدة البيانات." لم تكن المشكلة في قاعدة البيانات إطلاقًا. كانت الـ⁨API⁩ ترسل بريد ترحيب قبل أن تردّ على المستخدم. هذه هي المشكلة كاملة في رسمة واحدة:

المتصفح خادمك خدمة البريد 3 ثوانٍ كاملة المستخدم يحدّق في مؤشر التحميل طوال هذا الوقت
كل شيء يحدث في خط واحد. أبطأ خطوة هي التي تحدّد زمن الاستجابة.

الحل: الردّ أولًا، والعمل لاحقًا

المستخدم لا يحتاج أن يكون البريد قد أُرسل فعلًا قبل أن يرى "تم إنشاء الحساب". يحتاج فقط إلى الوعد بأنه سيُرسل. لذلك نقسّم الخط الزمني: نردّ فورًا، وندفع بالعمل البطيء إلى طابور يعالجه عامل في الخلفية.

المتصفح خادمك «تم!» خلال 50 مللي ثانية المهام تتراكم هنا، لا أحد ينتظرها الطابور العامل يُرسَل البريد بعد ثوانٍ
خطّان زمنيّان بدل خط واحد. المستخدم لا يرى إلا القصير منهما.

في ⁨Laravel⁩ هذا ثلاثة أسطر فقط

ادفع بالعمل إلى مهمة في الطابور، وردّ فورًا:

SendWelcomeEmail::dispatch($user);⁩ داخل الـ⁨controller⁩، و⁨php artisan queue:work⁩ على الخادم، و⁨QUEUE_CONNECTION=redis⁩ في متغيرات البيئة. هذا هو النمط بالكامل.

القاعدة التي أطبّقها في كل مشروع: إن كان المستخدم لا يحتاج نتيجة مهمة ما ليكمل، فهذه المهمة لا مكان لها داخل الطلب. رسائل البريد، ملفات الـ⁨PDF⁩، تصغير الصور، الـ⁨webhooks⁩، التحليلات: كل هذا ينتقل إلى طابور.

في ⁨Tamkeen⁩ قضيت جزءًا كبيرًا من ستة أشهر في نقل العمل من داخل الطلبات إلى الطوابير. نفس الخوادم، نفس قاعدة البيانات، ونقاط النهاية التي كانت تستغرق ثوانٍ صارت تردّ خلال عشرات المللي ثانية.

ملاحظات القراء

  1. لا توجد ملاحظات بعد. الأولى دائمًا الأجرأ.
باغي دير حاجة بحال هذي؟ نقدر نعاونك. تواصل