VOL8: Message Queue, OAuth2 and High Order Component Pattern
تخيلوا ان عندنا مطعم وشغال فيه اكتر من طباخ بيعملوا اكلات كتيرة ومتنوعة في نفس الوقت, وكل واحد شغال على الطبق اللي بيجهزه, فعشان الطباخين دول يبقى فيه بينهم تناسق وترتيب على حسب الاوردرات لازم يكون فيه نظام بيحققلهم ده فهم بيعملوا ايه ؟
بيحطوا الاوردرات كلها ورا بعض في شكل طابور، وكل طباخ بيلاقي اوردر متاح بياخد الاوردر اللي عليه الدور.
هو ده ببساطة الـ Message Queue
Message Queue
الـ Message Queue هو عبارة عن وسيلة تواصل بين الـ Services وبعضها البعض فيقدروا يتبادلوا المعلومات بشكل Asynchronous وعشان كده النوع ده من التواصل بنسميه Asynchronous Communication.
طب يعني ايه Async ؟
الـ Asynchronous Communication معناه ان الطرفين مش بيتواصلوا مع بعض In Real Time ومش محتاجين الاجابة تحصل بشكل Immediate زي الـ MailBox
Open Auth - OAuth2
بما أن الإنسان كائن ملول ومش كل شوية هنعمل حسابات جديدة بكلمات مرور جديدة علي كل موقع بندخله بنلاقي أمامنا خيار أنك تدخل ب Gmail account or Facebook or … بتختاره ومبروك وفرت ربع ساعة Sign up وإدخال معلومات لموقع جديد 🥳, لكن عمرك فكرت كمبرمج الموقع دا ازاي قدر يعملك اكونت من غير ما يعرف كلمة مرور الـ Gmail بتاعك؟
فورقة وقلم وتعالوا نعرف ما هو ال O-Auth (open authorization) Protocol السر وراء سحر ال Third Party authorization
ايه الـمشكلة اللي بيقوم الـ OAuth بحلها؟
بافتراض انك بتشترك في خدمة أو تطبيق جديد ولنقل Notion وبدل ما تعمل أكونت من الصفر بتستخدم أكونت ال Gmail بتاعك للدخول وهنا Notion كموقع مش محتاج من أكونت ال Gmail بتاعك غير بعض المعلومات زي البريد الإلكتروني وتأكيد هويتك وصورتك الشخصية عشان يحطها كصورة شخصية للاكونت بتاعك بس هيعمل دا ازاي؟
في السنين الأولى للانترنت والمواقع عشان Notion يعمل كدا كان هيطلب منك كلمة المرور الخاصة بالـ Gmail بتاعك عشان يعمل بيها Login علي ال Gmail services ويقدر يسحب البيانات دي من الاكونت وياخدها الموقع , طبعًا واضحة المشكلة!!
هو كدا عنده Access على "كل" بياناتك حرفيًا وممكن يتصرف فيها كأنه أنت!! بعد تنوع وانتشار التطبيقات اكتشفنا ان الطريقة دي مفيهاش Security بجنيه فتم الغاء التعامل بيها وظهر بدالها ال Open authorization
Higher Order Component Pattern In React
مع تزايد شعبية React كأداة رئيسية في بناء تطبيقات الويب المعاصرة، يبرز نمط Higher Order Component كاستراتيجية فعالة لتعزيز قابلية التوسيع وتحسين إعادة استخدام المكونات بكفاءة. يُقدم هذا النمط منهجية فريدة للتعامل مع المنطق المشترك والمتكرر في تطبيقات React. في هذا المقال، سنتعرف على هذا النمط، مستكشفين كيف يعمل، وكيف يمكن استخدامه لتحسين بنية تطبيقات React.
تعريف نمط التصميم HOC
نمط التصميم Higher Order Component (HOC) في React هو طريقة تسمح بإضافة وظائف أو سلوكيات جديدة إلى المكونات دون تعديل تركيبتها الأساسية. HOC هو في الأساس وظيفة (Function) تأخذ مكون كمدخل (Argument) وتُعيد مكون جديد مُحسّن. هذا النمط يُمكِّن المطورين من إنشاء مكونات معدلة أو مُعززة عن طريق إضافة منطق جديد أو سلوكيات مشتركة، مما يُقلل من التكرار في الشيفرة ويُحسّن قابلية الصيانة والاختبار.
Code Comments in a Nutshell
ورقه وقلم و خلينا نتكلم عن توثيق المشروع الخاص بك (Documentation)، أولاً وقبل كل شيء، فيه طرق كتير علشان تساعدك توثق مشروعك البرمجي منها (READMEs, Code Comments, How-to guides, tutorials, getting started guide, API documentation) وغيرهم كتير. لكن خلينا النهارده ندردش شويه عن نوع واحد وهو الجزء اللي بيكون مخفي بين سطور الكود، واللي ممكن يكون سر نجاح أو فشل المشروع في التواصل مع المطورين الآخرين وهو Code Comments.
الهدف الرئيسي من الCode Comments
الهدف الرئيسي من ال Code Comments هو إنارة الطريق للي هيشوف الكود بعدك، يعني تخليه يفهم ليه اخترت الطريق ده او ليه استخدمنا طريقه معينه او الجورزم معين مش ازاي نفذته , لان ببساطة إجابة سوال ازاي نفذت الفكره أنت مجاوب عليه في الكود 😄( ولا أنت مش كاتب Clean Code👀).
مثال:
- ❌ looping over the list to print items
- ✅ looping over the list to filter and display only relevant data