DevGuide

كيف تعمل الـ 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 💯

الفرق بين Hashing و Encoding و Encryption 🔐 . . لو بتشتغل في الباك إند، أو بتتعامل مع APIs، أو حتى بتشتغل على تطبيق بسيط فيه عملية تسجيل دخول… أكيد قابلت مصطلحات زي Hashing و Encoding و Encryption. وممكن تفتكر إنهم شبه بعض، أو إن أي واحد فيهم "بيأمن البيانات وخلاص". لكن الحقيقة إن كل واحد له هدف مختلف تمامًا، ولو استخدمت حاجة غلط ممكن تفتح ثغرات أمنية وأنت مش واخد بالك. تعال ندردش شوية عن الفرق بينهم... ———

✅ أولًا: الـ Hashing:

تخيل إنك بتعمل بصمة لأي معلومة… مش علشان ترجع لها بعدين، لكن علشان تتأكد إنها متغيرتش. الـ Hashing بياخد قيمة (زي password مثلًا)، ويطلع منها سلسلة ثابتة الطول شكلها عشوائي – اسمها Hash – واللي بتستخدمها عشان تطابق أو تتحقق من البيانات من غير ما تحتاج تخزن الأصل. 🎯 المهم هنا: - العملية دي One Way (مفيش رجوع). - لو غيرت حرف واحد، الـ Hash كله بيتغير. - وده اللي بنستخدمه مثلًا لما نخزن الـ Passwords في قواعد البيانات. ⚠️ لو حد عرف الـ Hash، مش هيعرف يطلع منه الباسورد الأصلي (بس ممكن يعمل Brute Force ويحاول يخمنه). ———

✅ ثانيًا: الـ Encoding:

ده ملوش أي علاقة بالسرية... الـ Encoding هو طريقة بنحول بها البيانات لشكل تاني علشان يسهل تخزينها أو نقلها. زي Base64، اللي بتحول مثلًا صورة أو نص يحتوي رموز غريبة لشكل مفهوم لأي نظام. 🎯 المهم هنا: - العملية دي Two Way (تقدر ترجّع البيانات الأصلية). - مفيش أي حماية أو تشفير، أي حد يعرف نوع الـ encoding يقدر يفكه بسهولة. - الهدف منه بس إنك تنقل الداتا بدون ما تضيع أو تبوظ. مثال بسيط: لو عندك some text ممكن يتحول بـ Base64 إلى: c29tZSB0ZXh0 ———

✅ ثالثًا: الـ Encryption:

أنت عايز تبعت داتا سرية لحد، ومش عايز أي حد في النص يفهمها. فبتعمل لها تشفير باستخدام مفتاح (Key)، والمستلم اللي معاه المفتاح يقدر يفكها. 🎯 المهم هنا: - العملية دي Two Way، بس لازم المفتاح. - لو المفتاح اتسرّب أو ضاع، أي حد يقدر يفك البيانات. - بتستخدمها في إرسال معلومات حساسة زي بطاقات الدفع أو بيانات المستخدمين. فيه نوعين من الـ Encryption: - الـ Symmetric: نفس المفتاح بيشفّر ويفك (زي AES). - الـ Asymmetric: مفتاحين، واحد بيشفّر (public) والتاني بيفك (private) – زي اللي بيستخدم في HTTPS. ——— 💡 إمتى تستخدم مين؟ - بتخزن passwords؟ يبقى Hashing - بتبعت صورة أو داتا عبر API؟ يبقى Encoding - بتبعت معلومات حساسة زي tokens أو بيانات مستخدم؟ يبقى Encryption ——— وفقكم الله لكل خير 🌿

How to Learn Databases? 🤔 1- Database Fundamentals 2- Data Models and Types 3- Querying and Language 4- Indexing and Optimization 5- Security, Backups, and Scaling 6- Tools and Ecosystem

16 Coding Patterns That Make Interviews Easy 💯 1- Two-Pointer Technique 2- HashMaps 3- Linked Lists 4- Fast and Slow Pointers 5- Sliding Window Technique 6- Binary Search 7- Stacks 8- Heaps 9- Prefix Sum 10- Trees 11- Tries 12- Graphs 13- Backtracking 14- Dynamic Programming 15- Greedy Algorithms 16- Intervals

The Most Confused Concepts in Engineering https://youtu.be/z5lpHsl8qQ4 ——— 💡 إن شاء الله قريب نشرح الفرق بينهم بالعربي

مفهوم الـ Atomicity 💯 . . تخيل إنك شغال على سيستم تحويل فلوس. العميل حول 1000 جنيه من حسابه، السيستم خصم الفلوس… وقبل ما يحطهم في حساب الشخص التاني، الكهرباء قطعت. كده الفلوس طارت؟ ولا هترجع؟ ولا هتتحول؟ السؤال ده بيجاوب عليه مفهوم مهم جدًا في البرمجة والـ Databasese وهو الـ Atomicity يا إما كل الخطوات تتم بالكامل...يا مفيش ولا خطوة تتم. ——— 🤔 يعني إيه Atomicity؟ تخيل إنك بتسحب فلوس من الـ ATM. العملية دي فيها خطوتين: 1- البنك يخصم المبلغ من حسابك. 2- الماكينة تطلع لك الفلوس. لو حصل إن السيستم عمل الخطوة الأولى بس، ووقف فجأة قبل ما يوصلك الفلوس… أنت كده خسرت فلوسك؟ هنا بقى ييجي دور الـ Atomicity. الـ Atomicity معناها إن العملية كلها تتنفذ بالكامل من أولها لآخرها، أو ما تتنفذ خالص. يعني All or Nothing. في مثال الـ ATM: يا البنك يخصم وتاخد الفلوس، يا ميحصلش أي حاجة أصلًا. مفيش نص عملية. ——— 💡 إزاي ده بيتم؟ الـ Atomicity هي واحدة من الـ ACID Properties اللي بتضمن سلامة البيانات خصوصًا في الـ Databases. علشان تحقق الـ Atomicity، السيستم بيستخدم حاجة اسمها Transactions. كل Transaction بتتكون من مجموعة عمليات (زي insert، update، delete)، والمفروض إن كل العمليات دي يحصلها commit في نفس الوقت، أو يحصلها rollback لو حصل أي خطأ. مثال:

BEGIN TRANSACTION;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;

لو أي واحدة من الـ 2 updates فشلت، الـ transaction كلها هتتفك، والداتا ترجع زي ما كانت كأن مفيش حاجة حصلت. ——— ⚠️ إيه اللي ممكن يبوّظ الـ Atomicity؟ - قطع الكهرباء أو أي Crash في النص. - الـ Exceptions أو الـ Errors في جزء من الـ transaction. - إنك تنفذ queries من غير transaction أصلًا ولو السيستم مش بيطبق الـ Atomicity صح، الداتا ممكن تبقى corrupted، وساعتها ربنا يستر. ——— 📌 إيه الفرق بين الـ Atomicity وبين الـ Consistency؟ الـ Atomicity بتتكلم عن هل العملية كلها تمت أو لا؟ الـ Consistency بتسأل هل الداتا بعد العملية في حالة صحيحة؟ يعني: - الـ Atomicity = حصل commit كامل ولا لا؟ - الـ Consistency = لو حصل، الداتا بقت consistent ولا لا؟ الاتنين مكملين بعض، بس مش نفس الحاجة. ——— وفقكم الله لكل خير 🌿

مفهوم الـ Atomicity 💯 . . تخيل إنك شغال على سيستم تحويل فلوس. العميل حول 1000 جنيه من حسابه، السيستم خصم الفلوس… وقبل ما يحطهم في حساب الشخص التاني، الكهرباء قطعت. كده الفلوس طارت؟ ولا هترجع؟ ولا هتتحول؟ السؤال ده بيجاوب عليه مفهوم مهم جدًا في البرمجة والـ Databasese وهو الـ Atomicity يا إما كل الخطوات تتم بالكامل...يا مفيش ولا خطوة تتم. ——— 🤔 يعني إيه Atomicity؟ تخيل إنك بتسحب فلوس من الـ ATM. العملية دي فيها خطوتين: 1- البنك يخصم المبلغ من حسابك. 2- الماكينة تطلع لك الفلوس. لو حصل إن السيستم عمل الخطوة الأولى بس، ووقف فجأة قبل ما يوصلك الفلوس… أنت كده خسرت فلوسك؟ هنا بقى ييجي دور الـ Atomicity. الـ Atomicity معناها إن العملية كلها تتنفذ بالكامل من أولها لآخرها، أو ما تتنفذ خالص. يعني All or Nothing. في مثال الـ ATM: يا البنك يخصم وتاخد الفلوس، يا ميحصلش أي حاجة أصلًا. مفيش نص عملية. ——— 💡 إزاي ده بيتم؟ الـ Atomicity هي واحدة من الـ ACID Properties اللي بتضمن سلامة البيانات خصوصًا في الـ Databases. علشان تحقق الـ Atomicity، السيستم بيستخدم حاجة اسمها Transactions. كل Transaction بتتكون من مجموعة عمليات (زي insert، update، delete)، والمفروض إن كل العمليات دي يحصلها commit في نفس الوقت، أو يحصلها rollback لو حصل أي خطأ. مثال: BEGIN TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; COMMIT; لو أي واحدة من الـ 2 updates فشلت، الـ transaction كلها هتتفك، والداتا ترجع زي ما كانت كأن مفيش حاجة حصلت. ——— ⚠️ إيه اللي ممكن يبوّظ الـ Atomicity؟ - قطع الكهرباء أو أي Crash في النص. - الـ Exceptions أو الـ Errors في جزء من الـ transaction. - إنك تنفذ queries من غير transaction أصلًا ولو السيستم مش بيطبق الـ Atomicity صح، الداتا ممكن تبقى corrupted، وساعتها ربنا يستر. ——— 📌 إيه الفرق بين الـ Atomicity وبين الـ Consistency؟ الـ Atomicity بتتكلم عن هل العملية كلها تمت أو لا؟ الـ Consistency بتسأل هل الداتا بعد العملية في حالة صحيحة؟ يعني: - الـ Atomicity = حصل commit كامل ولا لا؟ - الـ Consistency = لو حصل، الداتا بقت consistent ولا لا؟ الاتنين مكملين بعض، بس مش نفس الحاجة. ——— وفقكم الله لكل خير 🌿

مفهوم الـ Dependency Inversion Principle 💡 . . فيه مبدأ من مبادئ SOLID بيغيّر طريقة تفكيرك في تصميم الكود بشكل كبير جدًا... مبدأ أول ما تفهمه كويس وتطبّقه صح، هتحس إن المشروع بقى modular أكتر، والـ testing بقى أسهل، والـ bugs بقت قليلة إلى حد ما... تعال ندردش شوية عن مبدأ الـ Dependency Inversion... ——— 📌 يعني إيه Dependency Inversion Principle؟ المبدأ ده بيقول: "High-level modules should not depend on low-level modules. Both should depend on abstractions." و "Abstractions should not depend on details. Details should depend on abstractions." يعني لما تيجي تبني جزء كبير من السيستم (زي مثلاً order service في تطبيق تجارة إلكترونية)، المفروض ميكنش الـ high-level logic (زي إزاي الـ order بيتم) بيعتمد مباشرة على الـ details زي مثلا API معين أو database معينة أو class بتبعت إيميلات. بدل كده، المفروض يكون بيعتمد على abstraction (interface أو contract)، بحيث التفاصيل دي تقدر تتغير بسهولة بعد كده من غير ما تغيّر في الـ business logic نفسه. ———

📦 مثال بسيط:

[ كل الأكواد في التعليقات 👇 ]

class EmailService {
  sendEmail(to: string, body: string) {
    // logic to send email
  }
}

class OrderService {
  private emailService = new EmailService();

  placeOrder(orderData: any) {
    // logic to place order
    this.emailService.sendEmail(orderData.customerEmail, "Order placed!");
  }
}

كده الـ OrderService معتمد بشكل مباشر على الـ EmailService. لو حبيت تغير وسيلة إرسال الإيميل أو تبعتها عبر SMS أو push notification، هتضطر تغيّر في الكود بتاع OrderService نفسه… وده ضد مبدأ open/closed principle كمان. ———

✅ الحل؟

interface Notifier {
  notify(to: string, message: string): void;
}

class EmailService implements Notifier {
  notify(to: string, message: string) {
    // send email
  }
}

class SMSService implements Notifier {
  notify(to: string, message: string) {
    // send sms
  }
}

class OrderService {
  constructor(private notifier: Notifier) {}

  placeOrder(orderData: any) {
    // logic to place order
    this.notifier.notify(orderData.customerContact, "Order placed!");
  }
}

كده الـ OrderService ميعرفش أي حاجة عن الـ implementation بتاع الـ notifier، سواء كان email أو sms. هو بس بيتعامل مع abstraction (interface اسمها Notifier). وبالتالي تقدر تغير الـ implementation في أي وقت من غير ما تلمس الـ OrderService. ———

💡 إزاي ده هيفرق معاك؟

- الكود بتاعك بقى loosely coupled. - بقى modular وأسهل في التعديل والصيانة. - الـ testing بقى أبسط لأنك تقدر تعمل mock لـ Notifier بسهولة. - بقيت تقدر تبدّل الـ implementation من غير ما تعمل refactor تقيل. ——— الـ Dependency Inversion بيخليك دايمًا تفكر في dependencies على إنها شيء ممكن يتغير… فبدل ما تبني عليها بشكل مباشر، استخدم abstraction تفصل به بين high-level logic و low-level details. ——— وفقكم الله لكل خير 🌿

Struggling with authentication bugs? ⚠️ Learn clean NextAuth.js patterns to secure your Next.js app like a pro!

System Design was HARD until I Learned these 30 Concepts 💯 https://medium.com/algomaster-io/system-design-was-hard-until-i-learned-these-30-concepts-78042ff99cae