Microservices کے لیے GraphQL federation کیسے کام کرتی ہے؟

Question

IT Interview Practice · Accepted Answer

**Federation** کئی آزادانہ طور پر deploy کی گئی services کو یہ سہولت دیتی ہے کہ ہر ایک ایک ہی graph کے حصے کی مالک ہو، جسے ایک **gateway** ایک واحد schema میں جوڑ دیتا ہے جسے clients query کرتے ہیں۔ یہ **schema stitching** کا جدید متبادل ہے، جہاں ایک gateway دستی طور پر remote schemas کو ضم کرتا تھا — federation ضم کرنے کے اصولوں کو خود subgraphs میں منتقل کر دیتی ہے۔

## فنِ تعمیر (architecture)

```text
                 ┌────────────────────────┐
   Client ─────▶ │  Gateway / Router      │  (composed supergraph)
                 └───────┬────────┬───────┘
                         │        │  plans + fans out sub-queries
              ┌──────────▼──┐  ┌──▼──────────┐  ┌──────────────┐
              │ Users svc    │  │ Reviews svc │  │ Products svc │
              │  type User   │  │  extends    │  │  type Product│
              │  @key(id)    │  │  User/Prod  │  │  @key(id)    │
              └──────────────┘  └─────────────┘  └──────────────┘
```

ہر service ایک **subgraph** ہے۔ ایک type ایک service کی ملکیت ہوتی ہے اور دوسری اسے **extend** کرتی ہیں۔ `@key` directive ان field(s) کا نام بتاتی ہے جو services کے پار کسی entity کی شناخت کرتی ہیں۔

```graphql
# Users subgraph OWNS User
type User @key(fields: "id") {
  id: ID!
  name: String!
}

# Reviews subgraph EXTENDS User with fields it owns
type User @key(fields: "id") {
  id: ID! @external          # declared elsewhere; referenced here by key
  reviews: [Review!]!        # this subgraph contributes this field
}
```

جب کوئی query services پر پھیلتی ہے، تو gateway اسے **plan** کرتا ہے: Users سے `User` لائیں، پھر Reviews subgraph کے **entity resolver** (`__resolveReference`) کو `{ id }` کے ساتھ کال کریں تاکہ `reviews` بھری جا سکیں۔

```js
// Reviews subgraph resolves the User reference the gateway hands it
const resolvers = {
  User: {
    __resolveReference: (ref, ctx) => ctx.reviewLoader.load(ref.id),
  },
};
```

## Federation بمقابلہ stitching

Stitching ضم کرنے کی logic کو gateway میں مرکوز کرتی ہے (نازک، gateway کو سب کا علم ہونا چاہیے)۔ Federation ملکیت کو **غیر مرکوز** کرتی ہے: teams اپنے subgraph کو آزادانہ طور پر ارتقا دیتی ہیں، اور composition کی تصدیق CI میں ہوتی ہے۔ اس کی قیمت ایک زیادہ پیچیدہ gateway/router اور cross-service query planning ہے۔

## یہ کیوں اہم ہے

بڑے پیمانے پر، ایک team ایک monolithic schema کی مالک نہیں ہو سکتی۔ Interviewers یہ دیکھنا چاہتے ہیں کہ آپ **`@key` کے ذریعے entity ownership، reference resolvers، اور query planning** کو سمجھتے ہیں — اور یہ کہ federation stitching سے کیوں بہتر ہے، صرف تکنیکی خوبصورتی کے لیے نہیں بلکہ تنظیمی scaling کے لیے۔

فنِ تعمیر (architecture)

Federation بمقابلہ stitching

یہ کیوں اہم ہے

متعلقہ سوالات