VOL62: Understanding API Idempotency & API Authentication Methods
أهلًا وسهلا بكم في العدد الثاني والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثاني والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
API Authentication Methods
Idempotency in APIs
فرصة توظيف مميزة Hybird بمرتب يوصل لـ 35,000 جنيه 🚀
How Uber Serves Over 40 Million Reads Per Second
Star Method for Behavioral Interviews
الإصدار الأول من مدونات فطين في تصميم النظم
API Authentication Methods
أثناء تعاملنا مع ال APIs بنحتاج نعمل User Authentication واللي هي عبارة عن عملية التحقق من هوية المستخدم اللي باعت ال Request, ودا جانب هام جدُا في حماية الـ API وكذلك خصوصية وأمان المستخدمين.
فورقة وقلم و تعالوا نتعرف على أشهر 5 طرق من ال User Authentication Methods. 🚀
Basic Authentication
دا أبسط نوع وفيه بنبعت اسم المستخدم وكلمة المرور في ال Request في صيغة Base64 , طبعًا النوع دا منخفض الأمان ومش بنستخدمه في الـ Production Environment إلا علي HTTPS Connection, لأن ال Base64 Encoding بيتحل بأي Decoder على الإنترنت فلو ال Eequest اتعرض ل Eavesdrop Attack يقدر المهاجم بسهولة يعرف بيانات المستخدم.
الاستخدام المناسب:
مناسب للاستخدام في وقت التطوير أو الـ Testing
ممكن نستخدمه في التطبيقات الداخلية واللي ضامنين إنها على شبكة آمنة.
GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=API Key Authentication
ال API Keys عبارة عن مفاتيح أو "رموز تعريف" بيصدرها ال API لل Clients ودور ال Client أنه يبعتها مع كل Request لل API كوسيلة تحقق من هوية المستخدم. ال Client ممكن يبعتها ك Query String أو يحطها في ال Request Header أو حتي ك Cookie.
وزي ال Basic Authentication لازم نستخدمه علي HTTPS Connection لأن لو أي حد عرف ال API Key هيقدر ينتحل شخصية ال Client ويستعمل ال API باسمه.
الاستخدامات المناسبة:
بتكون في بيئات التطوير و الاختبار أو في التطبيقات الداخلية
ممكن نستخدمه في الـ Production ولكن مع وسائل أخري نزود بيها معامل الأمان.
ونلاحظ واحدة من أهم عيوب الـ API Key إنه مش بيدي User-Specific Permissions لأنه مصمم بالأساس عشان يستخدم بين ال Apps أو ال Services وبعضها.
Idempotency in APIs
عند تصميم واجهات برمجة التطبيقات (APIs)، يُعد مفهوم الـ Idempotency من المفاهيم المُهمة لضمان استقرار الأنظمة و سلامة بياناتها، لا سيما في الأنظمة الموزعة حيث ترتفع احتمالية تكرار الطلبات نتيجة لمشاكل الشبكة Network Failures أو إعادة المحاولة التلقائية Retries.
في هذا المقال سنستكشف مفهوم الـ idempotency، أهميته في تصميم الـ APIs، الآليات المتبعة لتحقيقه و متى يُستخدم.
ما هو الـ Idempotency؟
الـ Idempotency هو مفهوم مُستعار من الرياضيات، و يعني أن تنفيذ عملية مُعينة مرة واحدة أو عدة مرات سيُعطي نفس النتيجة. في سياق الـ APIs هذا يعني أنه يُمكن تنفيذ نفس الطلب Request عدة مرات دون أن يُؤثر ذلك على حالة النظام أو ينتج عنه آثار جانبية غير مرغوب فيها.
أهمية الـ Idempotency في الـ APIs
أحيانا يفقد العميل تأكيد نجاح العملية بسبب مشاكل الشبكة فيُعيد إرسال الطلب. لذلك يجب أن يتحمل النظام تكرار نفس الطلب دون تكرار التنفيذ.
بعض الأنظمة تعتمد على إعادة المحاولة تلقائيا عند فشل الطلب مؤقتا مما يجعل دعم الـ idempotency ضروريا لتفادي تكرار غير مرغوب فيه.
في العمليات الحساسة كتنفيذ المعاملات المالية قد يؤدي تكرار التنفيذ إلى أخطاء خطيرة إن لم يُراعى مفهوم الـ idempotency.
في الأنظمة الموزعة تكرار الطلبات أمر شائع بسبب الأعطال الجزئية، لذلك يُدعم الـ idempotency موثوقية النظام و سلامة بياناته.
فرصة توظيف مميزة Hybird بمرتب يوصل لـ 35,000 جنيه 🚀
لو بتدور على شغل حقيقي يطور ويقيّم مهاراتك بدل الـ CV، يبقى لازم تشارك في الـ Hiring Quest الجديدة من CodeXQuests 👇
💼 Backend Developer (Mid-Level) @ 4Sale – Hybrid
4Sale هي واحدة من أقوى منصات البيع والشراء في الكويت وعايزين يضموا لمهندسيهم شخص شاطر في:
🔸 Laravel, Go
🔸 MySQL , PostgreSQL
🔸 Docker, REST APIs, CI/CD
المميز في الـ Hiring Quest:
✅ مفيش مقابلات مملة
✅ مفيش تصفية للـ CVs
✅ الفرصة بتتحدد على حسب شغلك الفعلي
✅ أفضل المشاركين هيتراجع شغلهم وفرصة التوظيف حقيقية 100%
📅 سجل مجانًا قبل ما التسجيل يقفل خلال يومين!
ابدأ المشوار، وورّيهم شغلك وفي نفس الوقت ابني CV عملي من مشاريع حقيقة! 💪
How Uber Serves Over 40 Million Reads Per Second
شركة Uber بتستعمل Docstore وهو عبارة عن قاعدة البيانات الموزعة بتاعتهم واللي مبنية على MySQL و Docstore بتخزن عشرات الـ PetaBytes من البيانات وبتخدم عشرات الملايين من ال Requests في الثانية.
ودي واحدة من أكبر محركات قواعد البيانات عند Uber واللي بتستخدمها كتير من الـ Microservices في كل القطاعات التجارية أو اللي بنسميها Business Verticals عندهم.
والكلام ده من ساعة ما بدأت في 2020، عدد المستخدمين وحالات الاستخدام بتاعت Docstore في ازدياد، وكمان حجم الطلبات والبيانات في زيادة.
المطالب المتزايدة من القطاعات التجارية واحتياجاتهم بتضطر تقدم Microservices معقدة جدًا. وبالتالي، التطبيقات بتطلب زمن استجابة قليل Latency، وأداء عالي High Performance، وقابلية توسع من قاعدة البيانات Scalability، وفي نفس الوقت الكلام ده بيولد Workloads وأحمال عالية.
التحديات
معظم الـ Microservices في Uber بتستخدم قواعد بيانات مدعومة بتخزين على الـ Disk عشان تحافظ على البيانات والـ Durability بتاعتها. ومع ذلك، كل قاعدة بيانات بتواجه تحديات في خدمة التطبيقات اللي بتحتاج زمن استجابة قليل وقدرة توسع عالية.
ده وصل لدرجة الأزمة لما في حالة من الحالات طلبت معدل قراءة أعلى بكتير من أي مستخدم حالي. وكان ممكن Docstore تلبى احتياجاتهم لأنها مدعومة بـ NVMe SSDs، ,اللي بدورها بتوفر زمن استجابة قليل ومعدل نقل عالي. بس استخدام Docstore في الحالة دي كان هيبقى مكلف جدًا وكان هيطلب كتير من التوسع Scalability والتحديات التشغيلية اللي هي الـ Operational Challenges.
فقبل ما ندخل في التحديات، خلينا نفهم الـ High-Level Architecture لـ Docstore.
Docstore Architecture
هنلاقي أن Docstore متقسمة بشكل رئيسي لثلاث أجزاء أو طبقات Layers :
1- الـ Stateless Query Engine Layer
2- الـ Stateful Storage Engine Layer
3- الـ Control Plane
وللتذكير Stateless من اسمها يعني مش مسئولة عن الاحتفاظ بأي State نهائيًا أو معلومات ، بينما الـ Stateful فهي بتحتفظ بالـ State أو بعض المعلومات عشان تستفيد منها في أداء شغلها.
واحنا هنركز كلامنا فقط على الجزئين الأول والثاني من الـ 3 طبقات دول.
الـ Stateless Query Engine مسئول بشكل أساسي عن الـ Query Planning والـ Routing والـ Sharding والـ Schema Management وكمان الـ Node Health Monitoring والـ Request Parsing والـ Validation والـ AuthN/AuthZ.
والـ AuthN اللي هي اختصار لـ Authentication والـ AuthZ اختصار للـ Authorization.
بينما الـ Stateful Storage Engine مسئول بشكل أساسي عن تحقيق الـ Consensus من خلال Raft وده طبعًا بيتم استعماله بشكل أساسي في النظم الموزعة لضمان تحقيق الـ Replication بكفاءة واتساق البيانات أو ما يعرف بالـ Consistency.
والـ Storage Engine كذلك مسئول عن الـ Replication والـ Transactions والـ Concurrency Control والـ Load Management.
وزي ماحنا شايفين في الصورة احنا عندنا أكتر من Partition كل جزء بيكون عبارة عن بعض الـ MySQL Nodes مدعومة بـ NVMe SSDs واللي قادرة على انها تتحمل الأحمال الثقيلة في القراءة والكتابة Heavy Read and Write Workloads.
البيانات متقسمة على أكتر من جزء وكل جزء بيكون فيه Leader واحد , و 2 Follower وطبعا من خلال استعمال Raft لتحقيق الـ Consensus.
التحديات لما الخدمات بتطلب قراءات بزمن استجابة قليل وبمعدل عالي:
سرعة استرجاع البيانات من الـ Disk ليها حد: في حد لتحسين الـ Data Models والـ Queries عشان نحسن زمن الاستجابة والأداء. ولكن بعد كده، هنوصل لحيطة سد وده لان تحسين الأداء أكتر من كده مش هيبقى ممكن.
التوسع الرأسي Vertical Scaling: تخصيص موارد أكتر أو استخدام أجهزة أفضل هيكون برضو ليها حدود واللي وقتها هيكون محرك قاعدة البيانات بنفسه هو الـ Bottleneck.
التوسع الأفقي Horizontal Scaling: تقسيم البيانات على مزيد من الأجزاء ممكن يساعد بشكل ما أو بآخر ولكن برضو هيكون محدود وهيبقى عملية معقدة وطويلة. وده لاننا لازم نضمن استمرارية الـ Durability والـ Resilience للبيانات من غير أي Downtime يحصل. وكمان الحل ده مش بيحل المشكلة بالكامل وهيعرضنا لمشاكل تانية زي الـ Hot Keys/Shards/Partitions.
اختلال التوازن بين الـ Requests: كتير من الأحيان معدل طلبات القراءة بيكون أعلى بكتير من الكتابة. في الحالات دي، الـ MySQL Nodes الأساسية بتكافح عشان تواكب الحمل الثقيل اللي متعرضة ليه وده بيأثر على زمن الاستجابة Latency.
التكلفة: التوسع الرأسي والأفقي لتحسين زمن الاستجابة مكلف على المدى الطويل. والتكاليف دي بتتضاعف 6 مرات عشان تتعامل مع كل من الـ 3 Nodes في الـ Regions المختلفة. وكمان، التوسع مش بيحل المشكلة بالكامل.
عشان نحل المشكلة دي، الـ Microservices بتستخدم الـ Caching. وفي Uber بيستعملوا Redis™ كـ Distributed Caching ، ومن أشهر الـ Design Patterns اللي بيتم تطبيقها في الـ Microservices هي الكتابة لقاعدة البيانات والـ Cache في نفس الوقت وتقديم طلبات القراءة Read Request Serving من الـ Cache لتحسين زمن الاستجابة Latency. بس برضو النموذج ده ليه بعض التحديات:
كل فريق لازم يخصص ويـ Maintain الـ Cache Redis الخاص بيه للـ Services بتاعته.
الـ Cache Invalidation Logic متنفذ بشكل لا مركزي في كل الـ Microservices لان كل فريق هيكون مسئول عنه.
في حالة حدوث مشكلة في الـ Region وحصل Failover، الـ Services لازم يا اما تحتفظ بنسخ الـ Cache عشان تكون مستعدة لأي عمليات قراءة تحصل أو تتحمل زمن استجابة أعلى Higher Latencies لغاية مالـ Cache يكون مستعد في الـ Regions التانية اللي هيحصلها الـ Failover.
الفرق الفردية بتبذل مجهود كبير في تنفيذ الـ Caching Solutions الخاصة بيهم مع قاعدة البيانات. ولكن أصبح من الضروري إننا نلاقي حل أفضل وأكثر كفاءة عشان يـ Handle الطلبات بزمن استجابة قليل، ويكون سهل الاستخدام ويزيد كمان من إنتاجية المطورين.
خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :
Introduction Into System Design
How Uber Serves Over 40 Million Reads Per Second
How Discord Stores Trillions of Messages
Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution
Unlocking Notion's Power - The Data Model Explained
How Shopify Mitigates Deadlocks in High Concurrency Environments
How LinkedIn Improves Microservices Performance With Protobuf
How Figma Secures Internal Web Applications
How GitHub Improves Reliability of Code Push Processing
How Meta Leverages AI For Efficient Incident Response
How Stripe Architected Massive Scale Observability Solution on AWS
Change Data Capture at Pinterest
How Canva Built Scalable and Reliable Content Usage Counting Service
How Netflix Migrates Critical Traffic at Scale With No Downtime
How Slack Handles Billions of Tasks in Milliseconds
How YouTube Supports Billions of Users With MySQL
System Design Comprehensive Guide
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
Star Method for Behavioral Interviews
الـ Star Method هي واحدة من أكثر الطرق الفعالة في تحسين التواصل خلال الانترفيو خصوصًا الـ Behavioral Interviews.
الـ Interview بيبقي عبارة عن أسئلة من جهة الـ Interviewer وكتير منها أسئلة مفتوحة يعني Open-Close لأنه محتاج يعرف أكتر عنك وعن سلوكك
لكن البشر مش زي الكمبيوتر مستنين إجابات علي هيئة Bullet Points لأنه غالبًا هينسوها قبل ما تكملها حتي.
فلو سألتك ازاي بتواجه الضغط في الشغل أو الكلية ؟
وأنت ابتديت تقولي إجابة محفوظة من الـ Internet عن تقسيمك للمهام و تنظيم الوقت هاخد انطباع إنك حافظ إجابة ما بس مفيش دليل إنك حقيقي بتعمل دا.
علي عكس ما تحكيلي موقف حصل وتبين اتعاملت ازاي فيه باستخدامك لتقسيم المهام وتنظيم الوقت يمكن كمان تكون عملت Delegation أو استخدمت مهاراتك القيادية!
وقتها أنا هعرف عنك أكتر و الانطباع هيكون أحسن بمراحل.
فالأفضل دايمًا إنك تجاوب علي هيئة "قصة" وبما إن مش كلنا عندنا مهارة ال Storytelling فال STAR Formula بتساعدك ترتب إجابتك في شكل قصة.
وتقدر تطبقها بإنك بتكتب إجاباتك الطبيعية علي السؤال و بعدين تعدلها بحيث:
تبتدي بتوضيح الموقف Situation
توضح المهمة اللي كانت مطلوبة منك في الموقف دا Task
تشرح خطوات حلك للمهمة دي Action
توضح ال Result الناتجة عن ال Actions اللي خدتها
يفضل دايمًا تحتفظ بملف تكتب فيه أهم أسئلة الـ Behavioral Interviews و تحاول تجاوب علي الاسئلة دي باستخدام ال STAR Formula وراجع علي إجاباتك وحسنها لحد ما توصل لقصة قصيرة و فعالة بتعكس مهاراتك الحقيقة في كل موقف.
وعشان نتدرب افتح ملف و جاوب علي ال 3 أسئلة دول:
احكيلنا عن أحسن مشروع برمجي اشتغلت عليه؟
احكيلنا عن موقف اتعاملت فيه بسرعة بديهة وفي وقت ضيق؟
قولنا عن مرة عملت خطأ في مشروع واتعاملت ازاي؟
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
