Color Palette Inspiration 💡

Curated color palette ideas displayed in an example website.

http://happyhues.co

مفيش كورس واحد بيغطي كل حاجة عن الـ 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.

أهم بدائل الـ localStorage 💡
.
.
خلال رحلتك في عالم الـ Front-End لازم في وقت من الأوقات هتحتاج تخزن بيانات عند الـ Client Side (يعني عند المستخدم).

أبسط حاجة كلنا عرفناها في الأول هي الـ localStorage. سهلة جدًا والكود بسيط، وكمان عبارة عن key/value، بس الحقيقة إن localStorage مش دايمًا أحسن حل.

ليه؟ 👇

- الـ size محدود (تقريبًا 5MB).
- كل حاجة بتتخزن كـ string.
- مفيهاش أي نوع من الـ security (ممكن أي حد يقرأها).
- مش scalable لو بتتعامل مع data كبيرة.

علشان كده تعال ندردش شوية عن 4 بدائل للـ localStorage ممكن تساعدك في بعض السيناريوهات المختلفة...

———

📌 الـ IndexedDB

- دي عبارة عن database كاملة داخل الـ browser.
- بتخليك تخزن structured data (objects، arrays…) مش مجرد strings.
- بتتعامل معاها عن طريق APIs أو libraries زي Dexie.js عشان تسهّل الموضوع.
- مناسبة جدًا لو عندك data كبيرة أو offline apps زي Note Apps أو Todo Apps.
- أسرع بكتير في الـ queries من localStorage.

———

📌 الـ sessionStorage

- نفس فكرة localStorage بالضبط لكن الفرق إنها بتتمسح أول ما الـ tab تتقفل.
- مناسبة لحاجات temporary زي tokens أثناء الـ session أو data مش مهمة تحتفظ بها بعد ما اليوزر يقفل الصفحة.
- حجمها برضه محدود زي localStorage.

———

📌 الـ Cookies

- أقدم وأشهر طريقة لتخزين البيانات في الـ browser.
- ميزتها إنها بتتبعت تلقائي مع كل HTTP Request للـ server.
- مناسبة جدًا للـ authentication (زي الـ JWT tokens أو session IDs).
- بس عيبها إنها صغيرة (حوالي 4KB) وأي data زيادة ممكن تقلل سرعة الـ requests.
- لازم تستخدمها للحاجات الخفيفة والمهمة بس.

———

📌 الـ Service Workers + Cache API

- ده حل advanced شوية، بيستخدم الـ Service Workers مع Cache API.
- بيخليك تخزن responses كاملة من الـ network (زي HTML, CSS, JS, Images).
- ممتاز للـ Progressive Web Apps (PWA) عشان تشتغل offline.
- تقدر تتحكم في caching strategy (مثلًا: Network First, Cache First…).
- مفيد جدًا للأداء (performance) وتحسين تجربة المستخدم.

———

💡 الخلاصة:

- لو data كبيرة: استخدم IndexedDB.
- لو data بسيطة ومؤقتة: sessionStorage.
- لو عايز data تتبعت للـ server: استخدم Cookies.
- لو بتبني PWA أو محتاج caching قوي: استخدم Service Workers + Cache API.

فكر دايمًا قبل ما تستخدم localStorage: هل هو فعلًا الحل المناسب؟ ولا في بديل أفضل يساعدك من ناحية الأداء والأمان؟

———

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

دردشة سريعة عن الـ HTTP Caching 🔻
.
.
من ضمن المصطلحات المهمة جدًا في عالم الويب، خصوصًا لو مهتم بـ تحسين أداء المواقع... إيه فكرته وإزاي الموضوع ده بيساعد في تسريع المواقع وتحسين تجربة المستخدم؟

———

📌 يعني إيه Caching؟

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

الفكرة هنا هي إنك بتقلل الوقت المستغرق في تحميل الصفحة، وبتقلل الضغط على السيرفر كمان.

———

📌 إزاي الـ HTTP Caching بيشتغل؟

لما تفتح موقع، الطلبات اللي بتروح للسيرفر (الـ HTTP Requests) ممكن يترد عليها ببيانات بتتخزن عندك محليًا أو على مستوى معين من الشبكة.

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

———

📌 أنواع الـ HTTP Caching:

- الـ Browser Caching:

المتصفح بيخزن حاجات زي الصور، ملفات CSS، و JavaScript لفترة معينة. لما تزور الموقع تاني، المتصفح بيستخدم الحاجات دي بدل ما يحملها من السيرفر.


- الـ Server-Side Caching:

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


- الـ CDN Caching:

الـ Content Delivery Network هو شبكة سيرفرات موزعة عالميًا. السيرفرات دي بتخزن محتوى الموقع (زي الصور والفيديوهات) عشان توصل للمستخدمين من أقرب سيرفر ليهم، وبالتالي تقلل زمن التحميل.


———

الموضوع ده مش بيشتغل لوحده، لازم نستخدم شوية إعدادات زي الـ Cache-Control Headers عشان نتحكم في إزاي البيانات تتخزن، وفترة التخزين، وإمتى البيانات دي تتحدث. تعال نشوف أشهر الأنواع:

⚡️ الـ public: يعني البيانات ممكن تتخزن في أكتر من مكان، زي المتصفح أو الـ CDN.

⚡️ الـ private: البيانات تتخزن عند المستخدم بس، ومش مفروض تبقى متاحة على سيرفرات تانية.

⚡️ الـ no-cache: البيانات محتاجة تتأكد من صحتها قبل الاستخدام، يعني لازم يتم التأكد من إنها لسه صالحة من السيرفر.

⚡️ الـ max-age: ده بيحدد المدة اللي البيانات تفضل متخزنة فيها (بالثواني).


———

📌 ليه الـ HTTP Caching مهم؟

✅ سرعة التحميل: المواقع بتفتح أسرع لأن المتصفح مش بيضطر يحمل كل حاجة من الأول.

✅ تخفيف الحمل على السيرفر: كل ما الطلبات للسيرفر تقل، السيرفر يقدر يخدم عدد أكبر من المستخدمين في نفس الوقت.

✅ تجربة مستخدم أفضل: الناس بتحب المواقع السريعة، وده بيخليهم يقعدوا وقت أطول ويتفاعلوا أكتر مع الموقع.

———

📌 إيه المشاكل اللي ممكن تقابلنا؟

- لو بيانات الموقع بتتحدث كتير، ممكن المستخدم يشوف بيانات قديمة لو الـ Cache مش معمول له إدارة كويسة.

- ضبط الـ Caching بطريقة صح بيحتاج شوية خبرة، خصوصًا لو الموقع فيه أجزاء كتير بتتحدث بشكل مستمر.

———

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