Trigger.dev: متى تختارها لتشغيل المهام الخلفية؟

ما الذي يمكن أن تستبدله Trigger.dev؟

تجمع Trigger.dev بين مشغّل مهام وطوابير وجدولة ونشر ولوحة لمتابعة التشغيل. تكتب دالة غير متزامنة، وترسل إليها بيانات الإدخال، ثم تنفّذها عملية عاملة مستقلة بينما يعيد تطبيقك استجابة للمستخدم. ويمكنها أن تستبدل البنية التحتية التي كنت ستجمع مكوّناتها بنفسك لتشغيل المهام الخلفية؛ لكنها لا تستبدل قاعدة بيانات تطبيقك أو قواعد عمله أو النموذج الذي يتخذ قرارات وكيل الذكاء الاصطناعي.

جرت مراجعة المعلومات بالرجوع إلى الوثائق والأسعار وسجل التغييرات ومستودع GitHub المتاحة وقت المراجعة في 11 نوفمبر 2026. يستند هذا التقييم إلى الوثائق، من دون اختبار بحساب مسجّل أو قياس للأداء. وتقوم التوصية على مسؤولية إدارة بيئة التشغيل، وحدود التعافي من الأعطال، وسهولة الاستخدام للمشغّلين، وقيود بيئة الإنتاج.

أضاف سجل إطلاق v4، المؤرخ في 18 أغسطس 2025، بدء التشغيل الدافئ، ونقاط انتظار للموافقات والاستدعاءات الراجعة، وترتيب الطوابير حسب الأولوية، وتغييرات في لوحة التحكم، وخطافات لدورة الحياة. أما أحدث إصدار مُدرج وقت التحقق، وهو v4.8.4 الصادر في 10 نوفمبر 2026، فيضيف هوية أحمال العمل والنشر الموثوق. وتتيح ميزات الهوية هذه للخدمات وأنظمة النشر المدعومة المصادقة برموز هوية قصيرة العمر بدلًا من بيانات اعتماد مخزّنة طويلة العمر.

بالنسبة إلى مؤسس شركة، يتمثل الفرق العملي في تحويل «إنشاء التقرير بعد رفع الملف» إلى مهمة خلفية مُدارة، بدلًا من إبقاء نقطة نهاية ويب مفتوحة حتى يكتمل التقرير. ويظل على تطبيقك تسجيل العميل الذي يخصه كل تقرير، وتحديد ما يحدث عند فشل إنشائه.

لمن تناسب المنصة، ومتى يُفضّل اختيار غيرها؟

تناسب Trigger.dev منتجًا يتولى فريق هندسي تطويره، وتكون شيفرة مهامه الخلفية جزءًا طبيعيًا من بقية شيفرة TypeScript. وكلما اقترب احتياجك من «تشغيل هذه الدالة بموثوقية مع اعتمادياتها»، زادت ملاءمتها.

تقارن القائمة التالية المكان الذي تصف فيه سير العمل والمسؤوليات التي تبقى عليك. هذه اختيارات معمارية، وليست ترتيبًا للمورّدين بحسب طول قائمة الميزات.

n8n: عندما يتولى مشغّل إدارة سير العمل

تكون n8n أنسب لمسؤول عمليات المبيعات الذي يربط استقبال العملاء المحتملين بإثراء بياناتهم ومتابعتهم. يتيح نهجها البصري فحص العملية من دون تحويل كل تعديل إلى تغيير في شيفرة التطبيق. وهي تدعم الذكاء الاصطناعي وأتمتة الأعمال، لذا فإن عبارة «نحتاج إلى وكيل» لا تكفي وحدها لاستبعادها.

المفاضلة هنا تتعلق بمن يتولى العمل. إذا كانت الصعوبة في منطق تطبيق مخصّص له مكتبات واعتماديات نشر، فقد تكون صيانة مهمة TypeScript أسهل من صيانة مخطط بصري يتضخم باستمرار. أما إذا كانت الصعوبة في تمكين المشغّل من تعديل خطوات العمل، فإن Trigger.dev تجعل هذا المشغّل معتمدًا على الفريق الهندسي. راجع المقارنة الأوسع لبدائل n8n لاتخاذ قرار الشراء هذا.

مقارنة Inngest مع Trigger.dev

تُعد Inngest أقرب الخيارات للمقارنة لدى المطورين الذين يريدون دوال يمكنها استكمال التنفيذ بعد الأعطال. تصف وثائقها الحالية حفظ نتائج الخطوات وإعادة المحاولة من الخطوة الفاشلة، مع حزم SDK للغات TypeScript وPython وGo. لذلك تستحق النظر عندما ينقسم التطبيق بطبيعته إلى خطوات مسمّاة، أو عندما يريد فريق Python كتابة مسارات العمل بلغة Python.

تتمثل جاذبية Trigger.dev في توفير بيئة تشغيل المهمة واعتمادياتها مع التنسيق. أما نموذج الخطوات الصريح في Inngest فيُظهر حدود التعافي داخل الشيفرة. ولا يعفيك أي الخيارين من جعل عمليات الكتابة الخارجية آمنة عند تكرارها. اختر وفق الطريقة التي تريد بها نشر حمل العمل وفهم الأعطال، لا على أساس افتراض أن إحداهما وحدها تدعم الانتظار أو الوكلاء.

Temporal: عندما يتعلق القرار ببناء المنصة

تستحق Temporal مكانًا ضمن الخيارات عندما تمتد عملية أعمال عبر خدمات متعددة، وتكون دورة حياتها أهم من سرعة نشر دالة خلفية. تغطي وثائقها حزم SDK بلغات متعددة ونشر تطبيقك إلى جانب خدمة Temporal مستضافة ذاتيًا أو مُدارة.

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

كيف تكتب مهمة خلفية وتنشرها وتعيد محاولتها؟

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

المثال التالي هو مثال البداية البسيط في وثائق المهام، بعد حذف التعليقات وإضافة تصدير حتى يمكن اكتشاف المهمة واستيرادها:

import { task } from "@trigger.dev/sdk";

export const helloWorld = task({
  id: "hello-world",
  run: async (payload: { message: string }) => {
    console.log(payload.message);
  },
});

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

تميّز وثائق إعادة المحاولة بين إعادة محاولة المهمة، وإعادة محاولة كتلة أصغر باستخدام retry.onThrow، أو طلب HTTP باستخدام retry.fetch. فقد تعيد محاولة المهمة تنفيذها كاملة. وإذا نجحت معالجة الاستيراد ثم أخفق إشعار لاحق، فقد تؤدي إعادة كل شيء بلا تمييز إلى تكرار عمليات الكتابة السابقة.

قاعدة التصميم: أعد محاولة الأعطال المؤقتة بالقرب من العملية التي أخفقت، واجعل عمليات الكتابة متساوية الأثر عند التكرار، أي إن تكرار العملية نفسها لا يُحدث أثرًا تجاريًا إضافيًا. توفّر منصة المهام آليات التعافي؛ لكن قيود قاعدة بياناتك واختيارات واجهات API الخارجية هي التي تحدد ما إذا كانت إعادة المحاولة ستكرر فاتورة أو رسالة بريد أو سجلًا.

استخدام Python مع Trigger.dev

تستطيع Trigger.dev تنفيذ برامج Python داخل مهام TypeScript عبر إضافة البناء الخاصة بـ Python. يفيد ذلك عندما يكون منتج الويب مكتوبًا بلغة TypeScript، بينما محلّل المستندات مكتوب بلغة Python. إنها جسر بين بيئتي تشغيل، وليست تجربة تطوير مماثلة لحزمة SDK أصلية لسير العمل بلغة Python.

هناك تفصيل مهم عند النشر: تثبيت requirementsFile عبر الإضافة يعمل في بيئة الإنتاج فقط؛ أما اعتماديات التطوير فيجب تثبيتها محليًا. ونجاح المحلّل على حاسوب محمول لا يثبت صحة اعتمادياته بعد النشر.

كيف توقف الوكيل انتظارًا لموافقة أو استدعاء راجع؟

تتيح نقاط الانتظار في Trigger.dev إيقاف سير العمل إلى أن يقدّم شخص أو خدمة خارجية النتيجة الناقصة. في وكيل لاسترداد الأموال، يعني ذلك فصل «التوصية بالاسترداد» عن «تنفيذ الاسترداد». يمكن للمهمة إعداد التوصية، وانتظار الموافقة، ثم المتابعة بعد وصول نتيجتها فقط.

يستخدم شرح نقاط الانتظار من مطوّري المنصة الدوال wait.createToken وwait.forToken وwait.completeToken لتنفيذ هذا التسليم. ويعرض أيضًا عناوين URL للاستدعاءات الراجعة من الخدمات الخارجية. ويظل التطبيق هو من يقرر مَن يحق له الموافقة، وما الذي تسمح به الموافقة.

للوقت والتكلفة ضوابط منفصلة. تقول وثائق الانتظار الحالية إن الانتظار المحدد بمدة تتجاوز 5 ثوانٍ لا يُحتسب ضمن استهلاك الحوسبة. لكنه لا يحرّر خانة التنفيذ المتزامن إلا بعد أخذ لقطة لحالة الآلة وإيقافها، بعد مرور 60 ثانية من الانتظار. لذلك قد يكون الانتظار الأقصر معفيًا من تكلفة الحوسبة مع بقائه شاغلًا لخانة تنفيذ.

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

أما طبقة استدلال الوكيل، فراجع لها المقارنة المنفصلة لأطر عمل وكلاء الذكاء الاصطناعي. تستطيع بيئة تشغيل Trigger.dev إبقاء العمل مستمرًا، لكن اختيار التعليمات والأدوات وقواعد الموافقة هو ما يحدد سلوك الوكيل.

جدولة المزامنة مع توضيح افتراضات التوقيت

تدعم Trigger.dev العمل الدوري عبر schedules.task، مع تعريف الجداول في الشيفرة أو إرفاقها من لوحة التحكم وحزمة SDK. ومزامنة بيانات العملاء مثال مناسب: يبدأ الجدول المعالجة، وتنفّذ المهمة العمل، ويُظهر سجل التشغيل ما إذا كان قد اكتمل.

تذكر وثائق المهام المجدولة قيدًا أهم من كلمة «cron»: تُنشأ الجداول الجديدة افتراضيًا بنافذة توزيع مدتها 60 دقيقة. لذا ليس بالضرورة أن تبدأ المهمة اليومية عند توقيت cron المحدد تمامًا. وحيث تسمح الخطة، يعطّل window: "0m" هذا التوزيع.

تخضع الجداول الجديدة المنشأة على Free لقيد يمنع تكرارها أكثر من مرة في الساعة، مع نافذة لا تقل عن 60 دقيقة. وتُستثنى الجداول القديمة التي احتفظت بشروطها السابقة. ولا تعيد الترقية كتابة الجدول المقيّد فورًا؛ بل عليك حفظه مجددًا أو إعادة نشره وأنت على الخطة المدفوعة.

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

عرض التقدّم للمستخدمين والأعطال للمطورين

تساعد Trigger.dev Realtime على تحويل المهمة الخلفية من مؤشر تحميل مبهم إلى سير عمل واضح. في شاشة الاستيراد، اعرض حالة التشغيل والبيانات الوصفية للتقدّم؛ وعند توليد النص، ابثّ المخرجات أثناء عمل المهمة. فهذان مساران مختلفان للبيانات.

تميّز نظرة Realtime العامة بين useRealtimeRun التي تتابع الحالة والبيانات الوصفية، وuseRealtimeStream التي تستهلك البيانات الصادرة عبر تدفقات محددة. وتتطلب جميع خطافات Realtime ودوالها المصادقة. ينبغي أن يرى العميل تقدّم عملية الاستيراد الخاصة به، من دون أن يحصل على وصول إلى عمليات تشغيل بقية العملاء.

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

استخدام MCP مع Trigger.dev

يمنح خادم MCP في Trigger.dev مساعد البرمجة أدوات للبحث في الوثائق، وتهيئة المشاريع، وإطلاق المهام، والنشر، وفحص عمليات التشغيل. وMCP، أي بروتوكول سياق النموذج، هو الواجهة التي يستدعي المساعد هذه الأدوات من خلالها.

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

أسعار Trigger.dev: متى تحتاج إلى خطة للإنتاج؟

تُعد Trigger.dev Hobby نقطة بداية معقولة لتطبيق إنتاج صغير يقع حمل عمله ضمن حدودها: $10 شهريًا مع أرصدة استخدام مشمولة بقيمة $10، و50 عملية تشغيل متزامنة، واحتفاظ بالسجلات لمدة 7 أيام. أما Free فسعرها $0 شهريًا مع أرصدة بقيمة $5، و20 عملية تشغيل متزامنة، وسجلات لمدة 1 يوم؛ وبعد نفاد الأرصدة، يجب الترقية لإبقاء المهام قيد التشغيل. هذه أرقام صفحة الأسعار المتاحة وقت المراجعة، وقد جرى التحقق منها في 11 نوفمبر 2026.

ليست كمية الاستخدام وحدها سبب الانتقال من الخطة الأدنى إلى Hobby. فقد تجعل قيود الجدولة في Free الخطة غير مناسبة قبل أن تصبح الحوسبة مكلفة. واتصالات Realtime حد آخر: تشمل Free عدد 10 اتصالات متزامنة، مقابل 150 في Hobby. أما Pro فسعرها $50 شهريًا مع أرصدة بقيمة $50، و200 عملية تشغيل متزامنة مشمولة، وسجلات لمدة 30 يومًا؛ لذا تصبح مناسبة عندما تتطلب سعة التزامن أو مدة سجل تصحيح الأخطاء الترقية.

لتقدير ملموس، افترض 10,000 مهمة ناجحة شهريًا، يستغرق تنفيذ كل منها 60 ثانية على Small 1x، من دون إعادة محاولات. عند سعر $0.0000338 للثانية مضافًا إليه $0.000025 لكل استدعاء، يكون الاستخدام:

10,000 × ((60 × $0.0000338) + $0.000025) = $20.53.

في Hobby، يشمل الاشتراك البالغ $10 استخدامًا بقيمة $10 من هذا المبلغ، فيتبقى $10.53 إضافية: أي $20.53 إجمالي تكلفة المنصة، أو $0.002053 لكل مهمة مكتملة وفق هذه الافتراضات. هذا حساب انطلاقًا من الأسعار المنشورة، وليس قياسًا لحمل عمل فعلي. وتبقى استدعاءات API للنماذج والتخزين والخدمات الأخرى فواتير منفصلة؛ كما تضيف إعادة المحاولات مزيدًا من التنفيذ.

اختر الخطة بحسب التزامن والجدولة ومدة السجل التي تحتاجها. وقدّر الاستخدام من الزمن المستغرق في التنفيذ، ثم أضف هامشًا للفشل وإعادة المحاولة بدلًا من اعتبار تقدير التشغيل الناجح سقفًا للإنفاق.

قيود قد تغيّر قرارك

تُعفيك Trigger.dev من قدر كبير من البنية التحتية للعمليات العاملة، لكن المسؤوليات المتبقية محددة ومؤثرة.

الاستضافة الذاتية لا تضمن التكافؤ مع Cloud

يحدد مستودع Trigger.dev الترخيص بأنه Apache-2.0، ويربط بأدلة النشر عبر Docker Compose وKubernetes. ويُعد مستودع GitHub المرجع للتحقق من الشيفرة والترخيص.

تدرج مقارنة الاستضافة الذاتية حاليًا بدء التشغيل الدافئ، والتوسّع التلقائي، ونقاط حفظ الحالة، والدعم المخصص ضمن ميزات Cloud فقط. وتضع الاستضافة الذاتية أيضًا تطبيق الويب وRedis وPostgres ومشرفي العمليات العاملة والتحديثات والموثوقية تحت مسؤوليتك.

في مسارات العمل التي تكثر فيها الموافقات، يُعد سلوك نقاط حفظ الحالة سببًا مؤثرًا لتفضيل Cloud. ويشير أحدث إصدار أيضًا إلى تنظيف لقطات microVM في الاستضافة الذاتية، لذلك لا تثبت المقارنة الموثقة وتفاصيل الإصدار تكافؤًا بسيطًا. تحقّق من السلوك المدعوم في الإعداد الذي تنوي استخدامه، وأدرج تشغيل البنية التحتية ضمن القرار.

غياب مهلة قصوى للمنصة لا يغني عن سياسة للفشل

تتيح Trigger.dev استمرار التشغيل من دون سقف ثابت للمدة تفرضه المنصة، لكن إعداداتك قد تفرض maxDuration، وهو حد لزمن الحوسبة. وتدعم وثائق المدة تجاوز الإعدادات واستخدام timeout.None للتنفيذ غير المحدد المدة.

وتقول أيضًا إن cleanup وonSuccess وonFailure لا تُستدعى عند تجاوز المدة القصوى. وهذه نقطة حساسة إذا كان تطبيقك يتوقع من خطاف الفشل تحرير حجز أو وسم عملية استيراد بأنها فاشلة. احتفظ بوسيلة لتسوية سجلات التطبيق غير المكتملة، بدلًا من جعل خطاف واحد آلية التعافي الوحيدة.

إعادة المحاولة لا تقرر سلامة الإجراء التجاري

لا تستطيع Trigger.dev استنتاج ما إذا كان ينبغي تكرار استرداد أموال أو سلسلة رسائل بريد أو استيراد بيانات اكتمل جزئيًا. وحتى عندما ينجح التعافي من تعطل التنفيذ، قد تكون النتيجة التجارية خاطئة إذا أحدث تكرار الإجراء الخارجي أثرًا إضافيًا.

قبل اعتمادها، حدّد عملية الكتابة التي يجب ألا تحدث مرتين، والسجل الذي يثبت حدوثها. وإذا خلا سير عملك من هذا الحد الفاصل، فلن يؤدي تغيير منصة المهام إلى تصحيح سلوكه.

بيانات اعتماد Cloud تتطلب قرار ثقة مدروسًا

أعلنت Trigger.dev عن حادثة أمنية في 1 نوفمبر 2026 تضمنت وصولًا غير مصرّح به إلى متغيرات البيئة عبر مفاتيح API جذرية مخترقة لعملاء في بعض البيئات. ويقول تقرير الحادثة إن العملاء المتأثرين أُبلغوا، وأُلغيت المفاتيح المتضررة؛ ولم تتأثر عمليات النشر المستضافة ذاتيًا.

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

الحكم النهائي: اخترها عندما تريد إدارة العملية العاملة ضمن الخدمة

تُعد Trigger.dev الأنسب بين هذه الخيارات لفريق منتج TypeScript يريد شيفرة المهام الخلفية وبنية التنفيذ ولوحة متابعة التشغيل في حزمة واحدة. ابدأ بحمل عمل واحد يسبب المتاعب، مثل الاستيراد أو توليد التقارير، وحدّد حدود إعادة المحاولة قبل نقل الباقي.

اختر n8n عندما يحتاج مشغّل إلى إدارة تدفق التكامل وتعديله. وأدرج Inngest ضمن خياراتك لنموذج الخطوات الصريح أو حزم SDK الأصلية لسير العمل بلغتي Python وGo. واختر Temporal عندما يريد فريق منصة، عن قصد، تولّي البنية المعمارية لعمليات أعمال قادرة على استكمال التنفيذ عبر خدمات متعددة.

إذا كان احتياجك يتركز في نقل المعلومات بين تطبيقات الأعمال، فإن دليل بدائل Zapier نقطة بداية أنسب من اعتماد بنية تحتية للمهام.

استخدم قائمة تدقيق سير عمل الأعمال بالذكاء الاصطناعي لتحديد حمل العمل، والمسؤول عنه، ومسار الفشل، ونقطة التسليم قبل نقله.

أسئلة شائعة