microservices కోసం GraphQL federation ఎలా పనిచేస్తుంది?

Question

IT Interview Practice · Accepted Answer

**Federation** అనేక స్వతంత్రంగా deploy చేయబడిన services ప్రతి ఒక్కటి ఒక graph లో భాగాన్ని కలిగి ఉండటానికి అనుమతిస్తుంది, దాన్ని ఒక **gateway** clients query చేసే ఒకే schema గా compose చేస్తుంది. ఇది **schema stitching** కు ఆధునిక ప్రత్యామ్నాయం, అక్కడ gateway remote schemas ను మాన్యువల్‌గా merge చేసేది — federation merge rules ను subgraphs లోకే తరలిస్తుంది.

## ఆర్కిటెక్చర్

```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 services అంతటా ఒక entity ను గుర్తించే field(s) కు పేరు పెడుతుంది.

```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` ను fetch చేయండి, ఆపై `reviews` ను నింపడానికి `{ id }` తో Reviews subgraph యొక్క **entity resolver** (`__resolveReference`) ను పిలవండి.

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

## Federation vs stitching

Stitching merge logic ను gateway లో కేంద్రీకరిస్తుంది (పెళుసుగా ఉంటుంది, gateway ప్రతి ఒక్కరినీ తెలుసుకోవాలి). Federation ownership ను **decentralize** చేస్తుంది: teams తమ subgraph ను స్వతంత్రంగా evolve చేస్తాయి, మరియు composition CI లో verify చేయబడుతుంది. trade-off అనేది మరింత సంక్లిష్టమైన gateway/router మరియు cross-service query planning.

## ఇది ఎందుకు ముఖ్యం

scale వద్ద, ఒక team monolithic schema ను కలిగి ఉండలేదు. **`@key` ద్వారా entity ownership, reference resolvers, మరియు query planning** ను మీరు అర్థం చేసుకున్నారని — మరియు కేవలం technical elegance కోసమే కాకుండా organizational scaling కోసం federation stitching ను ఎందుకు అధిగమిస్తుందో — interviewers చూడాలనుకుంటారు.

ఆర్కిటెక్చర్

Federation vs stitching

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు