إزاي تتجنب الـ Memory Leaks في JavaScript؟ 🤔
.
.
خلال رحلتك في عالم الـ JavaScript، سواء في فرونت اند أو باك اند، ممكن تكون سمعت عن مصطلح الـ "Memory Leaks". وده موضوع ممكن يتسبب في كوارث زي إن التطبيق بتاعك يبقى بطيء جدًا أو حتى ينهار خالص...⚠️

تعال ندردش شوية عن الـ Memory Leaks وإزاي تتجنبها في الكود...

———

Memory Leaks in JavaScript: A Simple Guide 💯

في المقال ده تكلمنا عن أهم المواضيع اللي تخص الـ Memory Leaks:

📍 What is a Memory Leak?
📍 How JavaScript Manages Memory
📍 Common Causes of Memory Leaks
📍 How to Detect Memory Leaks
📍 Tips to Prevent Memory Leaks

———

📌 رابط المقال:

⚡️ Dev Community
https://dev.to/alisamir/memory-leaks-in-javascript-a-simple-guide-31e8

⚡️ Medium
https://medium.com/@dev.alisamir/memory-leaks-in-javascript-a-simple-guide-e274d44f169c

———

وفقكم الله لكل خير ☘️

———

#javascript@the_developer_guide

One line of CSS. Smooth page transitions. No JavaScript. 💯

@view-transition {
  navigation: auto;
}

The 🆕 CSS View Transitions bring native animations to multi-page apps, no SPA setup needed!

———

Explore now 👇
https://developer.mozilla.org/en-US/blog/view-transitions-beginner-guide

———

#css@the_developer_guide

12 نصيحـة لحمـاية الـ APIs! 🛡
.
.
في عالم البرمجة، تعتبر الـ APIs هي الأعصاب في جسم التطبيقات، لو حصل فيها مشكلة، الدنيا كلها بتخرب. عشان كده، حماية الـ APIs مهم جدًا وحاجة أساسية في التطبيق. 💡

تعال ندردش شوية عن طرق حماية الـ APIs...

———

1- استخدم الـ HTTPS:

دي أول حاجة لازم تعملها، أي حاجة بتتبعت أو بتستقبلها لازم تكون مشفّرة، عشان تحمي بياناتك.

2- اعتمد على الـ OAuth2:

ده المعيار الأساسي عشان تحمي التطبيقات اللي بتتصل بـ APIs، وبيضمن إن الـ Token اللي بيتبعت آمن ومحدود الصلاحيات.

3- جرب الـ WebAuthn:

لو شغلك فيه حساسية عالية، فكر في WebAuthn عشان تضيف طبقة أمان من خلال المصادقة البيومترية (زي البصمة أو التعرف على الوجه).

4- قسّم المفاتيح حسب الصلاحيات (Leveled API Keys):

مينفعش نفس المفتاح يقدر يعمل كل حاجة! قسّم المفاتيح بناءً على صلاحيات المستخدم أو التطبيق.

5- ركز على الـ Authorization مش بس الـ Authentication:

مجرد إن المستخدم سجل الدخول مش معناه إنه مسموح له يعمل كل حاجة. تأكد إن كل طلب معمول له تفويض.

6- طبّق الـ Rate Limiting:

متخليش أي حد يقدر يضرب الـ API بتاعتك بمئات الطلبات في الثانية. كده هتحمي نفسك من الـ DDoS attacks.

7- اعمل API Versioning:

تغيير صغير في الـ API ممكن يبوّظ تطبيقات كتير لو مش مأمن نسخة قديمة لها. حافظ على الإصدارات المختلفة.

8- استخدم Whitelisting:

اسمح بس لطلبات جايه من IPs معينة، وده بيقلل احتمالية الاختراق من جهات غير معروفة.

9- افحص OWASP API Security Risks:

قائمة OWASP دي زي الكتالوج للمخاطر الشائعة في الـ APIs. تأكد إنك عارفهم وعالجتهم.

10- خلي فيه API Gateway:

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

11- تعامل بحرص مع الأخطاء (Error Handling):

متطلعش معلومات حساسة لما يحصل خطأ، زي الـ stack traces أو البيانات الداخلية.

12- فعّل Input Validation:

بلاش تدي الأمان للبيانات اللي جايه من الـ client بشكل عشوائي. افحص كل المدخلات وتأكد إنها سليمة.

———

وفقكم الله لكل خير ☘️

———

#api@the_developer_guide

دردشة سريعة عن الـ React Server Components ⚡️
.
.
لو بتشتغل React بقالك فترة، أكيد عارف إن واحد من أكبر التحديات هو إن الأداء ساعات بيتأثر، والـ bundle size بيكبر، وبتلاقي نفسك بتجري ورا الـ optimization يمين وشمال: تضيف memo هنا، و useCallback هناك، و Server-Side Rendering عشان السرعة… بس لسه حاسس إن فيه حاجة ناقصة.

علشان كده React طلعوا بحاجة اسمها React Server Components (RSC)…

الـ React Server Components بتنقل React إلى مستوى تاني خالص. بتخلّي جزء كبير من الكود يشتغل على الـ Server بدل ما ينزل كله للـ Client، وبالتالي:

✅ الـ performance أعلى
✅ الـ bundle size أقل
✅ الـ data fetching أسهل وأبسط
✅ هيكون عندك zero client-side overhead لحاجات مش محتاجة تكون Client components أصلًا

يعني تخيّل تعمل Component كاملة تتنفذ على السيرفر من غير ما تنزل للمتصفح… وتقدر تدخل فيها مباشرة DB queries أو تستخدم APIs من غير ما تفكر في security ولا hooks زي useEffect…

———

الـ RSC هي Components بيحصل لها render بالكامل على الـ Server، ومش بتوصل للـ Browser كـ JavaScript code. هي بتبعت الـ UI final result للـ Client بشكل lightweight، من غير ما يبقى محتاج hydrate زي الـ SSR.

———

📌 الفرق بينها وبين SSR (Server-Side Rendering)؟

📍 الـ SSR:
- السيرفر بيعمل render، بس بيبعت HTML + hydration scripts
- بيبعت JS كتير للـ Client
- الهدف: تحسين الـ First Paint

📍 الـ Server Components:
- السيرفر بيبعت UI بدون hydration، ومش كل حاجة بتحتاج تكون interactive
- ممكن تمنع تحميل JS أصلًا لبعض الـ Components
- الهدف: تقليل الـ bundle size + handling logic على السيرفر

———

✅ الـ Server Components: بتتكتب بنفس شكل الـ Components العادية، بس بيحصل لها render على السيرفر فقط، ومينفعش تستخدم فيها useState أو useEffect.

✅ الـ Client Components: دي اللي بتشتغل على الـ Browser، وبتحتاج تكتب في أولها "use client" عشان React تفهم إنها لازم تنزل للـ Client.

———

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

———

#react@the_developer_guide

مفهوم الـ Load Test 💡
.
.
عمرك اشتغلت على سيستم وفجأة لقيت الكلاينت بيقولك "الموقع بيهنج أول ما الناس بتدخل عليه وقت ما يكون فيه خصومات"؟ أو فجأة الـ backend بيقع لما الترافيك يكون عالي؟

ساعتها أكيد أول حاجة بتفكر فيها: "إحنا عملنا Load Test؟"
وغالبًا الإجابة بتكون لأ. ودي غلطة كبيرة جدًا ممكن تبوّظ المشروع كله والكلاينت يطير منك، حتى لو السيستم معمول صح 100%.

تعال ندردش شوية عن واحد من أهم أنواع الـ Testing اللي دايمًا بيتنسي:
Load Testing

———

📌 يعني إيه Load Testing؟

الـ Load Test هو نوع من أنواع الـ Performance Testing. فكر فيه كأنك بتختبر السيستم بتاعك تحت الضغط.
يعني بتشوف السيستم هيشتغل إزاي لما يبقى عليه عدد كبير من الـ users في نفس الوقت.

الهدف الأساسي منه هو:

- تتأكد إن السيستم هيقدر يتحمّل الترافيك المتوقع.
- تعرف البوينت اللي بيبدأ فيها ينهار أو يبطأ.
- تلاقي الـ bottlenecks اللي ممكن تسبب مشاكل في الـ scalability.

———

💡 إزاي بنعمل Load Testing؟

ببساطة، بنستخدم Tools بتعمل simulation لعدد كبير من الـ users بيدخلوا على السيستم في نفس الوقت.
وبيبدأوا يعملوا Requests زي كأنهم مستخدمين حقيقيين.

ومن أشهر الـ Tools دي:

- JMeter
- k6
- Gatling
- Locust
- Artillery

———

👀 إيه الحاجات اللي بنقيسها أثناء الـ Load Test؟

- الـ Response Time: كل Request بياخد وقت قد إيه علشان يرجع.
- الـ Throughput: عدد الـ requests اللي السيرفر بيقدر يعالجها في الثانية.
- الـ Error Rate: نسبة الـ requests اللي بتفشل.
- الـ CPU و Memory Usage: السيستم بيستهلك قد إيه من الموارد.
- الـ Database Performance: هل الـ DB queries بتبطأ ولا فيها deadlocks؟
- الـ Bottlenecks: إيه المناطق اللي بتعطّل السيستم تحت الضغط؟ Backend؟ Cache؟ DB؟

———

💥 سيناريوهات لازم تختبرها في الـ Load Test

- لو عندك 1000 مستخدم بيسجلوا في نفس اللحظة.
- لو عندك 500 مستخدم بيطلبوا بيانات من نفس API.
- لو عندك 200 مستخدم بيعملوا checkout في نفس التوقيت.
- لو عندك 3000 مستخدم بيعملوا login على السيستم في أول دقيقة من الحملة الإعلانية.

———

⚠️ أخطاء شائعة بتحصل:

- بتعمل test على بيئة dev أو staging ضعيفة، فتطلع نتائج غير واقعية.
- بتعمل test على سيناريو واحد بس ومش بتغطي باقي الـ use cases.
- مش بتحلل النتائج كويس، وبتفتكر إن الـ test عدى خلاص فالدنيا تمام.

———

✅ نصائح عملية:

اعمل الـ Load Testing بدري في مرحلة التطوير، مش بعد ما تسلّم المشروع.

خليه جزء من الـ CI/CD pipeline.

حلل النتائج بعمق، وبص على كل metrics مش بس الـ response time.

متنساش إن الـ frontend pages ممكن تبطأ بسبب مشاكل في الـ client-side كمان.

———

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

كورس ممتاز هيساعدك في التحضير لانترفيو الـ Problem Solving 💯

Neetcode 150 Course - All Coding Interview Questions Solved 🚀

The NeetCode 150 is the most important LeetCode problems you need to master, selected to cover all major algorithmic patterns that top tech companies test for.

https://youtu.be/T0u5nwSA0w0

———

وده شيت فيه مجموعة مسائل لذيذة هتساعدك في عالم الـ Problem Solving

📍 Most Asked Technical Interview Questions:
https://docs.google.com/spreadsheets/d/1hzP8j7matoUiJ15N-RhsL5Dmig8_E3aP/edit

دردشة سريعة عن الـ Monolithic Architecture 💯
.
.
لما بنسمع كلمة Monolithic Architecture ممكن ييجي في دماغنا إنها حاجة قديمة خلاص ومبقتش تستخدم. بس الحقيقة إن الشكل ده من الـ architecture لسه موجود في مشاريع كتير، وساعات كمان بيكون هو الحل الأمثل في بدايات أي مشروع.

السبب؟ لأنه ببساطة أبسط شكل ممكن تبني به تطبيق أو سيستم وهيكون عبارة عن كود واحد، deploy واحد، وكل حاجة تحت سقف واحد. الفكرة دي شكلها سهلة وبديهية جدًا، وده اللي خلّاها تفضل مستخدمة سنين طويلة. لكن مع إن الموضوع باين عليه straightforward، لكن له مميزات وعيوب ممكن تأثر جدًا على قرارك كمبرمج أو كـ startup founder.

———

🎯 يعني إيه Monolithic Architecture؟

تخيل إنك بتبني سيستم كامل زي موقع e-commerce فيه:

- الـ UI (front-end).
- الـ business logic (زي إضافة منتجات للسلة، حساب الخصومات).
- الـ database access (CRUD operations).

في الـ Monolithic Architecture… كل ده بيتحط في codebase واحد، ويتعمله deplpoy كـ تطبيق واحد (single unit).

يعني لو عايز تعدل في جزء معين لازم تعيد Deploy للتطبيق كله.

———

✅ مميزات Monolithic Architecture:

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

2- سهولة الـ Development في البداية:
مثالي جدًا للـ MVP أو المشاريع الصغيرة.

3- أداء كويس:
مفيش network latency بين components (كلها في نفس العملية).

4- سهولة الـ Testing:
تقدر تعمل end-to-end test بسهولة لأن كل حاجة في مكان واحد.

———

❌ عيوب Monolithic Architecture:

1- صعوبة التوسّع (Scalability):
عايز تكبر جزء واحد بس من السيستم؟ مش هتقدر… لازم تكبر التطبيق كله.

2- الـ Codebase ضخم ومعقد مع الوقت:
لما المشروع يكبر، الكود بيبقى صعب أي حد يفهمه ويتعامل معاه.

3- ضعف المرونة في اختيار التكنولوجيا:
مش هينفع تبني جزء بـ Node.js وجزء بـ Python، كله لازم يبقى بنفس الـ stack.

4- بطء في الـ Deployment:
أي تعديل صغير لازم هتعمل Deploy التطبيق كله.

5- الـ Reliability ضعيفة:
لو جزء واحد وقع، ممكن يأثر على السيستم كله.

———

📌 إمتى تستخدم Monolithic Architecture؟

- لو بتبني مشروع صغير أو MVP وعايز تجرّب الفكرة بسرعة.
- لو عندك فريق صغير ومحتاج تقلل الـ overhead.
- لو لسه السيستم مش معقد ومش محتاج Scalability عالية.

———

الـ Monolithic: كل حاجة في تطبيق واحد.
الـ Microservices: السيستم متقسم لمجموعة خدمات مستقلة، كل خدمة بتشتغل لوحدها وتقدر تعمل Deploy/Scale/Debug بشكل منفصل.

———

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