Pular para o conteúdo
thiagoetipadrões

Contatos

apps/api/graphql-federation

120 · API & Integração · ≈ 5 min de estudo

GraphQL Federation

Vários serviços GraphQL, cada um dono dos próprios tipos, publicados como um único schema — o supergraph. O cliente faz uma query só; o gateway descobre qual subgraph é dono de cada campo, busca a entidade no dono e pede a quem a estende os campos extras, pela chave. Use quando vários times donos de domínios distintos precisam atender queries que cruzam esses domínios.

passos
5
arquivos
4
testes
0
tecnologias
7
Lógica puraTypeScriptBunElysiaGraphQL YogaHive GatewayApollo SubgraphDataLoader
CenárioRelaçõesComparar
Baixar cartão

Cenário

No banco digital, o time de contas é dono de Account (titular, agência, saldo) e o time de transações é dono de Transaction, além de acrescentar Account.transactions. O app pede numa única query as contas com o extrato. Cada time publica seu subgraph de forma independente; nenhum chama o outro. Um terceiro serviço que tentasse redeclarar Account.holderName precisa ser barrado antes de chegar ao gateway.

Planta

Sequência
7/7
{ accounts { holderName transactions { amountCents } } }1{ accounts { id holderName } }23 contas com id3_entities(representations: 3 Account com id) { transactions }4DataLoader: uma leitura do ledger para as 35transacoes por conta6resposta unica, campos dos dois subgraphs7ClienteGateway (supergraph)Subgraph accountsSubgraph transactions
7

7 passos — reproduza para seguir o fluxo

Como funciona

5 passos

Subgrafos compõem um único schema.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    accounts declara type Account @key(fields: "id") e resolve a entidade pela chave em __resolveReference

  2. 02

    transactions estende Account pela mesma chave, só com o campo que adiciona (transactions), e é dono da mutation transactionRecord

  3. 03

    supergraphCompose lê o SDL de cada subgraph em { _service { sdl } } e compõe o supergraph (Federation v2); campo não compartilhável declarado em dois subgraphs falha a composição

  4. 04

    O gateway (Hive Gateway) planeja cada query: busca a lista no dono e envia todas as chaves ao contribuidor num único _entities

  5. 05

    No contribuidor, um DataLoader criado por requisição junta as contas numa leitura só — nunca global, para o cache não vazar entre usuários

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Um schema para o cliente, uma query por tela

  • Cada time publica seu subgraph sem coordenar deploy

  • Join entre domínios sem um serviço chamar o outro

  • Composição barra conflito antes de produção

Custos

  • Gateway, composição e plano de query para operar

  • Regras de posse de campo exigem disciplina entre times

  • Plano mal desenhado gera cascata de chamadas entre subgraphs

  • Abaixo de três serviços, a complexidade não se paga

apps/api/graphql-federation

4 arquivos

src/

  • subgraph_accounts.tsSubgraph dono de Account
  • subgraph_transactions.tsSubgraph dono de Transaction, que estende Account e usa DataLoader por requisição
  • gateway_federation.tsComposição do supergraph a partir do SDL dos subgraphs e gateway
  • subgraph_rogue.tsSubgraph que viola a posse de um campo, recusado na composição

Executar · só Bun

  1. bun install# dependências
  2. bun run demo# roda o cenário
  3. bun run test# testes unitários
Requisitos
Bun

Relações

Onde ele se encaixa

Mapa
  1. GraphQL Federation
  • Combina com2
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com GraphQL Federation?

Próximo projeto · API & IntegraçãoAPI Versioning
Esc

↑ ↓ navegarEnter abrir191 resultados