مفهوم الـ 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 كمان.
———
وفقكم الله لكل خير 🌿
.
.
عمرك اشتغلت على سيستم وفجأة لقيت الكلاينت بيقولك "الموقع بيهنج أول ما الناس بتدخل عليه وقت ما يكون فيه خصومات"؟ أو فجأة الـ 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 كمان.
———
وفقكم الله لكل خير 🌿
👍6❤1
كورس ممتاز هيساعدك في التحضير لانترفيو الـ Problem Solving 💯
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
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
❤9
دردشة سريعة عن الـ 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 بشكل منفصل.
———
وفقكم الله لكل خير 🌿
.
.
لما بنسمع كلمة 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 بشكل منفصل.
———
وفقكم الله لكل خير 🌿
❤6
اسألني عن أي شيء من خلال حسابي في قبيلة 👇🏻
https://qabilah.com/profile/alisamir/professional-profile?target=ask-me-anything
https://qabilah.com/profile/alisamir/professional-profile?target=ask-me-anything
❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Color Palette Inspiration 💡
Curated color palette ideas displayed in an example website.
http://happyhues.co
❤5
مفيش كورس واحد بيغطي كل حاجة عن الـ Security في الـ Frontend، بس لو عايز تبدأ صح، ركّز على المواضيع دي بالترتيب:
Prevent users from injecting malicious code into your page.
Protect your forms and requests from being executed without user consent.
Understand JWT, cookies, tokens, and how to handle them securely.
Never trust user input, always validate and sanitize it.
Use headers like CSP, X-Frame-Options, and X-Content-Type-Options to strengthen your app’s security.
Regularly check your npm packages (npm audit, Snyk) for vulnerabilities.
Understand how HTTPS works and how to configure CORS properly.
Store and handle session tokens safely.
Protect your app from being embedded or tricking users with fake UI.
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.
❤8
أهم بدائل الـ 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: هل هو فعلًا الحل المناسب؟ ولا في بديل أفضل يساعدك من ناحية الأداء والأمان؟
———
وفقكم الله لكل خير 🌿
.
.
خلال رحلتك في عالم الـ 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: هل هو فعلًا الحل المناسب؟ ولا في بديل أفضل يساعدك من ناحية الأداء والأمان؟
———
وفقكم الله لكل خير 🌿
❤4🔥2