DevGuide

🔰 Awesome Free APIs for Developers that you should know about

🔰 All CSS Functions

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

ليه الأول بـ true والثاني بـ false؟ 🤔 لو فاهم لغة JavaScript كويس هتجاوب صح 💯

إزاي الموقع بيشتغل من غير انترنت؟ 🌐 . . عمرك فكرت إزاي ممكن تفتح موقع ويب ويفضل يشتغل حتى لو الإنترنت فصل؟ أو تلاقي الموقع سريع جدًا كأنه مخزن كل حاجة عندك؟ السر هنا في الـ 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 عشان الكل يستفيد. 💡 وفقكم الله لكل خير 🌿

الفرق بين الـ 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 الكبيرة. ——— القرار في الآخر بيرجع لطبيعة مشروعك واحتياجات فريقك. مفيش طريقة "صح" وطريقة "غلط"، لكن فيه طريقة مناسبة أكتر حسب ظروفك. أهم حاجة إنك تكون فاهم كل طريقة بتقدم إيه وعيوبها إيه. 💡 ——— وفقكم الله لكل خير 🌿

سمعت قبل كده عن الـ Microservices بس مش فاهمها كويس؟ أو حاسس إنها موضوع معقد ومحتاج خبرة كبيرة؟ 🤯 الموضوع ببساطة إن بدل ما يكون عندك تطبيق ضخم (Monolith) كله متشابك مع بعضه، تقدر تقسّمه لعدة خدمات صغيرة (Microservices)، وكل خدمة بتشتغل لوحدها وتقدر تتحدث مع باقي الخدمات بطريقة منظمة. الفكرة دي بتساعد الشركات الكبيرة زي Netflix و Amazon إنها تقدر تطوّر وتحدّث الأنظمة بتاعتها بسهولة وسرعة. ——— 🎯 تخيل إن عندك تطبيق لمطعم أونلاين: - خدمة مسؤولة عن الطلبات 🛒 - خدمة مسؤولة عن الدفع 💳 - خدمة مسؤولة عن إدارة العملاء 👥 كل خدمة تشتغل لوحدها، ولو حصل مشكلة في الدفع، الطلبات تفضل شغالة عادي بدون ما تتأثر. ——— في المقال ده، هتفهم الفكرة بأسلوب بسيط، مع مثال عملي يوضح لك كل حاجة خطوة بخطوة ✅👇

Microservices Made Simple: A Beginner’s Guide with a Real Example 💯

Imagine you’re building a house. You could construct it as one giant, unchangeable block with everything fused or use a modular approach, with separate rooms you can tweak, replace, or upgrade without tearing the whole thing down. https://differ.blog/p/microservices-made-simple-a-beginner-s-guide-with-a-real-example-47c171

Writing tests that actually last?

Let’s go beyond “it renders” and explore how to write robust, maintainable tests with React Testing Library

كيف تعمل الـ JavaScript خلف الكواليس؟ JS Event Loop https://youtu.be/5PbmjScmt4Y ——— 💡 سؤال مهم جدًا وهتقابله تقريبًا في أي انترفيو له علاقة بالـ JS

مفهوم الـ Webhooks 💡 . . تخيل معايا إنك مستني صاحبك يجيلك. بدل ما كل شوية تقوم تبص من الشباك تشوف وصل ولا لا، هو أول ما يوصل يبعتلك رسالة يقولك "أنا وصلت". السيناريو ده بالضبط شبه اللي بيعمله الـ Webhook. بدل ما الـ Application بتاعك يفضل كل شوية يسأل "فيه حاجة جديدة حصلت؟" (وده اسمه Polling)، الـ Webhook بيخلي الـ System التاني هو اللي يبعتلك أول ما يحصل التغيير. ——— 🔗 LinkedIn: https://www.linkedin.com/posts/mentoor-io_sofwaredevelopment-softwareengineering-softwaredeveloper-activity-7360720810849763329-4CYv 🔗 Facebook: https://www.facebook.com/share/p/1Bv7LHEAcf 🔗 Qabilah: https://qabilah.com/posts/5Tod1qKZvxU

مفهوم الـ API Rate Limiting 💡 . . تخيل إن عندك Event ضخم وكل الناس هتدخل من باب واحد بس. لو كل الناس حاولت تدخل في نفس اللحظة، إيه اللي هيحصل؟ زحمة، فوضى، وممكن الـ Event يتلغي. نفس الفكرة بتحصل مع أي API… لما عدد كبير جدًا من الـ Requests يوصل للسيرفر في نفس الوقت، الأداء بينهار، والـ Users بيبدأوا يحسوا إن الخدمة بطيئة أو مش شغالة. هنا بيجي دور الـ API Rate Limiting، اللي هو ببساطة نظام بيحط حدود واضحة لعدد الـ Requests اللي أي مستخدم أو تطبيق يقدر يبعته في فترة زمنية محددة، عشان يضمن إن الخدمة تفضل مستقرة وسريعة لكل الناس. ——— 🤔 ليه نعمل Rate Limiting؟ 1- حماية الـ Server لو الـ API استقبل عدد Requests أكتر من طاقته، ممكن يقع أو يشتغل ببطء شديد. الـ Rate Limiting بيحافظ على أداء السيرفر. 2- منع الـ Abuse فيه ناس بتحب تجرب تبعت ملايين Requests بسرعة عشان تهاك أو تعمل Spam. الحدود دي بتوقفهم. 3- توزيع الـ Resources بطريقة مناسبة لو فيه أكتر من عميل بيستخدم الـ API، مش معقول واحد منهم ياخد 90% من الـ Resources والباقي يتخانقوا مع بعض. ——— ⚙️ إزاي نطبق الـ Rate Limiting؟ - الـ Fixed Window بتحدد مثلًا 100 طلب في كل دقيقة. لو عديت العدد، هتاخد Error (غالبًا 429 Too Many Requests) لحد ما الدقيقة تخلص. - الـ Sliding Window نفس فكرة الـ Fixed Window بس أذكى شوية. بيحسب requests خلال آخر فترة زمنية متحركة بدل ما يقسم الوقت لمربعات ثابتة. - الـ Token Bucket عندك "جيب" فيه Tokens، كل Request بياخد Token. الـ Tokens بتتجدد بمعدل ثابت. لو الجيب فاضي، استنى لحد ما يتجدد. - الـ Leaky Bucket زي الصفيحة اللي فيها ثقب صغير بينقط Requests بمعدل ثابت، حتى لو جالك دفعة كبيرة فجأة. ——— 💡 نصائح لو أنت بتبني API - حدد معدل Requests معقول بناءً على قدرات السيرفر وعدد العملاء. - استخدم Caching في الحاجات اللي مش محتاجة تتطلب من السيرفر كل مرة. - خلي عندك خطة لتعامل خاص مع العملاء المهمين (Premium Users). ——— وفقكم الله لكل خير 🌿

React Context vs Redux 💯

Let’s break it down, what they do, when to use them, and how to choose the right one for your app.

يعني إيه Dead Code؟ 💀 . . تخيل معايا إنك في مشروع كبير، وكل يوم بتكتب فيه Features جديدة، وتعدّل على الكود القديم. مع الوقت، طبيعي جدًا يحصل تراكم أكواد غير مستخدمة…حاجات كانت مهمة زمان، بس دلوقتي مبقاش لها أي لازمة. الحاجات دي اسمها Dead Code. الـ Dead Code هو أي كود موجود داخل المشروع، لكن لا يتم تنفيذه أو استخدامه في الـ Runtime. يعني الكود موجود في الـ Files، بس فعليًا ملوش أي تأثير على البرنامج أو الـ Output. ——— 🔍 أمثلة على الـ Dead Code: - أي Function مكتوبة ومحدش بينادي عليها في أي مكان في المشروع. - أي Variables أو Constants متعرفة لكنها غير مستخدمة. - أي Conditions مش ممكن تتحقق أبدًا (Unreachable Code). - أي كود قديم استبدلناه بكود أحدث، بس نسينا نمسحه. ——— 💡 طيب إيه المشكلة؟ يمكن تحس إن مفيش ضرر، لكن الحقيقة فيه مشاكل كتير: 1- زيادة حجم الكود: بيخلي المشروع تقيل ومليان حاجات ملهاش لازمة. 2- صعوبة الصيانة: لما تيجي تصلّح Bug أو تعدّل Feature، هتلف وتدور. 3- ممكن حد يشوف Function موجودة ويظن إنها بتستخدم، فيبدأ يشتغل عليها وهو مش واخد باله إنها Dead. 4- أداء أبطأ في بعض الحالات: حتى لو مش بتتنفذ، وجودها ممكن يأثر على وقت الـ Build أو حجم الـ Bundle في الـ Frontend. 5- الـ Code Smell: علامة على إن المشروع مش Managed كويس، وده بيأثر على الـ Code Quality. ——— 🛠 إزاي نكتشف الـ Dead Code؟ ✅ في JavaScript/TypeScript: - استخدم Tools زي ESLint مع Rule زي no-unused-vars أو no-unreachable. - الـ ts-prune: أداة قوية بتحددلك الـ Exports اللي مش مستخدمة. - الـ webpack-bundle-analyzer: يعرفك إيه اللي داخل في الـ Bundle ومش محتاجه. ✅ في لغات تانية زي Java أو #C: - الـ IDE نفسه زي IntelliJ أو Visual Studio غالبًا بيحددلك الـ Unused Code بعلامة أو لون باهت. ——— وفقكم الله لكل خير 🌿

🔵🟢 يعني إيه Blue-Green Deployment؟ . . تعال أقولك على موقف حصل تقريبًا مع كل الناس اللي اشتغلت على مشاريع شغالة في الـ (Production)... أنت خلصت ميزة جديدة (Feature) أو صلحت مشكلة (Bug Fix)، ومبسوط أوي بالشغل اللي عملته، وداخل تعمل deploy للكود. أول ما تعمل Deploy، تكتشف إن حصلت مشكلة مش متوقعة، والموقع وقع أو المستخدمين اشتكوا من حاجة مخدتش بالك منها. ساعتها بتكون في لحظة توتر مش طبيعية، وتحاول ترجع الكود القديم بسرعة بأي طريقة. هنا بقى بييجي دور الـ Blue-Green Deployment علشان يمنع كل الكوارث دي... ——— 💡 يعني إيه Blue-Green Deployment؟ الـ Blue-Green Deployment هو أسلوب في نشر التحديثات (Deployment Strategy) بيخليك تنشر التغييرات بتاعتك بشكل آمن وسلس ومن غير downtime. ببساطة، بدل ما عندك نسخة واحدة شغالة من التطبيق، بتبقى مشغّل نسختين: - 🟢 النسخة الحالية اللي الناس كلها بتستخدمها دلوقتي اسمها Green - 🔵 النسخة الجديدة اللي فيها التعديلات والتحديثات اسمها Blue أنت بتجهّز نسخة الـ Blue، وتعمل عليها كل الاختبارات المطلوبة. ولما تتأكد إن كل حاجة شغالة تمام، بتبدّل الـ Traffic من Green لـ Blue. يعني المستخدمين بدل ما بيتعاملوا مع النسخة القديمة، بيتحولوا فجأة للنسخة الجديدة من غير ما يحسوا بأي downtime. ——— 🤔 ليه الأسلوب ده ممتاز جدًا؟ 1- الـ Zero Downtime مفيش وقت توقف. التحديث بيحصل في الخلفية، وأول ما يكون جاهز، بيتحوّل الـ Traffic بس. 2- الـ Rollback سهل جدًا لو حصلت مشكلة في النسخة الجديدة، تقدر ترجع المستخدمين تاني للنسخة القديمة بكل سهولة. 3- الاختبار على أرض الواقع تقدر تجرب النسخة الجديدة على عدد محدود من المستخدمين الأول (canary testing) قبل ما تعمل الـ switch الكامل. 4- مش هتبقى خايف تعمل Deploy. حتى لو فيه خطأ، فيه دايمًا نسخة سليمة تقدر ترجع لها. ——— فيه أكتر من طريقة تطبّق بيها Blue-Green Deployment، على حسب البنية التحتية اللي بتشتغل عليها: 1- لو شغال على Kubernetes، ممكن تستخدم مثلًا: - الـ Services + Deployments علشان تتحكم في الـ Traffic. - أدوات زي Argo Rollouts أو Spinnaker 2- لو بتستخدم Cloud Platforms زي AWS أو GCP، فيه أدوات built-in بتساعدك تعمل التبديل ما بين النسخ. 3- ولو شغال بشكل يدوي، ممكن تستخدم load balancer (زي NGINX أو HAProxy) وتغيّر التوجيه منه للنسخة الجديدة وقت ما تكون جاهزة. ——— - لازم النسختين (Blue و Green) يشتغلوا على نفس قاعدة البيانات أو يكون في حل مناسب لمزامنة البيانات. وإلا ممكن تواجه مشاكل في الـ schema أو البيانات نفسها. - لازم تتأكد إن الـ Blue نسخة طبق الأصل من Green + التعديلات الجديدة، علشان تضمن إن rollback هيشتغل كويس لو اضطررت ترجّع. ——— 👀 هل لازم دايمًا تستخدم Blue-Green Deployment؟ لا مش دايمًا. الأسلوب ده مفيد جدًا لو: - التطبيق بتاعك بيشتغل لعدد كبير من المستخدمين. - التحديثات اللي بتعملها حساسة وممكن تعمل مشاكل كبيرة. لكن لو مشروع صغير أو مش فارق معاك downtime بسيط، ممكن تستخدم أساليب أبسط زي Rolling Deployment. ——— وفقكم الله لكل خير 🌿

🔵🟢 يعني إيه Blue-Green Deployment؟ . . تعال أقولك على موقف حصل تقريبًا مع كل الناس اللي اشتغلت على مشاريع شغالة في الـ (Production)... أنت خلصت ميزة جديدة (Feature) أو صلحت مشكلة (Bug Fix)، ومبسوط أوي بالشغل اللي عملته، وداخل تعمل deploy للكود. أول ما تعمل Deploy، تكتشف إن حصلت مشكلة مش متوقعة، والموقع وقع أو المستخدمين اشتكوا من حاجة مخدتش بالك منها. ساعتها بتكون في لحظة توتر مش طبيعية، وتحاول ترجع الكود القديم بسرعة بأي طريقة. هنا بقى بييجي دور الـ Blue-Green Deployment علشان يمنع كل الكوارث دي... ——— 💡 يعني إيه Blue-Green Deployment؟ الـ Blue-Green Deployment هو أسلوب في نشر التحديثات (Deployment Strategy) بيخليك تنشر التغييرات بتاعتك بشكل آمن وسلس ومن غير downtime. ببساطة، بدل ما عندك نسخة واحدة شغالة من التطبيق، بتبقى مشغّل نسختين: - 🟢 النسخة الحالية اللي الناس كلها بتستخدمها دلوقتي اسمها Green - 🔵 النسخة الجديدة اللي فيها التعديلات والتحديثات اسمها Blue أنت بتجهّز نسخة الـ Blue، وتعمل عليها كل الاختبارات المطلوبة. ولما تتأكد إن كل حاجة شغالة تمام، بتبدّل الـ Traffic من Green لـ Blue. يعني المستخدمين بدل ما بيتعاملوا مع النسخة القديمة، بيتحولوا فجأة للنسخة الجديدة من غير ما يحسوا بأي downtime. ——— 🤔 ليه الأسلوب ده ممتاز جدًا؟ 1- الـ Zero Downtime مفيش وقت توقف. التحديث بيحصل في الخلفية، وأول ما يكون جاهز، بيتحوّل الـ Traffic بس. 2- الـ Rollback سهل جدًا لو حصلت مشكلة في النسخة الجديدة، تقدر ترجع المستخدمين تاني للنسخة القديمة بكل سهولة. 3- الاختبار على أرض الواقع تقدر تجرب النسخة الجديدة على عدد محدود من المستخدمين الأول (canary testing) قبل ما تعمل الـ switch الكامل. 4- مش هتبقى خايف تعمل Deploy. حتى لو فيه خطأ، فيه دايمًا نسخة سليمة تقدر ترجع لها. ——— فيه أكتر من طريقة تطبّق بيها Blue-Green Deployment، على حسب البنية التحتية اللي بتشتغل عليها: 1- لو شغال على Kubernetes، ممكن تستخدم مثلًا: - الـ Services + Deployments علشان تتحكم في الـ Traffic. - أدوات زي Argo Rollouts أو Spinnaker 2- لو بتستخدم Cloud Platforms زي AWS أو GCP، فيه أدوات built-in بتساعدك تعمل التبديل ما بين النسخ. 3- ولو شغال بشكل يدوي، ممكن تستخدم load balancer (زي NGINX أو HAProxy) وتغيّر التوجيه منه للنسخة الجديدة وقت ما تكون جاهزة. ——— - لازم النسختين (Blue و Green) يشتغلوا على نفس قاعدة البيانات أو يكون في حل مناسب لمزامنة البيانات. وإلا ممكن تواجه مشاكل في الـ schema أو البيانات نفسها. - لازم تتأكد إن الـ Blue نسخة طبق الأصل من Green + التعديلات الجديدة، علشان تضمن إن rollback هيشتغل كويس لو اضطررت ترجّع. ——— 👀 هل لازم دايمًا تستخدم Blue-Green Deployment؟ لا مش دايمًا. الأسلوب ده مفيد جدًا لو: - التطبيق بتاعك بيشتغل لعدد كبير من المستخدمين. - التحديثات اللي بتعملها حساسة وممكن تعمل مشاكل كبيرة. لكن لو مشروع صغير أو مش فارق معاك downtime بسيط، ممكن تستخدم أساليب أبسط زي Rolling Deployment. ——— وفقكم الله لكل خير 🌿

Introducing Zustand (State Management) Zustand is a minimal, but fun and effective state management library. https://frontendmasters.com/blog/introducing-zustand

كيف غيرت الـ containers بناء البرمجيات عالميا | كورس Docker | Docker - Containers - Images - Volumes https://youtu.be/Xnu-zoqopNM

حابب تتناقش في فكرة أو عندك استفسار؟ اسألني في أي وقت من خلال حسابي على منصة قبيلة 👇 https://qabilah.com/profile/alisamir

API Design 💯