دردشة سريعة عن الـ Cron Job ⚡️
.
.
تخيل معايا كده…

أنت عندك تطبيق بيبعت Reminder للمستخدمين كل يوم الساعة 9 الصبح.
أو متجر إلكتروني محتاج كل يوم بالليل يعمل تحديث للأسعار أو ينضف الـ expired data.
أو حتى نظام بيطلع تقارير آخر كل شهر بشكل أوتوماتيك...

هل كل شوية هنقف مستنيين الوقت ييجي ونشغل الحاجة بإيدينا؟
أكيد لا..

وهنا يظهر مفهوم مهم جدًا في حتة الـ automation… الـ Cron Job.

---

📌 يعني إيه Cron Job؟

ببساطة جدًا…

الـ Cron Job هو Task أو Process بتتحدد إنها تشتغل بشكل تلقائي في وقت معين أو كل فترة معينة.

يعني بدل ما حد يشغل Script بإيده، الـ System نفسه بيشغلها أوتوماتيك حسب Schedule أنت محدده.

وده بيتم غالبًا عن طريق حاجة اسمها cron أو scheduler

حسب الـ OS أو الـ Framework المستخدم.

---

📌 أشهر استخدامات الـ Cron Jobs

الـ Cron Jobs حرفيًا موجودة في أي System كبير تقريبًا.

ومن أشهر استخداماتها:

1. إرسال الإيميلات

زي:

- Welcome emails
- Daily reminders
- OTP cleanup
- Newsletter

---

2. تنظيف الـ Database

زي:

- حذف الـ expired sessions
- حذف الـ temp files
- عمل archive للـ old data

---

3. تشغيل Background Tasks

زي:

- Generate reports
- Export files
- Sync data between systems

---

4. Monitoring & Health Checks

زي:

- التأكد إن Service شغالة
- إرسال Alert لو حصل Crash
- مراقبة الـ CPU أو Memory usage

---

5. Scheduled Business Logic

ودي مهمة جدًا.

مثلاً:

- خصومات تشتغل الجمعة الساعة 12
- اشتراك ينتهي تلقائي
- تجديد باقات
- قفل حجز بعد وقت معين

---

📌 إزاي الـ Cron Job بتشتغل؟

أنت ببساطة بتقول للـ System:

"شغّل الـ Task دي كل قد إيه؟"

مثلًا:

- كل دقيقة
- كل ساعة
- كل يوم الساعة 12
- كل يوم جمعة
- أول يوم في الشهر

وهكذا.

في Linux مثلًا بيكون عندك Syntax مشهور كده:

* * * * * command

الخمس نجوم دول بيمثلوا:

- minute
- hour
- day of month
- month
- day of week

---

📌 مشاكل ممكن تحصل مع الـ Cron Jobs

1. التاسك تشتغل مرتين

وده بيحصل أحيانًا في الـ distributed systems.

خصوصًا لو عندك أكتر من Server وكلهم شغلوا نفس الـ job.


2. التاسك تاخد وقت أطول من المتوقع

يعني Job لسه شغالة، والـ scheduler يشغل واحدة جديدة...

وده ممكن يعمل:

- duplicate processing
- race conditions
- problems in data


3. Silent Failures

ودي من أخطر الحاجات.

الـ Job ممكن تقع وأنت أصلًا مش عارف إنها وقعت.

عشان كده لازم يكون عندك :

- logging
- monitoring
- alerts

---

الـ Cron Job مش المفروض تعمل Heavy Work

لو عندك Processing ضخم، الأفضل تستخدم:

- Queues
- Workers
- Message Brokers

زي:

- RabbitMQ
- Kafka
- BullMQ
- Sidekiq

والـ Cron Job يبقى مجرد Trigger للحاجة دي.

دردشة سريعة عن الـ OAuth 2.0 💡
.
.
تخيل إنك داخل تسجّل في تطبيق جديد علشان تتابع كورسات، ولما جيت تسجّل، التطبيق قالك:
"تقدر تسجّل بحساب Google أو GitHub بدل ما تعمل أكونت جديد"

ضغطت على زرار "Continue with Google"، وGoogle طلبت منك تختار الإيميل وتوافق على شوية صلاحيات.
بعدها التطبيق فتح واشتغل وكأنك عملت sign up فعلًا...

إيه اللي حصل هنا؟ 🤔
اللي حصل بالضبط هو إن Google استخدمت حاجة اسمها OAuth 2.0.

———

📌 يعني إيه OAuth 2.0؟

ببساطة، الـ OAuth 2.0 هو بروتوكول authorization (مش authentication)، بيخلّي التطبيقات تقدر تاخد إذن من المستخدم عشان تدخل على جزء من معلوماته في service تانية (زي Google, Facebook, GitHub) من غير ما يعرفوا الباسورد بتاعتك.

يعني التطبيق اللي بتستخدمه مش بيشوف الباسورد بتاعتك، بس بياخد توكن مؤقت يقدر يستخدمه يدخل على الـ APIs اللي أنت وافقت عليها.

وده بيخلي العملية آمنة، وبيحافظ على الخصوصية بتاعتك.

———

📌 إزاي الـ OAuth 2.0 بيشتغل؟

تعال نمشي خطوة بخطوة في الـ flow المشهور بتاع Authorization Code Grant Flow، واللي بيستخدم في web apps

1- الـ User Requests Login
التطبيق (Client) يقولك: "سجّل بحساب Google مثلًا"، والمستخدم يضغط على الزرار، ويتم توجيهه على authorization server (زي Google).


2- الـ User Grants Permission
جوجل يطلب منك تسجّل دخول وتوافق على الـ permissions اللي التطبيق طالبها (زي الإيميل، الاسم، إلخ).


3- الـ Authorization Code
لو وافقت، Google هيبعت authorization code للتطبيق (أو تحديدًا للـ redirect URL اللي التطبيق حدده قبل كده).


4- الـ Token Exchange
التطبيق ياخد الـ authorization code ده ويبعت request لـ token endpoint علشان يبدله بـ  access token (وساعات كمان refresh token).


5- الـ Access Protected APIs
بمجرد ما التطبيق ياخد الـ access token، يقدر يستخدمه يطلب بيانات من Google APIs، بس في حدود الـ scope اللي وافقت عليه.

———

إزاي بيأمن الـ APIs؟ 🔐

لو عندك API وعايز تأمنها، ممكن تستخدم OAuth 2.0 بحيث:

- أي Client مش هيقدر يوصل لـ API غير لما يقدّم Access Token صالح.
- الـ Backend بتاعك يقدر يتحقّق من التوكن (مثلًا JWT أو عن طريق introspection endpoint).
- تقدر تتحكّم في الصلاحيات عن طريق الـ scope (يعني مثلًا توكن معين يقدر يقرأ بس، وتوكن تاني يقدر يكتب ويعدّل).
- تقدر تسحب صلاحيات التوكن في أي وقت (Revoke).


بالتالي، OAuth 2.0 بيأمّن الـ APIs عن طريق إنه:

✅ بيقلل الاعتماد على كلمات المرور
✅ بيسمح بالـ delegation (تطبيق ياخد إذن من مستخدم يوصل لحاجة مش بتاعته)
✅ بيخلي الـ tokens مؤقتة، وممكن تتحكم في صلاحياتها ومدّتها

———

📌 أنواع الـGrant Types المشهورة:

- الـ Authorization Code (with PKCE): للموبايل والويب.
- الـ Client Credentials: للـ machine-to-machine apps.
- الـ Password (deprecated): كان بيستخدم لما المستخدم يكتب الـ username والباسورد في نفس التطبيق (غير آمن).
- الـ Implicit (deprecated): زمان كان بيتستخدم للـ SPA apps لكنه غير موصى به.

———

لو كنت بتستخدم OAuth 2.0 في موبايل أو SPA app، لازم تستخدم حاجة اسمها PKCE (Proof Key for Code Exchange) علشان تمنع الـ authorization code من إنه يتسرق.