دردشة سريعة عن الـ Temporal Dead Zone في JavaScript ⚡️
.
.
لو اشتغلت بـ let أو const في JavaScript، يبقى مهم جدًا تبقى فاهم الموضوع ده كويس جدًا… عشان هو واحد من الحاجات اللي ممكن تخلي الكود بتاعك يضرب وأنت مش فاهم ليه، وتفضل تلف حول نفسك بالساعات تحاول تحل error شكله غريب جدًا...

تعال ندردش شوية عن الـ Temporal Dead Zone أو الـ TDZ

———

🎯 الأول: يعني إيه Temporal Dead Zone؟

ببساطة كده، الـ Temporal Dead Zone هي الفترة الزمنية اللي بتبدأ من أول ما الـ scope بتاع المتغير بيتنفذ، لحد اللحظة اللي المتغير نفسه بيتعرف فيها (يعني بيتعمله declaration).

خلال الفترة دي، المتغير موجود "في دماغ JavaScript" بس مش مسموح توصل له، ولو حاولت تستخدمه... JavaScript هتقولك ReferenceError.

———

✅ مثال سريع يوضح الموضوع:

console.log(myVar); // ReferenceError: Cannot access 'myVar' before initialization
let myVar = 10;

تفتكر ليه الكود ده بيطلع Error؟

ده لأن myVar دخل في الـ Temporal Dead Zone من أول ما الـ scope بدأ، ومش خارج منها غير بعد ما نوصل لسطر

let myVar = 10

يعني المتغير موجود بس مش جاهز لسه للاستخدام.

———

🤔 طب ليه ده بيحصل؟

الـ JavaScript بتعمل حاجة اسمها Hoisting لكل المتغيرات، سواء var أو let أو const.

بس فيه فرق:

- الـ var: بيتعمله hoisting وتبقى الـ default value = undefined، فممكن تستخدمها قبل ما تُعلن عنها.
- الـ let و const: بيتعملهم hoisting بردو، لكن ملهمش value، وبيكونوا في منطقة اسمها الـ TDZ لحد ما يوصل السطر اللي بيعملهم declaration.

———

مجموعة أمثلة توضح الفرق بين var و let:

مثال بـ var:

console.log(a); // undefined
var a = 5;

نفس المثال بـ let:

console.log(b); // ReferenceError
let b = 5;

الاتنين اتعملهم hoisting… بس var أخذ value undefined، إنما let من غير value، فدخل في الـ TDZ...

———

📌 معلومات مهمة عن الـ TDZ:

1- الـ TDZ مش بس بتأثر على المتغيرات… كمان بتأثر على function parameters اللي متعرف لها default values

2- المتغير بيفضل في TDZ لحد ما توصل لسطر التعريف بتاعه.

3- الـ const كمان لها TDZ زي let بالضبط، لكن الفرق إنك لازم تعطيها قيمة وقت التعريف.

4- الـ TDZ بتمنعك من استخدام المتغير قبل ما تجهزه، وده هيحميك من مشاكل كتيرة.

———

🧠 كده نفهم إن:

الـ let و const أحسن من var في إنهم بيخلوا الكود predictable.

بس في نفس الوقت لازم تكون فاهم TDZ كويس جدًا علشان متغلطش غلطة بسيطة تكسرلك الكود.

كل ما تستخدم let أو const فوق في الكود، تأكد إنك مش بتستدعيهم قبل ما يتعرفوا.

Deep clean and optimize your Mac. 🚀

https://github.com/tw93/mole

يعني إيه API Gateway؟
.
.
تخيل معايا إنك داخل مطعم كبير جدًا، والمطبخ فيه أكتر من شيف:
واحد مسؤول عن البيتزا 🍕، والتاني عن الحلويات 🍰، والتالت عن المشروبات ☕️.

وأنت كـ زبون، مش هتروح لكل شيف وتطلب منه، صح؟
فيه جرسون (الـ waiter) بياخد طلبك ويوصّله للمطبخ، ويجيبلك الأكل كله مرّة واحدة.

الجرسون ده في عالم البرمجة اسمه: API Gateway.

———

💡 يعني إيه API Gateway؟

ببساطة، الـ API Gateway هو حارس البوابة أو نقطة الدخول الوحيدة لكل الـ APIs اللي السيرفر أو النظام بيقدّمها.

لو عندك نظام ضخم (زي موقع تجارة إلكترونية مثلًا)، هتلاقي كل جزء فيه شغّال كـ Microservice:

- جزء لطلب الأوردرات
- جزء لحسابات المستخدمين
- جزء للمنتجات
- جزء للدفع الإلكتروني


الـ API Gateway بيجمع كل الخدمات دي وبيخلي الـ Frontend أو الموبايل يتعامل مع نقطة واحدة بس، بدل ما يبعت طلبات متفرقة لكل خدمة.

———

🤔 ليه نستخدم API Gateway؟

✅ توحيد نقطة الاتصال
بدل ما الـ Frontend يتعامل مع 5 أو 10 APIs، بيتعامل مع gateway واحدة.

🔐 الأمان
الـ Gateway تقدر تضيف layer للأمان: JWT, API keys, Rate limiting... إلخ.

📊 المراقبة والتحليل
تقدر تعرف مين بيطلب إيه، وإمتى، وتراقب كل حاجة من مكان واحد.

📦 الـ Caching و Load Balancing
ممكن يخزّن الردود (Cache) ويوزّع الأحمال بشكل ذكي.

🔁 تحويل البيانات
لو خدمة بترد بـ XML وانت محتاج JSON، الـ Gateway ممكن يتصرف.

———

🛠 أمثلة حقيقية لـ API Gateways:

- Kong
- AWS API Gateway
- Nginx
- Apigee
- Zuul

———

#دقيقة_برمجة

From TCP to HTTP | Full Course 💯

https://youtu.be/FknTw9bJsXM

مفيش كورس واحد بيغطي كل حاجة عن الـ Security في الـ Frontend، بس لو عايز تبدأ صح، ركّز على المواضيع دي بالترتيب:


1- XSS (Cross-Site Scripting)
Prevent users from injecting malicious code into your page.

2- CSRF (Cross-Site Request Forgery)
Protect your forms and requests from being executed without user consent.

3- Authentication & Authorization
Understand JWT, cookies, tokens, and how to handle them securely.

4- Input Validation & Sanitization
Never trust user input, always validate and sanitize it.

5- Secure Headers
Use headers like CSP, X-Frame-Options, and X-Content-Type-Options to strengthen your app’s security.

6- Dependencies Security
Regularly check your npm packages (npm audit, Snyk) for vulnerabilities.

7- HTTPS & CORS
Understand how HTTPS works and how to configure CORS properly.

8- Session Management
Store and handle session tokens safely.

9- Clickjacking & Phishing Protection
Protect your app from being embedded or tricking users with fake UI.

Divider between items in CSS ⚡️

الفرق بين الـ Primary Key والـ Foreign Key 💯
.
.
خلينا نتخيل قواعد البيانات كأنها شيت إكسيل كبير فيه جداول (Tables)، وكل جدول فيه صفوف (Rows) وأعمدة (Columns)، إزاي نقدر نميّز كل صف لوحده؟ أو نربط بين جدول وجدول؟ هنا بقى بييجي دور الـ Primary Key والـ Foreign Key.

———

🔸 أولًا: الـ Primary Key – المفتاح الأساسي

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

- لازم يكون Unique: يعني كل صف له رقم مختلف عن التاني.
- لا يسمح بـ null: يعني لازم تكون القيمة موجودة ومش فاضية.


🎯 مثال بسيط: لو عندك جدول اسمه Students، ممكن تضيف عمود اسمه student_id كـ Primary Key. يعني كل طالب له ID مختلف، ده بيساعدنا نميّزه ونتعامل مع بياناته بسهولة.

———

🔸 ثانيًا: الـ Foreign Key – المفتاح الأجنبي أو المفتاح الرابط

هنا بقى الموضوع له علاقة بالعلاقات (Relationships) بين الجداول.

الـ Foreign Key هو عمود موجود في جدول، بس بيرجع يشاور على الـ Primary Key بتاع جدول تاني.
يعني بيقولك: "القيمة اللي هنا، لازم تكون موجودة هناك"


✅ استخدامه الأساسي:

- بيربط الجداول ببعض.
- بيساعدنا نحافظ على "سلامة البيانات" (Data Integrity)، يعني ميبقاش فيه بيانات ملهاش معنى أو ملهاش علاقة.


🎯 مثال: لو عندنا جدول اسمه Orders، وعايزين نعرف كل أوردر اتعمل من مين، هنضيف عمود اسمه user_id كـ Foreign Key، اللي بيربط الأوردر ده بالمستخدم اللي موجود في جدول Users.

———

📌 الخلاصة في كلمتين:

- الـ Primary Key: بيميز كل صف في جدول لوحده.
- الـ Foreign Key: بيربط الصف ده بصف تاني في جدول تاني.

الاتنين مع بعض زي المفتاح والباب... واحد يفتحلك الصف، والتاني يخليك توصل لجدول تاني وتربط البيانات ببعضها. 💡

———

#دقيقة_برمجة

يعني إيه Bearer Token وإزاي بيشتغل؟ 🤔

.
.
خليني أسألك سؤال... لما تدخل أي موقع ويطلب منك تسجيل الدخول، هل كل مرة بتفتح الموقع بيطلب منك اسم المستخدم والباسورد من الأول؟ "في الغالب" لا، لأنه بعد ما بتسجّل دخول بيتم إصدار Token تستخدمه بدل ما تدخل بياناتك كل مرة.

هنا بقى بييجي دور الـ Bearer Token... ده واحد من أشهر أنواع الـ Access Tokens واللي بيتم استخدامه في الـ authentication (وغالبًا مع معيار OAuth 2.0)، وده معناه إنك لما تبعت request لأي API محمي (Protected)، بدل ما تبعت بيانات تسجيل الدخول كل مرة، بتبعت الـ Token بيأكد إنك شخص موثوق.

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

———

📌 إزاي الـ Bearer Token بيشتغل؟

الموضوع بيتم على 3 مراحل:

1- تسجيل الدخول: لما المستخدم بيدخل بياناته الصح، السيرفر بيعمله authenticate، وبعدها بيصدر له Bearer Token (ممكن يكون مشفر زي JWT).

2- استخدام الـ Token: في كل request بعد كده، الـ Token بيتبعت مع الهيدر (Header) في الـ Authorization بالشكل ده:

Authorization: Bearer YOUR_ACCESS_TOKEN

وده معناه إن أي حد معاه الـ Token يقدر يستخدمه للوصول للـ API

3- التحقق من الـ Token: السيرفر بيستلم الـ Token ويشوف إذا كان صالح ولا لا (ممكن بمفتاح تشفير لو مشفر)، ولو كان صحيح، بيكمل تنفيذ الطلب، ولو كان منتهي أو غير صحيح، بيرد بخطأ Unauthorized (401).

———

📌 طب ليه اسمه Bearer Token؟

كلمة Bearer معناها "حامل"، وده لأن أي حد معاه الـ Token ده يقدر يستخدمه من غير ما يثبت هويته بأي حاجة تانية. بمعنى إن الـ Token لو اتسرق، اللي سرقه هيقدر يستخدمه كأنه أنت بالضبط.

———

📌 إيه المشاكل الأمنية اللي ممكن تواجهك مع Bearer Token؟

💀 الـ Token Theft: لو حد قدر يحصل على الـ Token بتاعك، يقدر يستخدمه كأنه أنت، ومفيش extra verification زي الـ refresh tokens أو OAuth flows اللي بتتأكد إن الشخص فعلًا هو المستخدم الحقيقي.

⌛️ الـ Expiration Issues: لو الـ Token مش بيخلص بسرعة، يبقى عندك مشكلة، لأن أي حد يسرقه يقدر يستخدمه لمدة طويلة، عشان كده الـ Tokens بتبقى لها expiry time، وبعدها لازم تعمل refresh.

📡 الـ Man-in-the-Middle Attacks: لو الـ Token بيتبعت من غير encryption، ممكن حد يعترضه ويستخدمه، عشان كده لازم تتأكد إن كل حاجة بتتم تحت HTTPS مش HTTP

🔄 الـ Replay Attacks: لو مكنش فيه حماية زي timestamps، ممكن حد يستخدم الـ Token المسروق أكتر من مرة.

———

📌 إزاي تأمن الـ Bearer Token؟

✅ استخدم HTTPS: عشان تمنع أي حد من التجسس على الـ Token أثناء نقله.

✅ حدد مدة صلاحية قصيرة للـ Token: خلي الـ Token يخلص بعد فترة قصيرة عشان لو اتسرق، يبقى ملوش لازمة.

✅ استخدم Refresh Tokens: عشان المستخدم يقدر يحصل على Token جديد لما الـ Token القديم يخلص.

✅ خزن الـ Token في مكان آمن: في المتصفح، بلاش تخزنه في localStorage لأنه ممكن يتسرق بسهولة، استخدم HttpOnly Cookies لو أمكن.

✅ استخدم Scopes: لو بتستخدم API، متديش الـ Token صلاحيات أكتر من المطلوب، مثلًا متديلوش صلاحية إنه يمسح داتا لو هو بس هيقرأ بيانات.

✅ ظبط CORS كويس: عشان تمنع أي مصدر مش موثوق من استخدام الـ Token.

———

#دقيقة_برمجة

🎯 الفرق بين الـ Client-side Validation والـ Server-side Validation
.
.
أول حاجة تعال نتفق إن الـ "Validation" يعني التحقق من صحة البيانات اللي المستخدم بيدخلها، زي مثلًا لما تيجي تسجل في موقع وتدخل الإيميل والباسورد، لازم الموقع يتأكد إن البيانات دي صح ومظبوطة قبل ما يحفظها أو يتعامل معاها.

التحقق ده ممكن يحصل في مكانين:

———

🔹 الـ Client-side Validation (التحقق في المتصفح):

- يعني التحقق بيحصل قبل ما البيانات تروح للسيرفر.
- الكود اللي بيعمل التحقق ده بيكون شغال عند المستخدم نفسه، غالبًا باستخدام JavaScript أو HTML5 Validation.

مثلًا لو أنت بتدخل بياناتك في فورم تسجيل، والمتصفح طلع لك رسالة بتقولك "الإيميل مش مكتوب بطريقة صحيحة" أو "الباسورد قصير"، قبل حتى ما تضغط على Submit... ده كده Client-side Validation.

ولكن النوع ده مش آمن بنسبة ١٠٠٪، ومينفعش نعتمد عليه لوحده.

———

🔹 الـ Server-side Validation (التحقق عند السيرفر):

- هنا التحقق بيحصل بعد ما البيانات تتبعت للسيرفر.
- السيرفر هو اللي بيتأكد بنفسه من كل حاجة: الإيميل صح؟ الباسورد قوي؟ وهكذا.

بغض النظر المستخدم عمل إيه على جهازه، السيرفر بيستلم الداتا ويتأكد منها بنفسه.

النوع ده ممكن يحميك من هجمات زي SQL Injection وغيرها، ولكن ده بيزود الحمل على السيرفر.

———

✅ إيه الصح؟

الصح والمُتبع في أي مشروع محترم إنك تستخدم النوعين مع بعض:

- تعمل Client-side Validation عشان تحسن تجربة المستخدم وتظهر له Feedback سريع.
- وتعمل كمان Server-side Validation عشان تأمن نفسك وتحافظ على السيرفر والداتا بتاعتك.

———

#دقيقة_برمجة