REST مقابل GraphQL مقابل gRPC — متى تختار كلًّا منها؟

Question

IT Interview Practice · Accepted Answer

هذه ثلاثة نماذج API مختلفة، كلٌّ منها مُحسَّن لقيود مختلفة. لا فائز عالمي — الخيار الصحيح يعتمد على **المستهلك، وشكل البيانات، والشبكة**.

## الثلاثة بلمحة

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

موجّه بالموارد فوق HTTP عاديّ. **اخترْه** للواجهات العامة، وخدمات CRUD، وأي شيء يستفيد من HTTP caching والانتشار والبساطة. نقاط ضعفه هي **الجلب الزائد (over-fetching)** (تحصل على `/users/42` كاملًا وإن أردت حقلًا واحدًا) و**الجلب الناقص (under-fetching)** (مشكلة `N+1`: اجلب مستخدمًا، ثم كرِّر لتجلب كل طلب).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

endpoint واحد حيث **يحدّد العميل بالضبط ما يريد** في استعلام واحد، حالًّا الجلب الزائد/الناقص. **اخترْه** للواجهات الأمامية الغنية (خاصة الموبايل، حيث الرحلات ذهابًا وإيابًا مكلفة) وحين يحتاج عملاء كثيرون أشكالًا مختلفة من البيانات نفسها.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
المفاضلات: الـ HTTP caching أصعب (كل شيء `POST` إلى `/graphql`)، وقد يُخفي resolver ساذج استعلامات `N+1` مكلفة في قاعدة البيانات.

## gRPC

RPC قائم على العقد يستخدم **Protobuf** فوق **HTTP/2**. ثنائيّ ومُتعدِّد الإرسال (multiplexed)، فهو سريع ومُدمَج مع دعم للـ streaming. **اخترْه** للاتصال **بين الخدمات داخليًّا (service-to-service)** في backend microservices حيث يهمّ الأداء والكتابة الصارمة (strict typing). نقطة الضعف: دعم متصفح ضعيف (يحتاج proxy مثل grpc-web) وغير مقروء للبشر.

## الاختيار

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## لماذا يهم

بمستوى senior، يهتمّ المُقابِلون بالتعريفات أقلّ من اهتمامهم بما إذا كنت تستطيع **تبرير خيار في مواجهة قيود** — هذا السؤال حقيقةً هو "هل تطابق تقنية مع مشكلة بدل ملاحقة الضجيج؟". أقوى الإجابات ترتكز على الألم الذي يحلّه كلٌّ منها: GraphQL موجود ليقتل الجلب الزائد/الناقص للواجهات الأمامية المتطلّبة، وgRPC موجود ليجعل استدعاءات الخدمات الداخلية سريعة ومكتوبة بصرامة، وREST يبقى الافتراضي لأن HTTP caching والأدوات والألفة الشاملة مزايا عملية هائلة للواجهات العامة وواجهات نمط CRUD. والأهم، يلاحظ المهندس الـ senior أنها **ليست إمّا/أو** — معمارية شائعة هي REST أو GraphQL عند الحافّة العامة مع gRPC بين microservices الخلفية — ويُسمّي المفاضلات الملموسة (مخاطر caching والـ `N+1` في GraphQL، وقصة المتصفح الضعيفة لـ gRPC). ذلك التعليل حول الملاءمة والكلفة، لا القدرة على سرد الميزات، هو الإشارة.

الثلاثة بلمحة

REST

GraphQL

gRPC

الاختيار

لماذا يهم

أسئلة ذات صلة