VOL58: API Gateway in Microservices Architecture
أهلًا وسهلا بكم في العدد الثامن والخمسين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثامن والخمسين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
API Gateway in Microservices Architecture
Building a CI/CD Pipeline with Jenkins
Demystifying SQL Unique Constraints
Improving Performance of Software Systems on Backend Level
الإصدار الأول من مدونات فطين في تصميم النظم
API Gateway in Microservices Architecture
في ظل وجود الـ Monolithic Applications ، الـ Client هنا مش بيتعب في انه يتواصل مع الـ Backend وده لإنه بيكلم Service واحدة في الأول والآخر ومش محتاج يشغل باله من أي مشاكل.
ولكن مع التقدم اللي حصل وبعد هوجة و Trend الـ Microservices بيبدأ الـ Monolithic Application ده يتكسر لـ Services صغيرة كل واحدة محدودة بالـ Boundaries بتاعتها.
وبيجي هنا السؤال اللي بيحير الناس ، يا ترى هنعمل ايه في الـ Client ؟ احنا كنا بنبعت Request لمكان واحد دلوقتي محتاجين نبعت Requests مختلفة لكل الـ Services دي. طب ازاي هنـ Manage التغيير اللي ممكن يحصل لو Endpoint اتغيرت ؟ وهل مفروض الـ Client يكون Coupled بالشكل العنيف ده مع كل Service في الـ Backend لما تتغير؟
وهنا بدأنا نفكر في اننا ليه مايكونش عندنا نقطة دخول واحدة بتتحكم في طلبات المستخدمين وبتوجهها للخدمات المناسبة جوا النظام ؟ وبالتالي اقدر اغير براحتي اي حاجة في الـ Backend طالما الـ Contract أو الـ Interface اللي بيستعمله الـ Client واحد.
ومنا هنا جت فكرة الـ API Gateway ، فخلونا نشوف مع بعض ايه هو والمميزات اللي بيقدمهالنا بالورقة والقلم 🚀
API Gateway
الـ API Gateway هو نقطة دخول واحدة (single entry point) لكل الـ (requests) اللي جايه من الـ clients للـ backend. فبدل ما الـ client يتعامل مع كل service بشكل مباشر، هو بيتعامل بس مع الـ Gateway، والـ Gateway يتولى الباقي.
API Gateway Benefits
الـ API Gateway مش بس نقطة دخول موحدة للـ APIs، لكنه بيقدّم مجموعة كبيرة من المميزات:
Building a CI/CD Pipeline with Jenkins
Jenkins هو أداة مفتوحة المصدر بتساعدك تبني Pipelines عشان تختبر وتبني الكود بشكل مستمر مع كل إضافة وتتأكد من عمله بطريقة صحيحة ودي بتسمي بعملية CI/CD.
قبل ال CI/CD كان كل فرد من الفريق بيشتغل على الجزء الخاص بيه و نتجمع في النهاية ونضيف الكود على بعضه ونحل المشاكل اللي بتظهر من عدم توافقه,طبعًا دي كانت عملية مرهقة وبتكلف وقت ومجهود واحم احم أعصاب.
فعملية التكامل المستمر تقوم بتجميع الكود الجديد والقديم و تختبرهم سوا في عدة خطوات أو ما يسمى بال Pipeline عشان تتأكد من عملهم وتظهر لك المشاكل علطول فبالتالي كفريق تقدروا تشتغلوا على التعديلات وتكتشفوا مواضع الخطأ.
Pipeline Stages
Jenkins بيساعدك تكون Pipeline بسهولة عن طريق كتابة Jenkins File باستخدام لغة Groovy بتحدد فيه كل مرحلة ومفروض يعمل فيها ايه :
مرحلة البناء ( Build Stage)
مرحلة الاختبار (Testing Stage )
مرحلة النشر على السيرفر ( Deploy Stage )
مثال:
بكدا تكون عملت Automation لبناء واختبار ونشر المشروع الخاص بك بدل مع كل تغيير بدل ما تقوم بالمراحل دي كلها بشكل يدوي.
مميزات Jenkins
مفتوح المصدر ومجاني – لا يحتاج إلى ترخيص مدفوع.
دعم كبير للإضافات (Plugins) – بيتيح عدد كبير من الـ Plugins لتوسيع وظائفه (مثل دعم Git، Docker، Kubernetes، وغيرها).
بيتشغل مع معظم الأدوات مثل GitHub، GitLab، Bitbucket، Maven، Docker، وغيرها.
يدعم CI/CD بالكامل – من البناء إلى الاختبار إلى النشر.
مجتمع نشط ودعم فني قوي – بسبب شعبيته هتلاقي Community قوي وكذلك الكثير من الأمثلة والدعم
عيوب Jenkins
واجهة المستخدم قديمة: أي حد اشتغل مع Jenkins هيواجه في الأول صعوبة معرفة منين بيودي على فين, بينما الوضع أسهل في البدائل الحديثة من ناحية الـ UI
تعلم منحنى متوسط: بيحتاج شوية وقت عشان تفهمه بالكامل، خاصةً عند استخدام Jenkinsfile.
البدائل المتاحة
في بدائل أكثر حداثة ل Jenkins ولكنه لا يزال واحد من أكثر أدوات الـ CI/C استخدامًا وبالأخص للشركات اللي بتحتاج Scaling.
البدائل -مفتوحة المصدر- مثل: Openshift pipelines, Gitlab CI/CD, Circle CI
Demystifying SQL Unique Constraints
المقال ده هيكون جزء من مجموعة مقالات هنبدا نتكلم فيها عن ال Constraints وبانوعها وايه ممكن يسبب Violation ليهم وفي طرقنا نبدأ نتكلم شوية عن ازي نحافظ علي ال Data Integrity للبيانات الي بنتعامل معاها بحيث ان ده ميكونش سبب ل Logical Errors في ال Reports.
ما هي ال SQL Constraints
الـ SQL Constraints هي قواعد تُطبق على أعمدة الجداول في قواعد البيانات عشان نضمان سلامة البيانات وصحتها، وهي جزء مهم من تصميم قواعد البيانات لأنها بتساعد في اننا نتحكم في نوع البيانات المدخلة وحمايتها من الأخطاء.
الأنواع الأساسية من الـ SQL Constraints
NOT NULL: ودي بنستخدمها لو احنا عندنا Column معين او اكتر محتاجين ميتضفش فيه اي NULL Values
UNIQUE: ودي بنستخدمها عشان نتاكد ان الدتا بتاعتنا Unique ومفيش اي دتا متكررة اكتر من مرة وهنا ممكن نقول ان Column معين لازم ميبقاش فيه تكرار او ان بيانات اكتر من Column سوا مينفعش يتكرروا
PRIMARY KEY: هنا دي بتجمع مابين ال NOT NULL AND UNIQUE سوا وبنستخدمها عشان يبقي عندنا عمود / مجموعة اعمدة معينة القيم بتاعته / بتاعتهم سوا فريدة وبالتالى يكون identifier for each row
Foreign KEY: ده بنستخدمه بحيث يبقي عمود معين يربط بين الجدول الاساسي بتاعنا وجدول تانى ، زي مثلا ان يبقي عندي عمود للاصناف بستخدمه عشان اربط ما بين جدول المبيعات وجدول الاصناف
CHECK: ودي بستخدمها لو انا حبه احط شرط معين زى مثلا ان مينفعش يبقي عمود السن فيه بينات شخص سنه اقل من سن معين
DEFAULT: وده بضيفه مثلا بحيث اقول لو مفيش داتا للعمود ده ممكن اخلي القيمه بتاعته ب 1 بحيث انه ميبقاش ب NULL
ليه محتاجين نستخدم Constraints
طيب عرفنا الأنواع الأساسية لل Constraints ايه اصلا الفايدة انى استخدم ال Constrains ؟ في اكتر من سبب بيخلينا محتاجين اننا نستخدم ال constraint.
محتاجن ان الدتا بتاعتنا ميكونش فيها اي تكرار عشان كدا بنستخدم ال ( UNIQUE CONSTRAINT )
نضمن ان الدتا بتاعتنا دقيقه ومفهاش أي Redundancy
تحسين الأداء لقواعد البيانات ونخليها أكثر كفاءة في التعامل مع البيانات.
بتساعدنا نضمان إدخال بيانات تتوافق مع قواعد العمل (Business Rules) المعتمدة في المؤسسة وبالتالي تمنع إدخال بيانات غير صحيحة أو خارج النطاق المحدد.
خصم 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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
Improving Performance of Software Systems on Backend Level
سنتناول في هذا المقال بعض النصائح لتحسين الأداء في الـ Backend ، ولقد تناولنا في مقال سابق كيفية تحسين الأداء على مستوى الـ Frontend ويمكنكم مشاهدة المقال من هنا
Code & Programming Logic
وأقصد به كتابة الكود وفق المنطق السليم وتعقيد زمني سريع في بناء واختيار الخوارزميات وهياكل البيانات, فأحد أهم وظائف الـ Backend في إطار الأنظمة والتطبيقات, هو تنفيذ العمليات المنطقية في الإدارة والتنظيم للعمليات والمعلومات في النظام ، وعلى ذلك لابد من ضمان سرعة تنفيذ هذه المهام والعمليات بأفضل طريقة وأسرع مدة
Multithreaded Programming & Asynchronous Programming
من المهم جداً بالنسبة لمبرمج ال backend عن يدرك الفرق بين مفهومي ال Multithreading و ال asynchronous programming
حتى يراعي الأنسب في بناء الأنظمة والتطبيقات فتطبيقهما بشكل صحيح يحقق:
تنفيذ العمليات ومعالجة الطلبات بشكل سريع
استيعاب ضغط الطلبات وكثرتها بشكل متزامن Concurrency
فإذا كان النظام يعتمد في الأساس على عمليات معالجة تستند إلى CPU bound tasks كالعمليات الحسابية المعقدة مثلاً، فمن الأفضل أن يستخدم في هذه الحالة لغات البرمجة وأطر العمل التي تدعم الـ Multi threading.
وفي حال كان النظام يعتمد على عمليات I/o bound مثل التعامل مع الملفات او إرسال طلبات http من الأفضل الاعتماد على لغات البرمجة وأطر العمل التي تدعم ال asynchronous programming.
ولا يوجد مانع من الاستخدام الاثنين في لغة وإطار يدعم الاثنين, ولكن المشكلة ستظهر في حال فقد أحدهما مع الحاجة إليه فإن فارق الأداء سيظهر حينها بشكل ملحوظ عندما يبدأ ال requests load القوي على النظام>
وعلى الرغم من لغات البرمجة واطر العمل تدير الـ threads في وال asynchronous operation بشكل يساعد المبرمج إلى حد كبير, فإن ذلك لا يخلي بالكامل مسؤولية المبرمج في الفهم والتعامل معهما بالشكل الصحيح في الكود
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
