Microservices साठी GraphQL federation कसे चालते?

Question

IT Interview Practice · Accepted Answer

**Federation** मुळे अनेक स्वतंत्रपणे deploy केलेल्या services पैकी प्रत्येक एका graph चा भाग स्वतःकडे ठेवू शकते, ज्याला **gateway** एकाच schema मध्ये compose करते, जो 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 च्या मालकीचा असतो आणि इतरांकडून **extended** केला जातो. `@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 तिचे **planning** करते: Users कडून `User` मिळवा, मग `{ id }` सह Reviews subgraph चा **entity resolver** (`__resolveReference`) call करून `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 स्वतंत्रपणे evolve करतात, आणि composition CI मध्ये तपासले जाते. याची किंमत म्हणजे अधिक गुंतागुंतीचे gateway/router आणि cross-service query planning.

## हे का महत्त्वाचे आहे

मोठ्या प्रमाणावर, एक team monolithic schema स्वतःकडे ठेवू शकत नाही. Interviewers ना तुम्हाला **`@key` द्वारे entity मालकी, reference resolvers, आणि query planning** समजते हे पाहायचे असते — आणि federation संघटनात्मक scaling साठी stitching पेक्षा का उत्तम आहे, केवळ तांत्रिक सौंदर्यासाठी नव्हे.

Architecture

Federation विरुद्ध stitching

हे का महत्त्वाचे आहे

संबंधित प्रश्न