Vercel Schedules تطلق مهام لمرة واحدة ومتكررة دون إعادة نشر

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

تخيّل طلبًا بسيطًا إلى وكيل: «صباح الغد اجمع أهم خمسة أخبار من Hacker News وأعدّ ملخصًا موجزًا». في المخطط التقليدي يحفظ التطبيق الطلب ووقت التشغيل في قاعدة البيانات، بينما يتحقق cron منفصل بانتظام من المهام التي حان وقت تنفيذها. هذا حل عملي، لكنه يجلب معه بنية تحتية مساعدة: جدول للمهام، وآلية استعلام دوري، وأقفال، ومعالجة للتكرار، ومنطق للإلغاء.

قدّمت Vercel خدمة Schedules، التي تتيح للتطبيق إنشاء مهام لمرة واحدة ومتكررة وتعديلها وإلغاءها أثناء العمل. ولا حاجة لتغيير إعدادات المشروع أو إعادة نشر التطبيق. وقد دخلت الخدمة مرحلة البيتا العامة.

كيف يعمل

يمرّر التطبيق إلى Vercel الوقت والمنطقة الزمنية وهدف التشغيل والحمولة (payload). ويمكن إنشاء هذا الجدول عبر JavaScript SDK أو API أو CLI. وعندما يحين الموعد، تسلّم Vercel البيانات المحفوظة إلى موضوع Vercel Queues المحدد، فيستقبل كود التطبيق الرسالة وينفّذ العمل.

في مثال Vercel يحصل الوكيل على أداة scheduleTask. يصوغ المستخدم مهمته، ويستدعي النموذج الأداة، فتنشئ جدولًا لمرة واحدة مع معرّفي المستخدم والمستأجر (tenant). وفي اليوم التالي يقرأ المعالج الرسالة من الطابور، ويتحقق من صلاحيات المستخدم الحالية، ويشغّل الوكيل ويحفظ النتيجة.

هذه نقطة مهمة: الجدول يجيب فقط عن سؤال «متى يُسلَّم العمل». أما العمل نفسه، والتحقق من الوصول، وحفظ النتيجة، ومعالجة الأخطاء، فيظل على عاتق التطبيق.

وللمهام المعروفة مسبقًا تبقى الإعدادات الثابتة في vercel.json أو Build Output API. فمثلًا يمكن ربط التنظيف اليومي لقاعدة البيانات بدالة خاصة ومنطقة زمنية محددة. تستدعي Vercel هذه الدالة مباشرة دون عنوان HTTP عام، وتؤكد بنفسها أن التشغيل جاء من خدمة الجدولة.

ما الذي يتغير بالنسبة للمطوّر

أهم فائدة هي اختفاء طبقة الاستعلام الدوري عن قاعدة البيانات التي كان المطوّرون يبنونها بأنفسهم لمؤقتات المستخدمين. يصبح الجدول كائنًا مُدارًا مستقلًا: يمكن إنشاؤه أو نقله أو إلغاؤه من التطبيق العامل. ويظهر سجل عمليات التشغيل في لوحة Vercel، ويمكن تشغيل المهمة يدويًا للاختبار.

تدعم Schedules عمليات النشر في وضع Preview والبيئات المخصصة. وهذا يعني إمكانية اختبار المعالج قبل الإنتاج دون انتظار وقت التنفيذ الفعلي. أما التطوير المحلي فمتاح عبر vercel dev.

لكن لا ينبغي اعتبار الخدمة بديلًا كاملًا عن الطوابير أو محرك العمليات الخلفية. فالمهام الديناميكية تُسلَّم تحديدًا عبر Vercel Queues، لذا يجب التفكير في إعادة التسليم وتحقيق خاصية idempotence في المعالج وقابلية المراقبة. فإذا كانت العملية تخصم أموالًا أو ترسل بريدًا إلكترونيًا، فيجب ألا يؤدي التشغيل المتكرر إلى تنفيذ الإجراء مرتين.

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

الخلاصة العملية

إذا كان تطبيقك يعمل بالفعل على Vercel ويحتاج إلى تذكيرات أو إجراءات مؤجلة للوكيل أو مهام خدمية دورية، فمن المفيد اختبار Schedules في بيئة Preview. ومن المعقول البدء بمهمة غير حرجة، وإضافة خاصية idempotence والتسجيل (logging)، ثم اختبار الإلغاء وتغيير المنطقة الزمنية وإعادة التسليم.

أما الفريق الذي يملك مجدوِلًا وطابورًا موثوقين، فلا يوجد سبب عاجل للانتقال. لكن بالنسبة لمنتج جديد، تقلّل Vercel Schedules حجم البنية التحتية التي عليك بناؤها، وتحوّل عبارة المستخدم «افعلها صباح الغد» إلى استدعاء API عادي بدل نظام فرعي مستقل.