Cum funcționează federația GraphQL pentru microservicii?

Question

IT Interview Practice · Accepted Answer

**Federația** permite mai multor servicii desfășurate independent să dețină fiecare o parte dintr-un graf, pe care un **gateway** îl compune într-o singură schemă pe care clienții o interoghează. Este înlocuitorul modern al **schema stitching**, unde un gateway îmbina manual scheme remote — federația mută regulile de îmbinare în subgrafurile înseși.

## Arhitectura

```text
                 ┌────────────────────────┐
   Client ─────▶ │  Gateway / Router      │  (supergraf compus)
                 └───────┬────────┬───────┘
                         │        │  planifică + distribuie sub-interogări
              ┌──────────▼──┐  ┌──▼──────────┐  ┌──────────────┐
              │ Users svc    │  │ Reviews svc │  │ Products svc │
              │  type User   │  │  extends    │  │  type Product│
              │  @key(id)    │  │  User/Prod  │  │  @key(id)    │
              └──────────────┘  └─────────────┘  └──────────────┘
```

Fiecare serviciu este un **subgraf**. Un tip este deținut de un serviciu și **extins** de altele. Directiva `@key` numește câmpul (câmpurile) care identifică o entitate între servicii.

```graphql
# Subgraful Users DEȚINE User
type User @key(fields: "id") {
  id: ID!
  name: String!
}

# Subgraful Reviews EXTINDE User cu câmpurile pe care le deține
type User @key(fields: "id") {
  id: ID! @external          # declarat în altă parte; referit aici prin cheie
  reviews: [Review!]!        # acest subgraf contribuie cu acest câmp
}
```

Când o interogare se întinde peste servicii, gateway-ul o **planifică**: aduce `User` din Users, apoi apelează **entity resolver-ul** subgrafului Reviews (`__resolveReference`) cu `{ id }` ca să completeze `reviews`.

```js
// Subgraful Reviews rezolvă referința User pe care i-o predă gateway-ul
const resolvers = {
  User: {
    __resolveReference: (ref, ctx) => ctx.reviewLoader.load(ref.id),
  },
};
```

## Federație vs. stitching

Stitching centralizează logica de îmbinare în gateway (fragil, gateway-ul trebuie să știe de toți). Federația **descentralizează** proprietatea: echipele își evoluează subgraful independent, iar compunerea este verificată în CI. Compromisul este un gateway/router mai complex și planificarea interogărilor între servicii.

## De ce contează

La scară mare, o singură echipă nu poate deține o schemă monolitică. Intervievatorii vor să vadă că înțelegi **proprietatea entităților prin `@key`, reference resolver-ele și planificarea interogărilor** — și de ce federația bate stitching-ul pentru scalarea organizațională, nu doar pentru eleganța tehnică.

Arhitectura

Federație vs. stitching

De ce contează

Întrebări conexe