Trigger.dev

منصة Trigger.dev هي منصة مفتوحة المصدر لمهام الخلفية ومسارات عمل الذكاء الاصطناعي، طورها Matt Aitken و Eric Allam، وهما فريق مقره دبلن مدعوم من Y Combinator ومستثمري السلسلة أ (Series A) بما في ذلك Standard Capital. تحل المنصة مشكلة محددة ومستمرة: وظائف الخوادم (serverless) مثل AWS Lambda و Vercel لها قيود صارمة على المهلة الزمنية تتراوح بين ثوانٍ أو دقائق، ولكن مسارات الذكاء الاصطناعي، ومهام معالجة المستندات، ومسارات عمل الوكلاء متعددة الخطوات تحتاج عادةً إلى التشغيل لدقائق أو ساعات. تتيح Trigger.dev للمطورين تحديد المهام كوظائف TypeScript غير متزامنة (async) عادية وتشغيلها دون هذا القيد، سواء على البنية التحتية السحابية المدارة أو على خوادمهم الخاصة عبر Docker أو Kubernetes.

تُقدم المنصة كحزمة تطوير برمجيات (SDK) لـ TypeScript تتكامل مع Node.js و Bun و Next.js و NestJS ومعظم بيئات خوادم TypeScript الأخرى. تشمل القدرات الأساسية التنفيذ المستدام مع ميزة نقطة الحفظ والاستئناف (تتوقف المهام مؤقتًا عند نقاط await وتُستأنف دون فقدان الحالة)، وإعادة المحاولة التلقائية مع تأخير زمني قابل للتكوين، وقوائم الانتظار المتزامنة مع عناصر تحكم في الأولوية، وجدولة cron، وواجهة برمجة تطبيقات في الوقت الفعلي (Realtime API) تبث تقدم المهمة المباشر إلى تطبيقات React في الواجهة الأمامية. تتكامل المنصة مع Vercel AI SDK و OpenAI Agents SDK و LangChain و LangGraph و LlamaIndex، وواجهات برمجة تطبيقات النماذج المباشرة من Anthropic و OpenAI و Google و Cohere و Mistral. بالنسبة لحالات الاستخدام الخاصة بالذكاء الاصطناعي، تدعم Trigger.dev أيضًا نقاط الانتظار التي تتطلب تدخلًا بشريًا (human-in-the-loop)، حيث تتوقف المهام مؤقتًا للحصول على موافقة أو إدخال بشري وتُستأنف تمامًا من حيث توقفت دون استهلاك وقت الحوسبة الخامل. الإصدار المستقر الحالي هو v4، مع أكثر من 14,800 نجمة على GitHub وترخيص Apache 2.0.

ما الذي تفعله Trigger.dev فعليًا في مايو 2026

الآلية الأساسية لـ Trigger.dev هي تنفيذ الحفظ والاستئناف (checkpoint-restore). عندما تصل مهمة إلى نقطة await (في انتظار مهمة أخرى، أو حدث خارجي، أو مؤقت، أو تدخل بشري)، تقوم المنصة بتسلسل حالة المهمة باستخدام CRIU (الحفظ/الاستئناف في مساحة المستخدم) وتعلق الحاوية. لا يتم احتساب تكلفة المهمة أثناء هذا التوقف المؤقت. عندما يتحقق الشرط المنتظر، تُستأنف المهمة تمامًا من الحالة المتسلسلة. يختلف هذا جوهريًا عن البنية التقليدية بدون خادم (serverless)، حيث إما أن تنتهي الوظيفة ضمن مهلتها الزمنية أو تفشل.

تعمل المهام في عمال (workers) مبنيين على Bun (حاويات طويلة الأمد، وليست استدعاءات مؤقتة بأسلوب Lambda). يمكن لكل مهمة تحديد تكوين الجهاز الخاص بها: عدد وحدات المعالجة المركزية (CPU)، وذاكرة الوصول العشوائي (RAM)، وحزم اختيارية على مستوى النظام مثل FFmpeg أو Puppeteer أو بيئات Python مخصصة عبر امتدادات البناء. هذا يعني أن مهمة تحويل ترميز الفيديو ومهمة بريد إلكتروني خفيفة يمكن أن تتشاركا نفس المشروع أثناء التشغيل على أجهزة ذات أحجام مناسبة.

تتيح واجهة برمجة التطبيقات في الوقت الفعلي (Realtime API)، التي تم إصدارها كإصدار عام (GA) في ديسمبر 2024 والمبنية على Electric SQL (محرك مزامنة PostgreSQL مفتوح المصدر)، استخدام خطافات React (React hooks) مثل useRealtimeRun و useRealtimeBatch لبث حالة المهمة المباشرة إلى واجهات مستخدم المتصفح. يمكن لمسار معالجة المستندات أن يُظهر للمستخدمين تقدمًا في الوقت الفعلي: "استخراج النص.. تلخيص الفصل 3 من 8.." دون الحاجة إلى الاستعلام المستمر (polling). اعتمدت أكثر من ستين مؤسسة واجهة Realtime API في غضون أيام من الإصدار العام، بما في ذلك Midday.ai و Papermark.io.

تتم معالجة الجدولة بشكل أصلي عبر تعبيرات cron أو المشغلات القائمة على الفترات الزمنية، وتدعم المهام أنماط التوزيع (fan-out): يمكن لمهمة أصلية أن تولد مئات المهام الفرعية بشكل متزامن، يتم تتبعها جميعًا في شجرة تشغيل واحدة مع إمكانية مراقبة موحدة. تُظهر لوحة المعلومات المدعومة بـ OpenTelemetry أشجار التتبع الكاملة، والسجلات، وسجل إعادة المحاولة، ومقاييس الأداء لكل عملية تشغيل.

"قررنا استخدام Trigger.dev بدلاً من Inngest أو إعداد حل مخصص خاص بنا.. [من أجل] أتمتة مسارات العمل، وقابلية التوسع، وسرعة المطورين، وكفاءة التكلفة، والجاهزية للمستقبل." - Sohrab Fadai، Product Hunt، 2024

موقع Trigger.dev مقارنة بـ Inngest و Temporal

الأدوات الثلاث الأكثر مقارنة في مجال التنفيذ المستدام الموجه للمطورين هي Trigger.dev و Inngest و Temporal. تتخذ كل منها نهجًا معماريًا مختلفًا تمامًا.

تُعد Inngest الأقرب من حيث التداخل الوظيفي مع Trigger.dev، لكن البنية تختلف في نقطة حاسمة واحدة: Inngest لا تقوم بتشغيل الحوسبة الخاصة بك. إنها طبقة تنسيق تعتمد على واجهة برمجة التطبيقات (API) فقط، تستدعي نقاط النهاية (endpoints) الخاصة بك بدون خادم عبر HTTP وتسلم الأحداث. يجب على المطورين تقسيم العمل إلى وظائف step.run() منفصلة، يتم إعادة محاولة كل منها بشكل مستقل وحفظها عند حدود الخطوة. هذا يعني أن مهام Inngest لا تزال مقيدة بحدود التنفيذ بدون خادم لكل خطوة (حوالي 15 دقيقة لكل استدعاء وظيفة خطوة). تقوم Trigger.dev بتشغيل الكود الخاص بك مباشرة على بنيتها التحتية المدارة (أو العمال المستضافين ذاتيًا) في حاويات طويلة الأمد، دون الحاجة إلى تقسيم الخطوات. يمكن لوظيفة غير متزامنة (async) واحدة مستمرة أن تعمل لساعات. تبدأ الفئة المدفوعة Hobby في Trigger.dev من $10/شهريًا؛ بينما تبدأ الفئة المدفوعة في Inngest من $75/شهريًا. Trigger.dev مرخصة بموجب Apache 2.0 ويمكن استضافتها ذاتيًا بالكامل دون قيود على الميزات. شروط الاستضافة الذاتية لـ Inngest أكثر تقييدًا. من حيث حجم التنزيلات الأسبوعية على npm، تجذب Inngest حوالي 85,000 تنزيل أسبوعيًا مقابل 45,000 لـ Trigger.dev، مما يعكس التواجد الأطول لـ Inngest في السوق، على الرغم من أن Trigger تنمو بشكل أسرع وفقًا لمسار نجوم GitHub.

تقع Temporal في فئة مختلفة تمامًا: تنفيذ مستدام على مستوى المؤسسات لمسارات عمل معقدة للغاية وطويلة الأمد ومتعددة اللغات. تستخدم Temporal إعادة التشغيل الحتمية المستندة إلى الأحداث. يتم تسجيل كل إجراء في مسار العمل في سجل تاريخي للإلحاق فقط؛ عند الاسترداد، يعيد مسار العمل التشغيل من البداية، ويعيد تنفيذ جميع الأنشطة حتى النقطة الحالية. يتطلب هذا كود مسار عمل حتمي: لا يوجد Date.now()، ولا أرقام عشوائية، ولا إدخال/إخراج مباشر داخل وظائف مسار العمل. منحنى التعلم أكثر حدة بشكل كبير، حيث يتطلب من المطورين فهم مسارات العمل (Workflows)، والأنشطة (Activities)، والعمال (Workers)، وقوائم انتظار المهام (Task Queues)، ومساحات الأسماء (Namespaces)، والإشارات (Signals) قبل إطلاق مهمتهم الأولى. Temporal متعددة اللغات (Go و Java و Python و TypeScript و PHP و .NET)؛ بينما Trigger.dev تعتمد على TypeScript أولاً، مع دعم Python فقط كحل بديل عبر الامتدادات. بالنسبة للمؤسسات التي تحتاج إلى سجلات مسارات عمل تمتد لسنوات، أو مسارات تدقيق كاملة، أو أساطيل عمال Java/Go، فإن Temporal هي الخيار الصحيح. أما بالنسبة لفريق تطبيق ذكاء اصطناعي يعتمد على TypeScript ويحتاج إلى مهام خلفية موثوقة مع الحد الأدنى من أعباء البنية التحتية، فإن Trigger.dev أسرع وأرخص في التشغيل. كما لخص أحد المطورين في صفحة المقارنة بين Trigger.dev و Temporal: "كان الانتقال إلى Trigger لمهام الخلفية أكثر موثوقية وأرخص وأسهل."

يجب على المطورين الذين يبنون مسارات تعلم آلي (ML) تعتمد على Python أولاً تقييم Modal أيضًا، والتي توفر حوسبة بدون خادم مسرعة بواسطة وحدة معالجة الرسومات (GPU) وأدوات Python ممتازة. بالنسبة للفرق التي تستخدم بالفعل n8n أو Activepieces لأتمتة مسارات العمل المرئية، فإن Trigger.dev ليست بديلاً للأدوات المرئية ولكنها مكمل على مستوى الكود للمهام التي تحتاج إلى الاستدامة والتنفيذ طويل الأمد.

كيف يبدو واقع حلقة الوكيل في الاستخدام اليومي

تبدأ تجربة التطوير بتثبيت حزمة @trigger.dev/sdk وإضافة ملف trigger.config.ts لتحديد إعدادات المشروع. المهام هي وظائف مُصدَّرة (exported) مزينة بـ task(). تقوم واجهة سطر الأوامر (CLI) الخاصة بـ Trigger.dev بتشغيل خادم تطوير محلي يتصل بلوحة معلومات Trigger.dev Cloud (أو المستضافة ذاتيًا)، حيث تظهر عمليات التشغيل في الوقت الفعلي أثناء التطوير. لا توجد بنية تحتية منفصلة لقوائم الانتظار يجب تكوينها أو إدارتها محليًا.

بالنسبة لمسارات عمل وكلاء الذكاء الاصطناعي، يتمثل النمط في تحديد مهمة جذرية تنسق المهام الفرعية. يمكن لكل مهمة فرعية استدعاء واجهات برمجة تطبيقات النماذج اللغوية الكبيرة (LLM)، والكتابة في قواعد البيانات، وإرسال طلبات HTTP، واستدعاء wait.forEvent() للتوقف مؤقتًا حتى تصل إشارة خارجية. تضيف مسارات العمل التي تتطلب تدخلًا بشريًا استدعاء waitpoint الذي يقوم بتسلسل حالة الوكيل ويرسل إشعارًا، ثم يُستأنف عندما يقدم إنسان الموافقة عبر لوحة معلومات Trigger.dev أو استدعاء واجهة برمجة تطبيقات مخصص.

النشر في بيئة الإنتاج يتم بأمر CLI واحد: npx trigger deploy. تقوم واجهة سطر الأوامر ببناء صورة Docker، ودفعها إلى Trigger.dev Cloud (أو سجل مستضاف ذاتيًا)، وإنشاء نشر غير قابل للتغيير بإصدار محدد. تستمر المهام قيد التشغيل بالفعل على إصدارها المنشور؛ بينما تلتقط المهام الجديدة أحدث إصدار. يمنع هذا الإصدار الذري (atomic versioning) تعطل عمليات التشغيل الجارية بسبب عمليات نشر الكود الجديدة، وهو نمط فشل شائع في الأنظمة القائمة على قوائم الانتظار.

"القدرة على استخدام TypeScript لتحديد مسارات العمل رائعة." - Charlie، Product Hunt، 2024

إمكانية المراقبة مدمجة عبر OpenTelemetry. تنتج كل عملية تشغيل شجرة تتبع مرئية في لوحة المعلومات: كل خطوة، ومدتها، ومدخلاتها ومخرجاتها، وأي استدعاءات مهام فرعية متداخلة. يمكن توجيه تنبيهات الأخطاء القابلة للتكوين إلى Slack أو PagerDuty. تتراوح فترة الاحتفاظ بالسجلات من يوم واحد في الفئة المجانية (Free) إلى 30 يومًا في فئة Pro، مع احتفاظ مخصص في فئة Enterprise.

لمن تم بناء Trigger.dev

تم بناء Trigger.dev خصيصًا لمطوري TypeScript الذين يبنون تطبيقات مدعومة بالذكاء الاصطناعي: تطبيقات Next.js ذات ميزات الذكاء الاصطناعي، وخلفيات NestJS التي تعالج المستندات، وأي كود من جانب الخادم يستدعي واجهات برمجة تطبيقات LLM ويحتاج إلى منطق إعادة المحاولة وإمكانية المراقبة. تُعد الأداة ذات قيمة خاصة عندما تصطدم مسارات الذكاء الاصطناعي باستمرار بقيود مهلة الخوادم (serverless) أو عندما يجد المطورون أنفسهم يكتبون منطق إعادة محاولة هش يدويًا.

ستجد الشركات الناشئة في مراحلها المبكرة أن خطة Hobby البالغة $10/شهريًا كافية لمعظم أعباء عمل الإنتاج، مع فوترة الحوسبة بشكل منفصل بناءً على الاستخدام الفعلي. ستجد الفرق التي تعالج كميات كبيرة من مهام استدلال الذكاء الاصطناعي أن فئة Pro التي توفر أكثر من 200 عملية تشغيل متزامنة ودعم Slack مخصص تستحق $50/شهريًا. عمليات النشر المستضافة ذاتيًا على Docker موثقة وناضجة اعتبارًا من الإصدار v4؛ الاستضافة الذاتية على Kubernetes متاحة وموصوفة في سلسلة من منشورات المدونة الرسمية.

تتكامل Trigger.dev بشكل طبيعي في حزم التكنولوجيا التي تستخدم بالفعل Zapier أو Make للأتمتة بدون كود، حيث تخدم طبقة مختلفة. في حين تتعامل تلك المنصات مع توجيه الأحداث عبر التطبيقات دون كتابة كود، تتعامل Trigger.dev مع ما يحدث داخل طبقة الكود عندما تحتاج المهام إلى التشغيل لفترة أطول مما تسمح به وظيفة Lambda.

تقدر الفرق التي لديها التزامات كبيرة تجاه المصادر المفتوحة ترخيص Apache 2.0. يمكن استضافة المنصة بأكملها ذاتيًا دون قيود على الميزات، ولا حدود لعمليات التشغيل، ولا تقييد بالمورد (vendor lock-in) بخلاف حزمة TypeScript SDK نفسها. تحتوي قاعدة الكود على أكثر من 14,800 نجمة على GitHub، ومشرفين نشطين، وأكثر من 617 إصدارًا اعتبارًا من مايو 2026، مما يشير إلى قوة بقاء حقيقية.

ما لا تمثله Trigger.dev

إنها ليست أداة Python. حزمة SDK مخصصة لـ TypeScript فقط. يمكن استدعاء نصوص Python كعمليات فرعية داخل المهام عبر امتدادات البناء، ولكن لا توجد حزمة SDK أصلية لـ Python، ولا تعريف لمهام Python، ولا دعم من الدرجة الأولى لإدارة حزم Python داخل المهام. يجب على فرق التعلم الآلي التي تعتمد على Python أولاً وتدير مسارات الاستدلال استخدام Modal أو Prefect أو Temporal مع عمال Python بدلاً من ذلك.

إنها ليست منصة بدون كود (no-code) أو منخفضة الكود (low-code). لا يوجد منشئ مسارات عمل مرئي، أو عقد سحب وإفلات، أو واجهة مستخدم رسومية (GUI) لتحديد المهام. كل شيء عبارة عن كود. لا يمكن لمستخدمي الأعمال أو الفرق غير الهندسية استخدام Trigger.dev دون تدخل المطورين. لأتمتة مسارات العمل المرئية، راجع n8n أو Activepieces.

إنها ليست حزمة مراقبة كاملة. في حين أن تتبع OpenTelemetry المدمج مفيد، ستحتاج الفرق التي لديها بنية تحتية حالية للمراقبة (Datadog أو Grafana أو Honeycomb) إلى دمج تتبعات Trigger.dev في أدواتها الحالية. لوحة المعلومات المدمجة وظيفية ولكنها ليست بديلاً لمنصات المراقبة المصممة خصيصًا لهذا الغرض.

لم يتم تحصينها بعد على مستوى المؤسسات بحجم Temporal. كشف حادث الإنتاج في سبتمبر 2025، والذي أدت فيه رسائل الخطأ الضخمة لعميل واحد إلى ثلاثة إخفاقات سحابية متزامنة، أن البنية التحتية لا تزال قيد الاستقرار في ظل النمو السريع. نشر الفريق تقريرًا عامًا شاملاً عن الحادث وأصدر إصلاحات في غضون 48 ساعة، وهي إشارة إيجابية. لكن الفرق التي تعتبر إخفاقات مسارات العمل بالنسبة لها حرجة للأعمال قد ترغب في انتظار الترحيل إلى MicroVM (المخطط له لتقليل الاعتماد على Kubernetes) قبل الالتزام على مستوى المؤسسة.

تجاوز Trigger.dev إذا كان فريقك يستخدم Inngest بالفعل بشكل جيد مع مسارات عمل قائمة على الخطوات ولا توجد مشكلات في المهلة الزمنية. تكلفة الترحيل حقيقية وقد لا يبررها الفارق في الميزات. تجاوزها إذا كنت بحاجة إلى مسارات تدقيق لمسارات العمل تمتد لسنوات ومختبرة في بيئات العمل: هذا هو مجال Temporal، وليس Trigger.