الفرق بين الـ Monorepo والـ Multirepo 💯
.
.
تخيل أنك شغال على مشروع ضخم، عندك أكتر من فريق، وكل فريق بيشتغل على جزء مختلف. فجأة، تبدأ المشاكل تظهر: كود مكرر، صعوبة في التعديلات، تعارض بين الفرق، وأوقات ضايعة على الـ builds والـ pipelines.

المشكلة هنا ممكن تكون في الطريقة اللي بتنظم بها الكود بتاعك. 💡

هنا تبدأ تسأل نفسك: تختار Monorepo ولا Multirepo؟

كل طريقة لها ميزاتها وعيوبها، واختيارك ممكن يحسن شغلك بنسبة كبيرة أو يعقد حياتك لو اختارت الغلط.

تعال نوضح الفرق بينهم وامتى تختار الطريقة المناسبة...

———

📌 أولًا: يعني إيه Monorepo؟

الـ Monorepo ببساطة هي إنك تحط كل الكود الخاص بالمشروع بتاعك، بكل الـ components أو الـ modules اللي فيه، داخل Repository واحد.

يعني حتى لو عندك أكتر من خدمة (microservices) أو أكتر من مكتبة أو أكتر من تطبيق مرتبطين ببعض، كله بيكون في مكان واحد.

———

📍 مميزات الـ Monorepo:

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

- إعادة استخدام الكود (Code Reusability): لو في مكتبة أو جزء معين من الكود محتاج تستخدمه في أكتر من موديول، تقدر تعمله بسهولة من غير duplication.

- تنسيق أفضل بين الفرق: كل فريق شايف الكود بتاع باقي الفرق، فده بيسهل التعاون بينهم وبيقلل تعارض التعديلات (conflicts).

- تكامل أفضل بين الأدوات: زي الـ CI/CD (Continuous Integration/Continuous Deployment) اللي بيشتغل بسهولة على مشروع واحد بدل ما يتقسم على أكتر من repository.

———

📍 عيوب الـ Monorepo:

- الحجم الكبير للـ repo: مع مرور الوقت وعدد المساهمين الكبير، حجم الـ repo بيكبر وده ممكن يبطّأ العمليات زي cloning أو حتى الـ builds.

- التعقيد في إدارة الصلاحيات: صعب تقول إن فلان يقدر يشتغل على جزء معين بس من غير ما يشوف الباقي.

- مشاكل مع الـ Tools: لو مش عندك أدوات قوية لإدارة الـ monorepo، ممكن تواجه مشاكل في التنظيم وعملية الـ build.

———

📌 ثانيًا: يعني إيه Multirepo؟

على العكس تمامًا، الـ Multirepo معناها إن كل جزء أو موديول من المشروع يكون في Repository خاص به. يعني كل موديول بيبقى مستقل بذاته وكأنه مشروع لوحده.

———

📍 مميزات الـ Multirepo:

- كل موديول ليه حياته الخاصة، وده بيخلي إدارة كل جزء مستقلة وأسهل لبعض الفرق.

- تقدر تحدد مين يشتغل على إيه بناءً على الـ repo اللي عندهم أكسس عليه.

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

- كل جزء بيكون صغير ومستقل، فده بيخلي العمليات زي cloning أسرع وأسهل.

———

📍 عيوب الـ Multirepo:

- تكرار الكود: لو فيه أكتر من موديول بيحتاج نفس الكود، ممكن تضطر تكرره أو تحط مكتبة منفصلة ليه.

- تعقيد في التنسيق بين الفرق: التعاون بين الفرق بيبقى أصعب، وخصوصًا لما يكون فيه dependencies كتير بين الـ modules.

- تكامل معقد للـ CI/CD: عشان كل جزء في Repository مختلف، هتحتاج إعدادات أكتر للـ pipelines عشان كل حاجة تشتغل مع بعض.

- صعوبة في إدارة التغييرات الكبيرة: لو عندك تغيير ضخم بيأثر على أكتر من موديول، هتحتاج تدخل على كذا repo وتعدل في كل واحد لوحده.

———

📌 امتى تختار مين؟

✅ اختر Monorepo لو:

1- مشروعك عبارة عن مجموعة modules مرتبطة ببعضها.
2- عندك فريق صغير أو متوسط.
3- بتحتاج تعمل تغييرات بشكل متكرر على أكتر من موديول في نفس الوقت.
4- الأدوات اللي بتستخدمها بتدعم إدارة monorepos بشكل كويس.


✅ اختر Multirepo لو:

1- مشروعك كبير جدًا ومعقد، وكل جزء فيه مستقل تمامًا.
2- بتحتاج تتحكم في الصلاحيات على مستوى كل موديول.
3- عندك فرق مختلفة كل فريق شغال على موديول خاص به.
4- عايز تتجنب المشاكل اللي بتسببها أحجام الـ repos الكبيرة.

———

القرار في الآخر بيرجع لطبيعة مشروعك واحتياجات فريقك. مفيش طريقة "صح" وطريقة "غلط"، لكن فيه طريقة مناسبة أكتر حسب ظروفك. أهم حاجة إنك تكون فاهم كل طريقة بتقدم إيه وعيوبها إيه. 💡

———

وفقكم الله لكل خير 🌿

إزاي الموقع بيشتغل من غير انترنت؟ 🌐
.
.
عمرك فكرت إزاي ممكن تفتح موقع ويب ويفضل يشتغل حتى لو الإنترنت فصل؟ أو تلاقي الموقع سريع جدًا كأنه مخزن كل حاجة عندك؟ السر هنا في الـ Service Workers.

الـ Service Workers بتلعب دور كبير في تحسين تجربة المستخدم، كمان بتخلي المواقع تشتغل بسرعة وكفاءة حتى في حالة انقطاع الإنترنت.

تعال نفهم الموضوع ببساطة...

———

📌 يعني إيه Service Worker؟

ببساطة، ده كود أو سكربت JavaScript بيشتغل في الخلفية بين المتصفح والسيرفر. ومش زي الكود العادي بتاع الصفحة، ده بيشتغل في الخلفية وبيدي الموقع مميزات كبيرة زي:

- الـ (Caching): يعني يحفظ ملفات الموقع عندك على الجهاز عشان يفتح بسرعة حتى لو الإنترنت ضعيف.
- العمل أوفلاين: الموقع يشتغل حتى لو الإنترنت قاطع.
- الـ (Push Notifications): الرسائل اللي بتجيلك من الموقع حتى لو مش فاتح الصفحة.

———

📌 إزاي الـ Service Workers بتشتغل؟

1- التسجيل (Registration): أول ما المستخدم يفتح الموقع، الـ Service Worker بيتسجل مرة واحدة.
2- التثبيت (Installation): هنا يقدر يبدأ يشتغل ويحفظ الملفات اللي محتاجها.
3- الحدث (Fetch Event): لما المستخدم يطلب أي حاجة (زي صورة أو صفحة)، الـ Service Worker يقرر يجيبها من الكاش ولا من السيرفر.

———

✅ مميزات الـ Service Workers:

- أداء أفضل: لأنه بيقلل الضغط على السيرفر.
- تجربة مستخدم ممتازة: من ناحية السرعة وإمكانية التشغل بدون إنترنت.
- الأمان: لازم الـ Service Workers يشتغلوا على HTTPS عشان يحافظوا على بيانات المستخدم.

———

📌 ملحوظات مهمة

📍 الـ Service Workers محتاجة تخطيط كويس عشان متعملش كاش للملفات زيادة عن اللزوم.
📍 مش كل المميزات بتشتغل في كل المتصفحات، فلازم تعمل حسابك.

———

إزاي ممكن تضيف الـ Service Workers في مشروعك؟ 🤔

الكود الأساسي بسيط جدًا:

// Register Service Worker
if ("serviceWorker" in navigator) {
  navigator.serviceWorker
    .register("/sw.js")
    .then(() => {
      console.log("Service Worker Registered!");
    });
}

———

أما في ملف sw.js:

self.addEventListener("install", (event) => {
  console.log("Service Worker Installed");
});

self.addEventListener("fetch", (event) => {
  event.respondWith(
    caches.match(event.request).then((response) => {
      return response || fetch(event.request);
    })
  );
});

———

لو عاوز تتعمق في الموضوع وتعرف تفاصيل أكتر 👇

Service Worker API
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

Service workers
https://web.dev/learn/pwa/service-workers

———

لو شايف إن البوست ده مفيد، ادعمه بـ Like أو Share عشان الكل يستفيد. 💡

وفقكم الله لكل خير 🌿

ليه الأول بـ true والثاني بـ false؟ 🤔

لو فاهم لغة JavaScript كويس هتجاوب صح 💯

The Hidden Cost of Over-Engineering in Software Development 🤔

Over-engineering in software and systems development occurs when a solution is made more complex than necessary to meet its current requirements.

———

🔗 Full Article:
https://dev.to/alisamir/the-hidden-cost-of-over-engineering-in-software-development-4dnk