GraphQL from Zero to Zero مع عبد الرحمن عوض

هذا الفيديو حلقة بودكاست تقنية بالعربي تشرح GraphQL بشكل عملي: ليه ظهرت بدل REST، إزاي نعرّف الـ schema والـ resolvers، وإيه أهم المزايا والمشاكل اللي لازم فريق التطوير ياخد باله منها.​

إيه هو GraphQL وليه نستخدمه؟

• بيشرح مشاكل REST التقليدية: over‑fetching (بتجيب بيانات زيادة)، under‑fetching (محتاج calls كتير)، والـ coupling القوي بين الـ frontend والـ backend مع كل شاشة جديدة.​

• يوضّح فكرة GraphQL الأساسية: الكلاينت هو اللي بيحدد الـ shape بتاع الداتا (fields والعلاقات)، والسيرفر يرد بنفس الشكل بس، فبتقلل حجم الـ response وعدد الـ requests.​

• بيستعرض إزاي نكتب الـ schema (أنواع، Queries, Mutations) وإزاي أدوات زي GraphiQL بتخلي الـ API self‑documenting فيسهل على الـ frontend يكتشف المتاح من غير ما يفضل يسأل الـ backend.​

الديمو العملي

• بيبني مثال بسيط لمدوّنة (Posts و Authors) مرة بـ REST ومرة بـ GraphQL علشان يوضح قد إيه جلب البيانات المتداخلة (بوست ومعاه الكاتب والعكس) أبسط وأكتر مرونة في GraphQL.​

• بيشرح خطوة بخطوة backend implementation: تعريف الـ types (Post, Author)، كتابة الـ queries والـ mutations، وربطهم بـ resolvers بتتعامل مع قاعدة البيانات، مع توضيح إن المنطق قريب من REST لكن منظم حوالين الـ schema مش الـ endpoints.​

• بيوريك إزاي تضيف أو تعدل fields (زي content أو excerpt أو timestamps) والتغييرات دي تنتشر في الـ schema والأدوات من غير ما تجبر الـ frontend ياخد بيانات مش محتاجها.​

الأداء ومشكلة N+1

• بينبّه لمشكلة N+1: لو كل بوست بيجيب الكاتب نفسه باستعلام منفصل، هتغرق قاعدة البيانات في queries صغيرة كتير.​

• يشرح حل DataLoader: يعمل batching لكل الـ IDs المطلوبة في window صغيرة، ويبعتهـم في query واحدة (IN list) ويرجّع النتايج لكل resolver مرة واحدة.​

• يوضّح إن GraphQL مش سحر بيقلل كود الـ backend، إنت لسه هتكتب نفس منطق الجلب تقريبًا لكن هتركّز إدارة العلاقات والـ batching في loaders/resolvers.​

الـ Types، الـ Validation والـ Scalars

• بيبيّن إزاي نظام الـ types في GraphQL بيعمل عقد واضح وقت الـ runtime: السيرفر يرفض أي query مش مطابقة للـ schema قبل ما يدخل على الـ resolvers.​

• بيعرض أمثلة لأخطاء validation لما الكلاينت يطلب field مش موجود أو يبعث argument بنوع غلط، وده يحمي الطرفين من bugs غبية.​

• يشرح فكرة custom scalars (زي نوع خاص للوقت) علشان تتحكم في parsing و serialization وتضمن تنسيق موحّد بين الويب والموبايل.​

الأمان والتعقيد في الإنتاج

• بيناقش خطورة الـ queries المتعمقة جدًا (author → posts → author → posts …) اللي ممكن تكلف السيرفر وقت وموارد ضخمة وتتسبب في DoS لو الـ API مفتوح.​

• يذكر حلول عملية: تحديد أقصى عمق للـ query، limits لحجم البيانات، تحليل cost لكل query، وأحيانًا تعيين “تعقيد” لكل field وفرض budget لكل طلب.​

• بينهي الفكرة إن GraphQL قوي جدًا مع أنظمة فيها كذا كلاينت وداتا مترابطة، لكن بيضيف تعقيد حقيقي في الـ backend (performance، security، تصميم الـ schema) لازم الفريق يفهمه ويسيطر عليه.​