DevGuide

Introducing Claude Opus 5. It's a thoughtful and proactive model that comes close to the frontier intelligence of Fable 5 at half the price. https://www.anthropic.com/news/claude-opus-5 . . #ai

CSS: Tabular Numbers In CSS, tabular numbers force digits to take up the exact same horizontal width. . . #css

مصطلحات مهمة في عالم الـ System Design 💯 (٦) . . في البوست اللي فات عرفنا إزاي نزود عدد السيرفرات باستخدام الـ Horizontal Scaling، وإزاي الـ Load Balancer بيوزع الـ Requests بينهم. لكن مع الوقت، المشكلة الحقيقية غالبًا بتكون في قاعدة البيانات نفسها. تخيل إن عندك ملايين المستخدمين، ومئات الملايين من الطلبات، وكل السيرفرات بتقرأ وتكتب في نفس الـ Database. في مرحلة معينة هتلاقي إن قاعدة البيانات بقت هي المشكلة الأكبر والأهم... وقتها بنبدأ نفكر إزاي هنحل المشكلة دي... ——— 📌 Replication أول حل هو إننا نعمل نسخ متعددة من قاعدة البيانات. يبقى عندنا: • Primary Database تستقبل عمليات الكتابة (Write). • Replica Databases تستقبل عمليات القراءة (Read). تخيل إن عندك مكتبة عليها زحمة. بدل ما الناس كلها تقف على نسخة واحدة من الكتاب، بتعمل نسخ إضافية علشان عدد أكبر من الناس يقدر يقرأ في نفس الوقت. وده بالضبط اللي بيحصل مع Replication. الميزة إنك تقدر توزع عمليات القراءة على أكتر من Replica، فتخفف الضغط على الـ Primary Database. لكن إيه اللي هيحصل لو حجم البيانات نفسه بقى ضخم جدًا، حتى النسخ المتعددة مش كفاية؟ ——— 📌 Sharding هنا بنقسم البيانات نفسها. بدل ما كل المستخدمين موجودين في قاعدة بيانات واحدة، ممكن نقسمهم على عدة قواعد بيانات. كأن عندك ملف ضخم جدًا، فقسمته على عدة أدراج بدل ما تحطه كله في درج واحد. الميزة إن كل Shard يشيل جزء من البيانات فقط، وبالتالي الضغط يتوزع. لكن الـ Sharding بيضيف تعقيد أكبر، لأن التطبيق لازم يعرف البيانات المطلوبة موجودة في أي Shard. ——— 📌 Vertical Partitioning تخيل جدول مستخدمين فيه: - الاسم - الإيميل - رقم التليفون - الصورة - العنوان - إعدادات الحساب - بيانات إضافية تانية… مش كل الطلبات محتاجة كل الأعمدة دي. فممكن نفصل البيانات الأساسية في جدول، والبيانات الأقل استخدامًا في جدول تاني. وده اسمه Vertical Partitioning. يعني بدل ما كل Query تقرأ جدول ضخم، تقرأ الجزء اللي محتاجاه فقط. ——— 💡 الخلاصة النهارده عرفنا 3 طرق مختلفة علشان نكبر قاعدة البيانات: • الـ Replication: إنشاء نسخ متعددة من قاعدة البيانات لتوزيع عمليات القراءة. • الـ Sharding: تقسيم البيانات على عدة قواعد بيانات مختلفة. • الـ Vertical Partitioning: تقسيم الأعمدة داخل الجداول لتقليل حجم البيانات المقروءة في كل Query. دلوقتي نقدر نتعامل مع قواعد بيانات ضخمة جدًا. لكن… حتى مع كل التقسيم والنسخ دي، لسه فيه مشكلة ممكن تقتل الأداء: إننا نروح نكلم قاعدة البيانات في كل Request. وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Caching و Denormalization و CAP Theorem. ——— #system_design

AI Engineering from Scratch 💯 503 lessons. 20 phases. Every algorithm built from raw math before a single framework gets imported. https://aiengineeringfromscratch.com

مصطلحات مهمة في عالم الـ System Design 💯 (٥) . . في البوست اللي فات تكلمنا عن Vertical Scaling، وإن أبسط حل لزيادة الضغط هو إننا نقوّي السيرفر الحالي... لكن تخيل إن عندك تطبيق وعدد المستخدمين زاد جدًا، وكل ما تزود RAM أو CPU تلاقي الضغط بيرجع يزيد تاني. في لحظة معينة هتوصل لأقصى قدرة ممكنة للسيرفر. إيه الحل؟ ——— 📌 Horizontal Scaling بدل ما نقوّي سيرفر واحد، نضيف سيرفرات جديدة. يعني لو عندك سيرفر واحد عليه ضغط عالي، ممكن تخلي عندك 2 أو 5 أو 10 سيرفرات يشيلوا الحمل مع بعض. وده اسمه Horizontal Scaling أو Scale Out. تخيل مطعم فيه موظف واحد بيستقبل الطلبات. لما الزحمة تزيد، بدل ما نجيبله مكتب أكبر، نجيب موظفين إضافيين يساعدوه. نفس الفكرة بالضبط. الميزة هنا إنك تقدر تزود عدد السيرفرات تدريجيًا حسب عدد المستخدمين. لكن ظهر سؤال جديد… لو عندي 10 سيرفرات، الـ Request يروح لمين فيهم؟ ——— 📌 Load Balancer هنا ييجي دور الـ Load Balancer. هو جهاز أو خدمة بتقف قدام كل السيرفرات، وأي Request جديد يوصله، يقرر يبعته لأي سيرفر. يعني بدل ما المستخدم يختار بنفسه، الـ Load Balancer هو اللي يوزع الطلبات بشكل ذكي. مثلًا: - السيرفر الأول مشغول جدًا - ابعت الطلب لسيرفر تاني. - سيرفر وقع أو فيه مشكلة - متبعتلوش أي Requests. - عايز توزع الحمل بالتساوي - وزّع الطلبات على كل السيرفرات. من غير Load Balancer، ممكن سيرفر واحد ينهار من الضغط بينما باقي السيرفرات فاضية. وده سبب إن أي نظام قابل للتوسع تقريبًا بيستخدم Load Balancer بشكل أو بآخر. لكن حتى بعد توزيع الحمل، فيه مشكلة تانية ممكن تبطّأ النظام… ——— 📌 Database Indexing تخيل إن عندك كتاب فيه 1000 صفحة، وعايز تدور على موضوع معين. هل هتقرأ الكتاب كله صفحة صفحة؟ أكيد لا. هتروح للفهرس الأول. الـ Index في قاعدة البيانات بيعمل نفس الفكرة. بدل ما الـ Database تفتش في كل الصفوف علشان تلاقي مستخدم أو أوردر معين، تستخدم الـ Index علشان توصل للبيانات بسرعة. مثلًا لو بتبحث كتير باستخدام email، ممكن تعمل Index على العمود ده هيخلّي البحث أسرع بفرق كبير. لكن خلي بالك، كل Index إضافي بياخد مساحة، وبيخلّي عمليات الكتابة أبطأ شوية، علشان كده بنعمل Index للأعمدة اللي عليها عمليات بحث كتيرة. ——— 💡 الخلاصة النهارده عرفنا إزاي الأنظمة الكبيرة تتعامل مع زيادة عدد المستخدمين: • الـ Horizontal Scaling: إضافة سيرفرات جديدة بدل تقوية سيرفر واحد. • الـ Load Balancer: توزيع الـ Requests على السيرفرات بشكل ذكي. • الـ Database Indexing: تسريع البحث داخل قاعدة البيانات باستخدام Indexes. ——— دلوقتي بقينا نقدر نشغّل أكتر من سيرفر ونوزّع الحمل بينهم. لكن إيه اللي هيحصل لو قاعدة البيانات بقت كبيرة جدًا؟ ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Replication و Sharding و Vertical Partitioning. ——— #system_design

مصطلحات مهمة في عالم الـ System Design 💯 (٤) . . في البوست اللي فات عرفنا إزاي الـ Client يطلب بيانات من السيرفر باستخدام APIs، سواء كانت REST أو GraphQL. لكن فيه سؤال مهم جدًا… السيرفر بيجيب البيانات دي منين؟ لما تفتح بروفايل مستخدم، أو تشوف قائمة المنتجات، أو تبحث عن أوردر معين، أكيد البيانات دي لازم تكون متخزنة في مكان ما. وهنا يظهر دور الـ Database... ——— 📌 Databases الـ Database هي المكان اللي بنخزن فيه البيانات بشكل منظم. بدل ما التطبيق يعتمد على الذاكرة فقط، بيخزن البيانات بشكل دائم في قاعدة بيانات علشان يقدر يرجع لها في أي وقت. تخيل عندك متجر إلكتروني. فيه منتجات، ومستخدمين، وأوردرات، وعمليات دفع. كل المعلومات دي بتتخزن داخل الـ Database. ولما المستخدم يطلب حاجة، السيرفر يروح يجيب البيانات من قاعدة البيانات ويرجع النتيجة. لكن مش كل قواعد البيانات بتشتغل بنفس الطريقة. وهنا ييجي السؤال اللي بيتكرر كتير في أي Interview… SQL or NoSQL? ——— 📌 SQL vs NoSQL قواعد بيانات SQL بتكون منظمة في جداول وعلاقات واضحة بين البيانات. زي مثلًا: - جدول للمستخدمين - جدول للطلبات - جدول للمنتجات والعلاقات بينهم بتكون محددة بشكل واضح. أشهر الأمثلة: - PostgreSQL - MySQL - SQL Server أما NoSQL فبتكون أكثر مرونة. ممكن تخزن البيانات على شكل Documents أو Key-Value أو Graphs، من غير ما تكون ملتزم بنفس شكل الجداول التقليدي. أشهر الأمثلة: - MongoDB - Redis - Cassandra ——— طيب أختار إيه؟ لو عندك بيانات مترابطة وعايز معاملات تضمن سلامة البيانات، غالبًا SQL هيكون مناسب. لو شكل البيانات بيتغير باستمرار، أو محتاج مرونة أكبر في التوسع، ممكن NoSQL يكون اختيار مناسب. لكن مع الوقت، حتى لو اخترت النوع المناسب، هتواجه مشكلة تانية… المستخدمين بيزيدوا، والضغط على السيستم بيزيد... ——— 📌 Vertical Scaling تخيل إن عندك سيرفر واحد، وكل حاجة شغالة عليه. وفجأة عدد المستخدمين زاد جدًا. أبسط حل يخطر في بالك إنك تزود إمكانيات السيرفر نفسه. وده اسمه Vertical Scaling أو Scale Up. يعني بدل ما تغير النظام كله، بتقوي الجهاز الحالي. الحل ده سهل وسريع في البداية، لكنه له حدود. لأن في مرحلة معينة، مهما زودت إمكانيات السيرفر، هتوصل لأقصى قدرة ممكنة، وساعتها هتحتاج تفكر بطريقة مختلفة. ——— 💡 الخلاصة • الـ Database: المكان اللي بيتخزن فيه كل بيانات التطبيق. • الـ SQL: قواعد بيانات منظمة بعلاقات واضحة بين الجداول. • الـ NoSQL: قواعد بيانات مرنة تناسب البيانات المتغيرة والتوسع بسهولة. • الـ Vertical Scaling: تقوية السيرفر الحالي بزيادة الـ CPU أو الـ RAM أو الـ Storage. ——— دلوقتي عرفنا أول طريقة للتعامل مع زيادة الضغط على السيستم. لكن إيه اللي هيحصل لو السيرفر نفسه وصل لأقصى إمكانياته المسموح بها ومبقاش كافي لوحده؟ ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Horizontal Scaling وLoad Balancer وDatabase Indexing. ——— #system_design

مصطلحات مهمة في عالم الـ System Design 💯 . . في البوست اللي فات عرفنا إن الـ Client بعت الـ Request، والـ Server استقبله، وتكلموا مع بعض باستخدام HTTP/HTTPS. لكن بمجرد ما الـ Request يوصل للسيرفر، ييجي سؤال مهم... إزاي السيرفر يعرف المطلوب منه؟ يعني لما تضغط على زرار Login، أو تعمل Search، أو تفتح قائمة المنتجات... إيه اللي بيخلي كل Request يروح للمكان الصح؟ الإجابة هي إن كل وظيفة في التطبيق بيكون لها API. ——— 📌 API الـ API اختصار لـ Application Programming Interface. الاسم ممكن يخض شوية، لكن الفكرة أبسط من كده بكتير. تخيل إنك في مطعم. أنت مش بتدخل المطبخ بنفسك علشان تطلب الأكل، فيه ويتر بياخد منك الطلب، يوصله للمطبخ، وبعدها يرجعلك بالأكل. الويتر ده هو الـ API. هو الوسيط بين الـ Client والـ Server. الـ Client يبعت Request، والـ API يستقبله، يوصله للجزء المناسب في السيرفر، وبعدها يرجع Response. علشان كده لما تسمع حد بيقول: "اعمل API للـ Login" فهو يقصد نقطة دخول يقدر الـ Client يبعتلها بيانات تسجيل الدخول، والسيرفر يتعامل معاها ويرجع النتيجة. لكن... هل كل الـ APIs بتشتغل بنفس الطريقة؟ الإجابة لا. وأشهر طريقة موجودة حاليًا اسمها REST. ——— 📌 REST الـ REST مش لغة برمجة، ولا Framework. ولكن هي مجموعة قواعد بتنظم شكل الـ APIs. يعني بدل ما كل Backend Developer يخترع طريقة مختلفة، بقى فيه أسلوب متفق عليه يخلي أي Developer يفهم الـ API بسهولة. مثلًا... لو عايز تجيب كل المنتجات، غالبًا هتلاقي Endpoint زي: GET /products ولو عايز تضيف منتج جديد: POST /products ولو عايز تعدل منتج: PUT /products/1 الفكرة إن كل حاجة بقت ماشية بنمط معروف. وده السبب إن أغلب الـ APIs اللي بنتعامل معاها النهارده هي REST APIs. لكن مع الوقت، بدأت تظهر مشكلة. أوقات الـ Client بيحتاج جزء صغير من البيانات، والسيرفر يرجع بيانات أكتر بكتير من اللي محتاجها. وأوقات تانية يحتاج بيانات من أكتر من API علشان يقدر يعرض شاشة واحدة. ومن هنا ظهر مفهوم جديد. ——— 📌 GraphQL الـ GraphQL جه يحل المشكلة دي. بدل ما السيرفر يقرر إيه البيانات اللي هترجع، الـ Client هو اللي يحدد بالضبط هو محتاج إيه. يعني لو شاشة فيها اسم المستخدم وصورته بس. مش لازم السيرفر يرجع الإيميل، ورقم التليفون، والعنوان، وتاريخ الميلاد، وباقي البيانات. الـ Client يطلب الاسم والصورة فقط. والسيرفر يرجع الاسم والصورة فقط. وده بيقلل حجم البيانات اللي بتتنقل، وبيخلي بعض الشاشات أسرع، خصوصًا في التطبيقات الكبيرة. لكن ده مش معناه إن GraphQL أحسن من REST في كل الحالات. كل واحد له استخداماته، واختيار واحد منهم بيعتمد على طبيعة النظام اللي بتبنيه. ——— 💡 الخلاصة النهارده عرفنا إزاي السيرفر بيفهم المطلوب منه. - الـ API: هي نقطة التواصل بين الـ Client والـ Server، وكل Feature في التطبيق غالبًا بيكون لها API. - الـ REST: أسلوب شائع لبناء الـ APIs باستخدام قواعد وأنماط متفق عليها. - الـ GraphQL: بيدي الـ Client حرية يحدد البيانات اللي محتاجها بالظبط، بدل ما يستقبل بيانات زيادة. دلوقتي بقينا عارفين إزاي الـ Client يطلب البيانات من السيرفر. لكن... السيرفر بيجيب البيانات دي منين أصلًا؟ وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Databases، وSQL vs NoSQL، وVertical Scaling.

مفهوم الـ End-to-End Test 💯 . . خلال رحلتك في عالم البرمجة، ممكن تكون اشتغلت على Feature كبيرة، وكنت متأكد إن الـ code شغال زي الفل. وكتبت Unit Tests، وكل الـ functions بتـرجّع اللي المفروض ترجعه. بعد كده جربت الـ app بإيدك، كل حاجة ماشية حلو… بس لما رفعت الكود على الـ staging أو الـ production، فجأة فيه حاجات وقعت ومش شغاله... المشكلة هنا إن اللي أنت اختبرته مش كفاية... أنت اختبرت أجزاء صغيرة، لكن معملتش اختبار للرحلة كاملة من أول ما الـ user يفتح الـ app لحد ما يوصل لهدفه. وهنا بييجي دور الـ End-to-End Testing (E2E)... ——— 🎯 يعني إيه End-to-End Test؟ الـ End-to-End Test ببساطة هو نوع من أنواع الـ Testing اللي بيحاكي تصرفات الـ user الحقيقية. بنختبر الـ system كـ “صندوق أسود” من غير ما نهتم بالتفاصيل الداخلية، إحنا بس عاوزين نتأكد إن الـ app بيشتغل زي ما الـ user متوقع بالضبط، من أول خطوة لآخر خطوة. يعني بنبدأ من الـ UI، ونتفاعل مع الـ buttons والـ forms والـ links، وبنشوف هل الـ backend بيرد زي ما المفروض؟ هل الـ database اتحدثت؟ هل النتيجة اللي ظهرت للمستخدم منطقية؟ ——— 📌 إمتى تستخدم الـ E2E؟ - لو بتسلم Feature مهمة جدًا، زي عملية دفع أو تسجيل دخول. - لو الـ app فيه flows معقدة أو steps كتير وبتعتمد على بعض. - لو عاوز تتأكد إن الـ integration بين الـ frontend والـ backend شغال تمام. - وقت الـ release، علشان تطمن إن الـ system ككل شغال سليم من الأول للآخر. ——— 🛠 أشهر أدوات الـ End-to-End Testing - الـ Cypress: سهل، واضح، بيشتغل على المتصفح، وبيخليك تـ debug بسهولة. - الـ Playwright: سريع وبيدعم browsers كتير، وممتاز للـ automation. - الـ Selenium: قديم وتقيل شوية، بس لسه ناس بتستخدمه عشان مرن وبيشتغل بلغات مختلفة. ——— ⚙️ أمثلة على Scenarios ممكن نعملها E2E Test - مستخدم بيسجل في الموقع، بيرجعله confirmation message. - مستخدم بيدخل بيانات كريدت كارد وبتتم عملية الدفع. - مستخدم بيعمل login وبيتنقل على الـ dashboard. - مستخدم بيبعت فورم contact us وتوصله رسالة تأكيد. ——— 💡 ليه الـ E2E Tests مهمة؟ - بتمنع الـ regressions اللي ممكن تحصل بعد تغييرات كبيرة. - بتكشف bugs مش ممكن تكتشفها بالـ Unit أو الـ Integration tests. - بتديك confidence إن الـ system ككل شغال زي ما المفروض. - بتساعد الفريق كله (frontend, backend, QA) يكونوا مطمنين قبل أي release. ——— ⚠️ بس خلي بالك... الـ E2E Tests تقيلة في الـ execution، وبطيئة مقارنةً بالأنواع التانية. فعشان كده بنكتب منها بس الـ critical flows، مش كل حاجة. كمان أي تغيير بسيط في UI ممكن يكسرها… فلازم تكتبها بشكل كويس وقابل للصيانة. ——— 💡 نصائح لو هتبدأ تكتب E2E Tests: - ابني test لكل user journey مهمة. - حاول تعزل الـ data اللي بتستخدمه في التست (استخدم mocks أو test accounts). - حافظ على naming واضح وسهل في الـ tests. - شغّلها في CI/CD pipeline عشان تمسك المشاكل قبل ما توصل للناس. ——— الـ E2E Testing هو خط الدفاع الأخير، اللي بيأكد إن كل حاجة ماشية تمام من منظور المستخدم. وكمان هو اللي بيخليك ضامن إن الـ feature اللي تعبت فيها مش هتبوظ لما تطلع production.

مصطلحات مهمة في عالم الـ System Design 💯 . . في البوست اللي فات بدأنا رحلة الـ Request، وتكلمنا عن الـ Client-Server Architecture، وإزاي الـ Client بيبعت الـ Request، ودور الـ DNS في تحويل اسم الموقع إلى IP Address علشان يوصله للسيرفر الصحيح. لكن هل معنى كده إن كل Request بيروح مباشرة للسيرفر؟ الإجابة في أغلب الأنظمة الكبيرة هي: غالبًا لا. قبل ما الـ Request يوصل للسيرفر، غالبًا بيعدي على محطة في النص. والمحطة دي ممكن يكون لها أكتر من وظيفة، زي إنها تحمي السيرفر، أو توزع الضغط، أو حتى تسرّع الاستجابة. وده ياخدنا لأول مفهوم النهارده... --- 4- Proxy الـ Proxy ببساطة هو وسيط بينك وبين السيرفر. بدل ما جهازك يتواصل مع السيرفر بشكل مباشر، بيبعت الـ Request للـ Proxy الأول، وهو اللي يتعامل مع السيرفر نيابة عنك. طب ليه نعمل كده؟ تخيل إنك في شركة، وكل الموظفين اللي فيها بيستخدموا الإنترنت من خلال شبكة الشركة. بدل ما كل جهاز يظهر على الإنترنت مباشرة، كل الطلبات بتعدي على Proxy Server. كده الشركة تقدر تراقب الترافيك، تمنع مواقع معينة، أو حتى تخزن بعض البيانات لتسريع الوصول ليها. وده مجرد استخدام واحد. فيه استخدامات تانية كتير للـ Proxy حسب نوعه، وهنقابل نوع مهم جدًا قدام وهو Reverse Proxy. لكن حتى لو فيه Proxy، أو مفيش، يفضل فيه سؤال مهم... ليه بعض المواقع بتفتح في ثانية، ومواقع تانية بتحس إنها بطيئة؟ --- 5- Latency كتير بنربط بطء الموقع بسرعة الإنترنت، لكن ده مش السبب الوحيد. فيه حاجة اسمها Latency، وهي الوقت اللي بيستغرقه الـ Request علشان يروح للسيرفر، والـ Response يرجع تاني. كل ما المسافة بينك وبين السيرفر كانت أكبر، أو كان فيه عدد كبير من الأجهزة في الطريق، أو الشبكة نفسها بطيئة، كل ما الـ Latency تزيد. عشان كده ممكن يكون عندك إنترنت سريع، لكن موقع معين لسه بيفتح ببطء، لأن المشكلة مش في سرعة التحميل، المشكلة في الوقت اللي البيانات بتستغرقه علشان توصل وترجع. وده واحد من أكبر التحديات في الـ System Design، لأن تحسين الـ Latency بيأثر بشكل مباشر على تجربة المستخدم. طيب... بعد ما الـ Request وصل للسيرفر، هو بيتكلم معاه إزاي أصلًا؟ --- 6- HTTP / HTTPS لما شخصين بيتكلموا مع بعض، لازم يكون فيه لغة مشتركة بينهم. ونفس الفكرة بتحصل بين الـ Client والـ Server. اللغة أو البروتوكول الأشهر اللي بيتواصلوا بيه هو HTTP. هو اللي بيحدد شكل الـ Request، وشكل الـ Response، وإزاي البيانات تتبعت وتترجع. لكن مع الوقت، بقى مهم إن البيانات تكون محمية أثناء انتقالها، خصوصًا لما تبعت Password أو بيانات بطاقة بنكية. ومن هنا ظهر HTTPS. هو ببساطة نفس HTTP، لكن مع إضافة طبقة تشفير بتحافظ على البيانات أثناء انتقالها، بحيث لو حد اعترضها، ميقدرش يفهم محتواها. علشان كده هتلاقي معظم المواقع دلوقتي بتستخدم HTTPS، وهتشوف علامة القفل جنب اسم الموقع في المتصفح. --- 💡 الخلاصة - الـ Proxy: وسيط بين الـ Client والـ Server، وله استخدامات كتير زي الأمان، والتحكم، وتحسين الأداء. - الـ Latency: الوقت اللي الـ Request والـ Response بيستغرقوه في الرحلة، وكل ما قل، تجربة المستخدم كانت أفضل. - الـ HTTP / HTTPS: البروتوكول اللي بيتواصل بيه الـ Client مع الـ Server، وHTTPS بيضيف طبقة تشفير لحماية البيانات. دلوقتي بقينا عارفين إزاي الـ Client بيتواصل مع الـ Server. لكن... لما السيرفر يستقبل الـ Request، إزاي بيعرف المطلوب منه؟ وإزاي التطبيقات بتتواصل مع بعضها؟ ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على APIs و REST و GraphQL. --- #system_design