როგორ მუშაობს GraphQL federation მიკროსერვისებისთვის?

Question

IT Interview Practice · Accepted Answer

**Federation** ბევრ დამოუკიდებლად deploy-ებულ სერვისს აძლევს საშუალებას, თითოეულმა ერთი გრაფის ნაწილი ფლობდეს, რომელსაც **gateway** კლიენტების მიერ query-სთვის ერთ schema-ში აერთიანებს. ეს **schema stitching**-ის თანამედროვე ჩამნაცვლებელია, სადაც gateway remote schema-ებს ხელით აერთებდა — federation კი შერწყმის წესებს თავად subgraph-ებში გადააქვს.

## არქიტექტურა

```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)    │
              └──────────────┘  └─────────────┘  └──────────────┘
```

ყოველი სერვისი არის **subgraph**. ტიპს ერთი სერვისი ფლობს და სხვები მას **აფართოებენ**. `@key` დირექტივა ასახელებს ველ(ებ)ს, რომლებიც 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 სერვისებს გადაკვეთს, gateway მას **გეგმავს**: მოაქვს `User` Users-იდან, შემდეგ 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 შერწყმის ლოგიკას gateway-ში აცენტრალებს (მყიფეა, gateway-მ ყველა უნდა იცოდეს). federation კი მფლობელობას **დეცენტრალიზებს**: გუნდები საკუთარ subgraph-ს დამოუკიდებლად ავითარებენ და კომპოზიცია CI-ში მოწმდება. სამაგიეროდ trade-off არის უფრო რთული gateway/router და სერვისებს-შორის query-ს დაგეგმვა.

## რატომ არის ეს მნიშვნელოვანი

მასშტაბზე ერთ გუნდს მონოლითური schema-ს ფლობა არ შეუძლია. ინტერვიუერებს უნდათ დაინახონ, რომ გესმის **entity-ს მფლობელობა `@key`-ით, reference resolver-ები და query-ს დაგეგმვა** — და რატომ სჯობს federation stitching-ს ორგანიზაციული სკალირებისთვის და არა მხოლოდ ტექნიკური ელეგანტურობით.

არქიტექტურა

Federation თუ stitching

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები