VOL38: Deep Dive Into Rate Limiting
أهلًا وسهلا بكم في العدد الثامن والثلاثين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثامن والثلاثين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Deep Dive Into Rate Limiting
HTTP Status Codes Cheat Sheet
Introduction Into Authentication & Authorization in .NET
Introduction Into Unit Testing in .NET
ستجدون أيضًا في هذه النشرة:
فرصة تكسب 8000 جنيه لو شغال Backend
خصم يصل لـ 60% على خطط الاشتراك السنوي لفترة محدودة 🎉
الشراكات - Sponsorship
قناة التليجرام مجانية للجميع حتى يصلك كل مقال جديد
كيفية كتابة مقالات معنا في اقرأ-تِك: والمقالات تكون متاحة ومجانية للجميع ومحفوظة باسم الكاتب بكل تأكيد
كيفية الاشتراك في اقرأ-تِك من خلال InstaPay و VodafoneCash
فرصة تكسب 8000 جنيه لو شغال Backend
نافس و اطور و 🏆 اكسب 8000 جنيه!
تقدر دلوقتى تشتغل على الـ Backend Task 💻 من Code Quest و تنافس ناس تانية 🤝، هتكتسب خبرة 📚 و تبني portfolio 💼 و كمان جوايز للمراكز الاولى 🥇🥈🥉.
ماتفوتش الفرصة 🚀 وسجل دلوقتي 🖊️
Deep Dive Into Rate Limiting
الـ Rate Limiting هو واحد من أهم الـ Mechanisms اللي بنستخدمها في الـ Software Systems اللي عاوزينها تكون Scalable و Secure عشان نتحكم في كمية الـ Requests اللي ممكن النظام يعالجها في وقت معين.
الفكرة الأساسية هي إننا نحمي النظام من الـ abuse، سواء من users بيحاولوا يستهلكوا موارد زيادة أو من هجمات زي الـ DDoS.
فخلونا نتعرف أكتر عنه لإنه أحد الأجزاء الرئيسية في وقتنا الحالي خصوصا في الـ Distributed Systems وبنحتاجه احياناً واحنا بنعمل System Design ، وهنشرح برضو أنواع الـ algorithms المختلفة المستخدمة في الـ Rate Limiting وازاي تختار الأنسب لنظامك.
ليه ممكن نحتاج الـ Rate Limiting
الـ Rate Limiting مش مجرد فكرة لحماية النظام من الـ abuse، ولكنه بيقدم layers من الـ control والـ scalability اللي بتحمي الـ backend من مشاكل مختلفة زي:
الـ Overload على الـ Resources:
عدد كبير جدًا من الـ requests ممكن يسبب ضغط على الـ servers، وده بيأثر على الـ performance لكل المستخدمين.حماية الـ APIs من الـ abuse:
سواء كان هجوم DDoS أو user بيحاول يعمل spam.تحسين تجربة المستخدم:
لما نضمن إن كل المستخدمين بياخدوا نصيب عادل من الـ resources، ده بيحسن الـ UX ككل بالنسبة للمستخدمين.
المكونات الرئيسية لأي Rate Limiter
علشان نفهم الـ Rate Limiting بعمق، لازم نبص على المكونات الأساسية اللي بتكوّن أي implementation ألا وهي:
الـ Quota:
وده بيكون الحد الأقصى للـ requests اللي ممكن client يعمله خلال فترة زمنية معينة (مثلاً 100 request لكل دقيقة) وطبعًا لو حاولتوا تعملوا Integration مع Third Party APIs بتلاقوا الـ Quota دي محددة ولو بتعديها بيبدأ الـ System يبعتلك Errors على الـ Requests اللي بتبعتها.الـ Interval:
الفترة الزمنية اللي بيتم فيها تطبيق الـ limit (مثلاً دقيقة، أو ساعة).الـ Policy:
القواعد اللي بتحدد الـ behavior لما الـ limit يتعدى ودي بتختلف باختلاف نوع الـ System زي:إننا نـ Reject requests فورًا ونبعت للـ clients انهم تعدوا الـ Quota.
ممكن نعمل Delay requests بحيث يستنوا فترة أطول وبعدين يتنفذوا.
وممكن نـ Apply exponential backoff ودي باننا بنستنى بوقت Exponential مش Fixed وليكن أول مرة هنستنى ثانيتين بعدين 4 وبعدين 8 وبعدين 16.
الـ Storage:
ودي مهمة عشان نقدر نتتبع الـ requests، فالـ Rate Limiting implementation محتاج يخزن معلومات زي timestamps وعدد الـ requests. وكل ده ضروري عشان نعرف نـ Apply الـ Rate Limiting فممكن يتنفذ باستخدام:الـ In-Memory Storage: ممكن نطبق الـ Rate Limiting باستعمال Redis أو Memcached.
الـ Distributed Systems: لو الـ API بتشتغل على أكتر من server وعاوزين نـ Apply Rate Limiting على الـ API ده فمش هينفع كل Machine تخزن Local المعلومات دي فمحتاجين Distributed Systems نقدر نرجع ليه بالنسبة لكل الـ Servers اللي موجودة.
التحديات اللي بتواجهنا في تطبيق الـ Rate Limiting
تطبيق الـ Rate Limiting بيجي مع مجموعة من التحديات اللي محتاجة حلول مبتكرة زي:
الـ Sync بين الـ Distributed Systems:
لو عندنا أكتر من instance للنظام، لازم نتأكد إن كل الـ instances متزامنة في تتبع الـ requests، وده ممكن يتم باستخدام distributed storage زي Redis.الـ Rate Limiting لـ Clients مختلفين:
أحيانًا بنحتاج نعمل Rate Limiting مختلف لكل نوع من الـ clients (مثلاً user عادي vs. premium user).الـ Handling للـ Bursty Traffic:
الـ traffic مش دايمًا بيكون steady، وبالتالي لازم نختار algorithm مرن في التعامل مع النوع ده من الـ Traffic والـ Bursty traffic هو نوع من الـ traffic اللي بيحصل بشكل غير منتظم، بيظهر فيه فترات قصيرة فيها كمية requests كبيرة جدًا (burst)، وبعدها ممكن تكون فيه فترات هدوء أو requests قليلة جدًا.تجنب الـ Overhead:
تطبيق الـ Rate Limiting مش المفروض يكون عبء على النظام نفسه. وبالتالي محتاجين اختيارنا للـ efficient algorithms والـ storage solutions يكون بيقلل من الـ overhead ده.
Rate Limiting Algorithms
عشان نطبق الـ Rate Limiting في الـ Systems بتاعتنا محتاجين نفهم أن فيه أكتر من Algorithms نقدر من خلالهم نطبق المفهوم ده ، وكل Algorithm بيختلف عن التاني في بعض النقاط زي السهولة والتعقيد أو الدقة أو ضرورة الاستعمال اللي تخلينا نختاره عن Algorithm تاني.
خلونا نشوف بعض وأشهر الـ Algorithms المستخدمة في تطبيق الـ Rate Limiting:
Fixed Window Counter
Sliding Window Log
Sliding Window Counter
Token Bucket
Leaky Bucket
Fixed Window Counter
إزاي الـ Fixed Window بيشتغل:
الـ Fixed Window هو أبسط algorithm لتطبيق الـ Rate Limiting. وفكرته ببساطة هي إنه بيقسم الوقت لـ windows ثابتة (مثلاً كل دقيقة) وبيسمح بعدد معين من الـ requests لكل window.
لو العدد تعدى الحد المسموح، الـ requests الزايدة بتترفض أو على حسب الـ Policy زي ما شوفنا في المكونات الرئيسية للـ Rate Limiter.
مميزات الـ Fixed Window:
بسيط وسهل التنفيذ.
مناسب للـ use cases اللي مش بتحتاج دقة عالية في تطبيق الـ Rate Limiting.
عيوب الـ Fixed Window:
مش دقيق، خصوصًا لو الـ requests وصلت في نهاية window وبداية window جديدة فموضوع الـ Overlapping ده والدقة مش بيكون أفضل حاجة فيه.
إمتى نستخدم الـ Fixed Window:
لو كانت الـ APIs اللي شغالين عليها مش بتحتاج rate control دقيق جدًا.
Fixed Window Rate Limiter in Python
تعالوا نشوف تطبيق ده في الكود ممكن يكون شكله عامل ازاي ، والـ Code Snippet ده باستعمال ChatGPT:
Sliding Window Log
إزاي الـ Sliding Window Log بيشتغل:
الـ Sliding Window بيستخدم الـ timestamps اللي جاية مع الـ Request عشان يقدر يتتبع الـ requests ويحسب المعدل بشكل متحرك. وده بيخليه أكتر دقة من الـ Fixed Window.
بيتتبع timestamps لكل request باستخدام الـ Data Structure زي
dequeأوlist.بيحذف الـ timestamps القديمة اللي مش في الـ window الزمنية الحالية.
بيحسب عدد الـ requests في الـ window علشان يقرر إذا كان هيقبل request جديد أو يرفضه.
مميزات الـ Sliding Window Log:
أدق في تتبع الـ requests خصوصًا في حل مشكلة الـ Overlapping والـ Edges اللي شوفناها بتواجه الـ Fixed Window.
بيوفر توزيع عادل أكتر للـ requests لإنه متحرك مش ثابت فكل Request Timestamp جه بيبدأ من اللحظة دي لحد الـ Window ما تنتهي.
عيوب الـ Sliding Window Log:
أكتر تعقيد في التنفيذ.
ممكن يستهلك موارد كتير جدًا في حالة ان كان فيه High Volume Requests وده لإنه بيخزن الـ Request Timestamps عشان يعرف يحرك الـ Window ويكون دقيق.
إمتى نستخدم الـ Sliding Window Log:
لو كانت الـ APIs اللي شغالين عليهابتحتاج rate control دقيق جدًا وفي نفس الوقت مش High Volume.
Sliding Window Log Rate Limiter in Python
تعالوا نشوف تطبيق ده في الكود ممكن يكون شكله عامل ازاي ، والـ Code Snippet ده باستعمال ChatGPT:
تقدروا دلوقتي تشتركوا في اقرأ-تِك بخصم يصل لـ 60% لفترة محدودة وتنضموا لمجتمع مهتم بالقراءة في هندسة البرمجيات (يعني بـ 30 جنيه بس) 🎉
وتستمتعوا بحرية كاملة في قراءة المقالات في مواضيع مختلفة بجودة عالية زي:
Data Structure & Algorithms , System Design , Distributed Systems , Micro-Services, Clean Code, Refactoring, Databases , Web Development, DevOps وغيرهم كتير باللغة العربية!
بالاضافة لمحتوى ورقة وقلم اللي بنشرح فيه مفاهيم برمجية بطريقة سهلة وباستعمال صور توضيحية 🚀
ولو فيه مشاكل في الدفع الأونلاين فمتاح دلوقتي الاشتراك من خلال InstaPay و VodafoneCash 💪
تقدروا تتواصلوا معانا من خلال البريد الالكتروني contact@eqraatech.com 😍
ماتنسوش تستعملوا Coupon: WHITEFRIDAY50 ! 🚀
HTTP Status Codes Cheatsheet
اتكلمنا قبل كدا عن ايه هي ال Http status codes وليه مهمة في تصميمنا لـ APIs , النهارده هنتكلم عن أشهر 15 status code منهم وعاملين cheat sheet بيهم تقدر تساعدك في انك تفتكر استخداماتهم سريعًا في وقت الشغل.
Success Codes 2xx
1- 200 OK
يعبر عن تنفيذ ال request و ايصاله لل client بنجاح
2- 201 Created
يستخدم هذا الكود ليعبر عن إنشاء resource جديد بنجاح
و يستخدم مع ال POST Method ويمكنك أن تعيد معه أيضَا ال resource ID
3- 202 Accepted
يعبر عن قبول الطلب بنجاح ولكنه لا يزال قيد التنفيذ على ال server , ويمكنك أن تستخدم هذا الكود حينما يفوض السيرفر الطلب لسيرفر أخر أو background task قد تستغرق وقتًا
Redirect Codes 3xx
4- 301 Moved Permanently
عندما تقوم بتغيير ال URL يمكنك أن تستخدم هذا الكود لتوضح أنه قد تم نقل الAPI لعنوان جديد بدلاً من العنوان المستخدم في هذا الطلب وفي ال response body تضع العنوان الجديد ليتم استخدامه فيما بعد.
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-location
Content-Type: text/html
5- 302 Found (Moved Temporarily)
يستخدم هذا الكود في حالة تغيير عنوان ال API لعنوان آخر بشكل مؤقت لعمل صيانة أو تحديث لل API علي هذا العنوان, يقوم ال client بعمل redirect للعنوان المؤقت الجديد و لكن فيما بعد يستطيع العودة لاستخدام ال URL القديم.
6- 304 Not Modified
يستخدم هذا الكود في حالة ال conditional GET حيث يتم إرسال if-modified-since بداخل الـ request headers فيجيب الserver بهذا الكود كي يعلم ال client بأن الـ resource لم يتغير ويمكن لل client استخدام النسخة التي لديه في الـ cache.
Introduction Into Authentication & Authorization in .NET
لما بنبني تطبيق فيه بيانات حساسة أو مهم إننا نحميها، لازم نتأكد من هوية المستخدم (Authentication) وبعدين نحدد إيه الصلاحيات المسموح ليه يعملها (Authorization). لو هنتكلم عن ASP.NET Core، الإطار ده بيقدم أدوات مرنة وبسيطة علشان تدير الأمور دي.
إيه الفرق بين Authentication و Authorization
الـ Authentication: ده ببساطة التحقق من هوية المستخدم. يعني لما المستخدم يدخل على التطبيق، بنعمل تحقق من بياناته زي البريد الإلكتروني وكلمة السر عشان نتأكد إنه الشخص ده هو اللي بيقول إنه هو.
الـ Authorization: ده بيكون بعد ما نتأكد من هوية المستخدم. الهدف من Authorization هو تحديد إيه الحاجات اللي يقدر المستخدم يوصل ليها أو يعملها في التطبيق بناءً على صلاحياته.
تطبيق الـ Authentication in .NET CORE
في ASP.NET Core، فيه كذا طريقة ممكن تستخدمها علشان تعمل Authentication للمستخدمين، أشهرهم JWT Tokens. ده بيكون مفيد خصوصًا لو بتبني REST API لأن JWT بيقدم طريقة آمنة وسهلة للتواصل بين العميل والخادم.
استخدام JWT في Authentication:
هنا هتتعلم إزاي تجهز JWT في تطبيقك علشان تعمل التوثيق:
أول حاجة، هتقوم بإعداد خدمة Authentication في ملف Startup.cs عشان تستخدم JWT Bearer Authentication.
في الكود ده: بنحدد الطريقة اللي هيتم بها التحقق من التوكن باستخدام JWT Bearer وبنضيف إعدادات التحقق زي التحقق من Issuer و Audience وأيضًا التحقق من صلاحية التوكن نفسه.
الشراكات - Sponsorship
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship وتقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 🚀
لا تدع شيء يفوتك!
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
Introduction Into Unit Testing in .NET
اختبار الوحدات (Unit Testing) هو عملية اختبار جزء صغير من الكود لوحده عشان نتأكد إنه شغال صح. الجزء ده ممكن يكون Function أو Component صغير. الفكرة إنه قبل ما ندمج الكود مع باقي التطبيق، نتأكد إن كل جزء شغال بشكل مستقل وبلا مشاكل.
الهدف من Unit Tests هو التأكد من إن الكود مش هيعمل مشاكل في مراحل التطوير أو لما نضيف ميزات جديدة.
أهمية Unit Testing
اكتشاف الأخطاء بسرعة: الـ Unit Tests بتساعدك تكتشف الأخطاء في الكود بسرعة قبل ما تكبر أو تؤثر على باقي أجزاء التطبيق. يعني لو في حاجة غلط، هتلاقيها بدري.
تسهل التعديل والإضافة: مع وجود اختبارات، تقدر تضيف مميزات جديدة أو تعدل على الكود من غير ما تخاف إن الحاجات التانية تتكسر. ده بيخلي التغيير أسهل وأنت مطمئن.
تحسين التوثيق: الاختبارات بتشرح الكود بشكل عملي. لو حد شاف الاختبار، هيفهم إزاي الكود بيشتغل وبيكون المتوقع من كل جزء. الاختبار بيبقى زي وثيقة حية للكود.
زيادة الثقة في الكود: لما تكتب اختبارات للوحدات، بيزيد استقرار الكود. ده بيخليك أكتر ثقة إن الكود هيشتغل زي ما هو مفروض في كل وقت.
أدوات الـ Unit Testing في الـ .NET
في أدوات كتير ممكن تستخدمها لاختبار الوحدات في .NET. هنا هنتكلم عن أكتر الأدوات شهرة:
xUnit: دي واحدة من أشهر الأدوات لاختبار الوحدات في .NET. سريعة وسهلة، وكمان بتدعم خاصية تنفيذ الاختبارات في وقت واحد (التوازي)، يعني لو عندك اختبارات كتير، تقدر تنفذهم في نفس الوقت.
NUnit: أداة قوية تانية مشهورة في عالم .NET. بتتميز بمرونتها وسهولة استخدامها، وبتدعم أكتر من نوع لاختبار الوحدات.
Moq: دي مكتبة عشان تقدر تعمل Mock Objects. لو عندك مكونات خارجية مش هتقدر تستخدمها أثناء الاختبار (زي قواعد البيانات أو API’s)، تقدر تستخدم Moq عشان تحاكيها وتختبر الكود من غير ما تعتمد عليها.
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
