Microservices માટે GraphQL federation કેવી રીતે કામ કરે છે?

Question

IT Interview Practice · Accepted Answer

**Federation** અનેક સ્વતંત્ર રીતે deploy થયેલી services ને એક ગ્રાફ નો ભાગ own કરવા દે છે, જેને એક **gateway** clients query કરે તેવા એક જ schema માં compose કરે છે. તે **schema stitching** નું આધુનિક પ્રતિસ્થાપન છે, જ્યાં gateway remote schemas ને manually merge કરતું — federation merge નિયમો ને 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 દ્વારા own થાય છે અને બીજાઓ દ્વારા **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` ભરવા માટે `{ id }` સાથે Reviews subgraph નો **entity resolver** (`__resolveReference`) call કરો.

```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 ને **વિકેન્દ્રિત** કરે છે: teams તેમના subgraph ને સ્વતંત્ર રીતે evolve કરે છે, અને composition CI માં verify થાય છે. Trade-off એ વધુ જટિલ gateway/router અને cross-service query planning છે.

## આ શા માટે મહત્વનું છે

Scale પર, એક team monolithic schema own કરી શકતી નથી. Interviewers જોવા માગે છે કે તમે **`@key` દ્વારા entity ownership, reference resolvers, અને query planning** સમજો છો — અને organizational scaling માટે federation stitching કરતાં શા માટે વધુ સારું છે, માત્ર technical સુઘડતા નહીં.

Architecture

Federation vs stitching

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો