VOL61: What is gRPC? A Modern Alternative to REST APIs
أهلًا وسهلا بكم في العدد الأول والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الأول والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
What is gRPC? A Modern Alternative to REST APIs
RESTful APIs Design Principles
How GitHub Improves Reliability of Code Push Processing
UUID Performance Nightmare at Scale
الإصدار الأول من مدونات فطين في تصميم النظم
What is gRPC? A Modern Alternative to REST APIs
الـ gRPC هي اختصار لـ Google Remote Procedure Call وهي تكنولوجيا بتخلي الـ Service تقدر تنادي الـ function اللي موجودة في Service تانية كأنها بتناديها عادي كـ Function Call، حتى لو الـ Service التانية دي مكتوبة بلغة برمجة مختلفة ومش موجودة على نفس الـ Machine!
بشكل أبسط يعني لو عندنا Service مكتوبة بـ Java و Service تانية مكتوبة بـ Python، نقدر نخلي الـ Python ينادي Function في الـ Java بسهولة.
في الـ Microservices لو كل Service بدأت تعمل Generate لـ Client Library عشان الـ Services التانية تستخدمها ، هنضطر نعمل Client Library بلغات برمجة مختلفة على حسب الـ Services التانية ، وده مش حاجة منطقية! وهنا بتيجي ميزة الـ gRPC في انها بتوفر Unified Framework وكمان Language Agnostic ، فاحنا بنقول ده الـ proto اللي عاوزها والـ Client بيستعمل الـ gRPC Framework في انه يبعتلنا الـ Proto ويستقبل الـ Proto كـ Response وخلاص.
الـ gRPC بيبدأ من الـ Schema ، بـ Define الـ APIs بتاعتي وبقول دول الـ Functions اللي عندي أو الـ Contracts بتاعتي ، وبحدد الـ Request/Response كـ proto واللي هي اختصار للـ Protocol Buffer.
الـ gRPC شغال إزاي؟
الـ gRPC بيعتمد على حاجة اسمها Protocol Buffers (Protobuf). دي زي JSON كده، بس أخف وأسرع، بتستخدمها علشان توصف شكل البيانات اللي رايحة واللي جاية.
فبدل ما نبعت JSON كبير ومليان تفاصيل، بنكتب ملف .proto نعرف فيه الـ Message والـ Functions اللي عاوزين نتبادلها بين الـ Client والـ Server.
فانا بقول عندي service x بتشمل الـ functions الآتية وكل function بتستقبل proto request وبترجع proto response وخلاص كده ، فمش محتاج باه احدد الـ params دي هتيجي من الـ query , url , body والـ complexity بتاعة الـ REST
مثال سريع على ملف .proto:
RESTful APIs Design Principles
ورقة وقلم وتعالوا نتكلم عن الأساسيات الخمسة لتصميم ال RESTful APIs زي ما الكتاب بيقول
1. Stateless
كل HTTP Request من ال Client للـ Server مفروض يكون مستقل تمامًا، ويحتوي على جميع المعلومات اللازمة لفهم الـ Request, وبالتالي ال Server مش محتاج يحتفظ بال session بين كل طلب والثاني ودا يفيدنا جدًا في إنه يجعل النظام أبسط وأسهل في التوسع.
مثال:
لو بعت Request إلى /orders/123، لازم الطلب يحتوي على ال Auth Token أو بيانات المصادقة، لأن ال Server لا يحتفظ بمعلومات عن مين هو ال Client.
2. Cacheable
من المفترض أن تٌصمم الـ API Responses بحيث توضح هل يمكن تخزينها مؤقتًا (Cache) أم لا. ودا بنستخدمه في تقليل الحمل علي ال Server وتحسين ال Response time فكثير من الطلبات قابلة للتخزين المؤقت لأن معدل تغير البيانات مش بالسرعة الكبيرة بين كل طلب والثاني.
مثال:
ال Response من طلبك ل /products ممكن نخزنها في الذاكرة المؤقتة لمدة محددة وبالتالي خلال تصفحي هقلل عدد الطلبات للـ Server عشان أحصل على نفس البيانات.
3. Uniform Interface
التواصل بين الـ Client و الـ Server يجب أن يتم عبر واجهة واحدة موحدة وبسيطة. يعتبر دا أهم مبادئ تصميم ال RESTful APIs و بنلاحظ دا في أن كلنا بنصمم و بنتعامل مع ال APIs بنفس ال URIs وبنستخدم ال HTTP Methods بنفس الطريقة بغض النظر عن تنظيمنا لل Application أو نوع ال Server, دا بيسهل ويسرع عملية تعلم و صنع ال API وكذلك استخدامها
4. Code-on-Demand
ممكن ال Server يبعت كود قابل للتنفيذ (مثل JavaScript) يقدر ال Client بتشغيله مؤقتًا مش بس بيانات.ودي تعتبر من المبادئ الاختيارية في التصميم واللي مش بنلجأ ليها كثير كون إرسال وتنفيذ كود علي ال Client تعتبر عملية غير سلسة وقد تكون في بعض الأحيان غير آمنة.
مثال:
عند زيارتك لصفحة منتج يقوم ال Server بإرسال كود Javascript يعرض عد تنازلي لعروض الخصم على المنتج بحسب بيانات المنتج.
5. Layered System
يمكن للـ API أن يكون خلف طبقات متعددة (مثل خوادم وسيطة، Proxy Gateways،) دون معرفة ال Client بذلك. بكدا الClient بيتواصل فقط مع "الواجهة" وميعرفش اللي بيحصل وراء الكواليس. دا بيتيح لينا ميزات مختلفة زي سهولة التواصل وسهول التوسع عن طريق إضافة طبقات مختلفة مع الاحتفاظ بنفس طريقة التواصل .
How GitHub Improves Reliability of Code Push Processing
كلنا عارفين GitHub وأهميته في كونه منصة لاستضافة الـ Code Repositories باستخدام Git Version Control. و GitHub بيتم استعماله على نطاق واسع من قبل المطورين لإدارة مشاريعهم البرمجية، والتعاون مع فرق العمل، واستضافة مشاريع مفتوحة المصدر.
بالإضافة إلى توفير أدوات لتتبع المشاكل، وإدارة المشاريع، وكمان فيه مميزات تانية زي GitHub Actions والي بتمكن المطورين من تنفيذ عمليات CI/CD.
وفي السنوات الأخيرة، أصبح GitHub جزء لا يتجزأ من عملية تطوير البرمجيات العالمية، مع مجتمع يضم ملايين المطورين والشركات.
Enhance the Reliability and Efficiency of Code Pushes
قامت GitHub بعمل Rollout لأكتر من Technical Upgrade وده بهدف التحسين من الـ Reliability والكفاءة الخاصة بعملية الـ Code Pushes.
والـ Code Pushes هي أكيد واحدة من العمليات الشائعة والمتكررة اللي كلنا بنقوم بيها بشكل دوري. والحركة اللي عملوها دي هدفها معالجة أي مشاكل محتملة وانهم يوفروا تجربة أكثر سلاسة لأي حد بيعمل Code Push على GitHub.
فتعالوا نشوف ايه التحسينات اللي فريق مهندسين GitHub خدها عشان يحسن من كفاءة عملية الـ Code Push.
ايه اللي بيحصل لما بنعمل Code Push ؟
الاجابة المنطقية واللي كتير عارفينها ان الـ Repository بالتأكيد هيبقى فيها الـ Updates بتاعتي اللي انا عملتلها Push , ولكن رغم ان الكلام ده صحيح الان ان فيه مجموعة من العمليات اللي بتحصل كمان واحنا ممكن مانكونش على دراية كاملة بيها.
ودي بعض الأمثلة للعمليات اللي بتحصل لما بنعمل Push لأي Code على GitHub:
بيحصل مزامنة بين الـ Pull Requests وبعضها , وده معناه ان الـ Diffs والـ Commits اللي موجودين في الـ Pull Request بيتأثروا بالتغييرات اللي بتطرأ من الـ Code Push اللي عملناه
بيتم عمل Dispatching للـ Push Webhooks
بيتم عمل Triggering للـ Workflows
لو عملنا Push لـ App Configuration File , التطبيق هيتم عمل ليه Installing بشكل اوتوماتيك على الـ Repository
بيتم نشر الـ GitHub Pages
وغيرهم كتير من العمليات اللي بتحصل واحنا ممكن ما نكونش على دراية كافية بيها.
فلما بتيجي تعمل Code Push بيكون فيها ما يقرب من 60 عملية مختلفة من الـ Logic مرتبطين تقريبًا بحوالي 20 Service مختلفة وكلهم بيحصلهم Run بعد ما تعمل Code Push وده طبعا في الـ Monolith GitHub اللي هم مصممينه.
فزي ما احنا شايفين احنا عندنا Monolith Application وفيه Sequential Operations بتحصل تباعًا مع كل Code Push بيتم.
ايه هي المشاكل ؟
المشكلة ان لحد قبل ما يحصل أي تحسين في الـ System ده , كان الموضوع كله قايم على Background Job ضخمة جدًا , كل لما يحصل Notify للـ Ruby and Rails GitHub Monolith بأن حصل عملية Code Push, كان بيحصل عملية Enqueue لـ Job ضخمة اسمها RepositoryPushJob , والـ Job دي هي اللي كان فيها الـ Logic الضخم اللي اتكلمنا عنه واللي فيه أكتر من 60 Logic.
وبالتأكيد مع وجود كمية كبيرة من الـ Processing Logic اللي شايلاه وحجمها وتعقيدها , كل ده كان بيؤدي إلى مشاكل كتيرة.
وده شكل الـ Sequential Operations اللي بتتم بعد ما يحصل Code Push.
Enormous Job and Retry
حجم الـ
كتابة الـ Push Records في الـ Database واللي هينتج عنه بالتأكيد Duplicated Entries
ارسال الـ Push Webhooks هي عملية Time Sensitive والمفترض اننا منحاولش نعيد تنفيذها لفترة طويلة بعد ما الـ Code Push يكون حصل
مش حاجة كويسة اننا نبعت برضو أكتر من مرة نفس الـ Webhook
Tightly Coupling and Catching Failures
بعض الـ Processing Logic اللي موجود قدر انه ينجو من الـ Failures اللي ممكن تحصل , ولكن احيانا كتير بسبب طبيعة الـ
Bad Latency
زي ما شوفنا بسبب الاعتمادية العالية بين الـ Steps وبعضها لاننا شغالين Sequential , فأصبح دلوقتي لازم على كل الـ Steps اللي موجودة في الآخر انها تستنى كل اللي قبلها يتنفذ عشان تتنفذ , ومع الـ Scale أكيد كل ده كان بيقدم Latency بتوصل احيانا لـ ثانية وأكتر وده طبعا بيقابل المطور وهو بيعمل Push , أو مستني يحصل Pull Request Synchronization.
خصم 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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
UUID Performance Nightmare at Scale
الطريقة الشائعة واللي أغلبنا اتعرضلها عشان يقدر يولد Unique IDs عشان نستعملها في الـ Database ونميز الـ Rows كانت الـ UUID أو اللي بنسميه برضو GUID في منتجات Microsoft.
ورغم انها طريقة عملية جدًا لاننا نـ Generate Unique IDs الا ان الكلام ده بيجي معاه مشاكل خطيرة لما نشتغل في Scale كبير خصوصا مع الـ Performance.
ايه هو الـ UUID ؟
هو اختصار للـ Universally Unique Identifier والفرق بينه وبين الـ GUID ان اول كلمة بس هي اختصار لـ Globally.
بيتكون من 128 Bit، وده بيخليه عنده قدرة إنه يولد أكتر من 340 سكستيليون (340 مع 36 صفر جنبها) ID مختلف. فيه أنواع مختلفة من الـ UUID، زي الـ UUIDv1 والـ UUIDv4، وكل نوع ليه طريقة معينة لتوليد الـ IDs.
لكن النوع الأكثر شيوعًا هو الـ UUIDv4 , وهنلاقي انه بيشتمل على رقم 4 في الـ UUID المتولد اصلا واللي بيشير للـ Version.
ازاي بيحصله Generation ؟
بيعتمد على العشوائية التامة على عكس بعض الـ Versions التانية اللي بتعتمد على الـ Timestamp بالاضافة للـ MAC Address على سبيل المثال.
وبالتالي ده بيديله ميزة قوية الا وهي صعوبة تكراره وانه بيتميز بانه فريد بالاضافة لانه مش بيعتمد على أي معلومات شخصية.
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
