GraphQL

Schema e Schema Definition Language (SDL)

O schema GraphQL é o contrato central — define todos os tipos disponíveis, as relações entre eles, e as operações que os clientes podem executar. É escrito em SDL (Schema Definition Language), uma sintaxe independente de linguagem que ferramentas e runtimes interpretam para gerar código, validar queries e oferecer autocompletion.

Tipos escalares e objetos

# Tipos escalares built-in
# Int, Float, String, Boolean, ID

# Tipos escalares customizados
scalar DateTime
scalar UUID
scalar Money  # centavos como Int, mas com semântica explícita

# Enum
enum OrderStatus {
  PENDING
  PROCESSING
  SHIPPED
  DELIVERED
  CANCELLED
}

# Tipo objeto — campos não-nullable por padrão com !
type OrderItem {
  id: ID!
  productId: ID!
  productName: String!
  quantity: Int!
  unitPriceCents: Int!
  totalPriceCents: Int!  # campo derivado — calculado no resolver
}

type Address {
  street: String!
  city: String!
  state: String!
  postalCode: String!
  country: String!
}

type Customer {
  id: ID!
  name: String!
  email: String!
  # Relação — lista de pedidos com paginação (veremos adiante)
  orders(
    first: Int
    after: String
    status: OrderStatus
  ): OrderConnection!
}

type Order {
  id: ID!
  customer: Customer!        # relação — resolver faz join/fetch
  items: [OrderItem!]!       # lista não-nullable de não-nullables
  status: OrderStatus!
  shippingAddress: Address
  subtotalCents: Int!
  shippingCostCents: Int!
  totalCents: Int!
  createdAt: DateTime!
  updatedAt: DateTime!

Input types — para mutações

# Input types são separados de tipos de output — boa prática
input OrderItemInput {
  productId: ID!
  quantity: Int!
}

input AddressInput {
  street: String!
  city: String!
  state: String!
  postalCode: String!
  country: String!
}

input CreateOrderInput {
  customerId: ID!
  items: [OrderItemInput!]!
  shippingAddress: AddressInput!
}

input UpdateOrderStatusInput {
  orderId: ID!
  status: OrderStatus!
  reason: String  # opcional — sem !
}

Tipos especiais: Query, Mutation, Subscription

type Query {
  # Busca simples
  order(id: ID!): Order       # retorna null se não encontrado
  customer(id: ID!): Customer

  # Listagem com filtros e paginação (Relay Cursor Connections)
  orders(
    first: Int
    after: String
    last: Int
    before: String
    filter: OrderFilterInput
  ): OrderConnection!

  # Busca textual
  searchProducts(query: String!, limit: Int = 20): [Product!]!

  # Campo de saúde (útil para verificação de schema)
  _health: Boolean!
}

type Mutation {
  createOrder(input: CreateOrderInput!): CreateOrderPayload!
  updateOrderStatus(input: UpdateOrderStatusInput!): UpdateOrderStatusPayload!
  cancelOrder(id: ID!, reason: String): CancelOrderPayload!
}

type Subscription {
  # Evento push quando status de um pedido muda
  orderStatusChanged(orderId: ID!): OrderStatusChangedEvent!
  # Todos os pedidos de um cliente em tempo real
  customerOrderUpdates(customerId: ID!): OrderEvent!
}

# Payload types para mutações — padrão recomendado
# Embute o objeto criado/modificado + erros de negócio no type system
type CreateOrderPayload {
  order: Order            # null se houve erro
  errors: [UserError!]!  # lista vazia em sucesso
}

type UserError {
  field: [String!]   # caminho do campo com erro (ex: ["items", "0", "quantity"])
  message: String!
}

type OrderStatusChangedEvent {
  order: Order!
  previousStatus: OrderStatus!
  newStatus: OrderStatus!
  changedAt: DateTime!
}

Interfaces e Union types

# Interface — múltiplos tipos implementam campos comuns
interface Node {
  id: ID!
}

interface Timestamped {
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Order implements Node & Timestamped {
  id: ID!
  createdAt: DateTime!
  updatedAt: DateTime!
  # ... outros campos
}

# Union — um campo pode retornar um de N tipos não relacionados
union SearchResult = Order | Product | Customer

type Query {
  search(query: String!): [SearchResult!]!
}

# Na query, o cliente usa inline fragments para acessar campos específicos:
# query {
#   search(query: "notebook") {
#     ... on Product { id name price }
#     ... on Order { id status }
#     ... on Customer { id name email }
#   }
# }

Operações: Query, Mutation, Subscription

Todas as operações GraphQL são enviadas via HTTP POST para um único endpoint (tipicamente /graphql). O body JSON contém query (a operação em SDL), variables (parâmetros externos) e opcionalmente operationName (quando o documento contém múltiplas operações nomeadas).

Queries — leitura com precisão cirúrgica

# O cliente pede exatamente o que precisa — nem mais, nem menos

# Query simples sem variáveis
query {
  order(id: "order-abc") {
    id
    status
    totalCents
    customer {
      name
      email
    }
    items {
      productName
      quantity
      totalPriceCents
    }
  }
}

# Query com variáveis (forma correta — sem interpolação de string)
query GetOrder($orderId: ID!) {
  order(id: $orderId) {
    id
    status
    items {
      productName
      quantity
    }
  }
}
# Variables JSON: { "orderId": "order-abc" }

# Múltiplos recursos em uma requisição (o grande ganho vs REST)
query DashboardData($customerId: ID!) {
  customer(id: $customerId) {
    name
    email
  }
  orders(filter: { customerId: $customerId, status: PROCESSING }, first: 5) {
    edges {
      node {
        id
        status
        totalCents
        createdAt
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

# Aliases — buscar o mesmo campo com parâmetros diferentes
query CompareOrders {
  order1: order(id: "order-abc") { status totalCents }
  order2: order(id: "order-xyz") { status totalCents }
}

# Fragments — reutilizar seleções de campos
fragment OrderSummary on Order {
  id
  status
  totalCents
  createdAt
}

query RecentOrders($customerId: ID!) {
  customer(id: $customerId) {
    orders(first: 10) {
      edges {
        node {
          ...OrderSummary  # reutiliza o fragment
        }
      }
    }
  }
}

# Directives — comportamento condicional na query
query GetOrderMaybeWithAddress($orderId: ID!, $includeAddress: Boolean!) {
  order(id: $orderId) {
    id
    status
    shippingAddress @include(if: $includeAddress) {
      street
      city
    }
    # @skip é o inverso — omite se condição for true
    subtotalCents @skip(if: $includeAddress)
  }
}

Mutations — escrita com payload estruturado

mutation CreateOrder($input: CreateOrderInput!) {
  createOrder(input: $input) {
    order {
      id
      status
      totalCents
      createdAt
    }
    errors {
      field
      message
    }
  }
}
# Variables:
# {
#   "input": {
#     "customerId": "cust-123",
#     "items": [
#       { "productId": "prod-1", "quantity": 2 }
#     ],
#     "shippingAddress": {
#       "street": "Rua X, 100",
#       "city": "São Paulo",
#       "state": "SP",
#       "postalCode": "01310-100",
#       "country": "BR"
#     }
#   }
# }

# Múltiplas mutations em sequência (executadas na ordem)
mutation BatchOperations($input1: ..., $input2: ...) {
  op1: updateOrderStatus(input: $input1) { ... }
  op2: cancelOrder(id: "order-xyz") { ... }
  # atenção: se op1 falha, op2 ainda executa — não há transação automática
}

Resolvers — a camada de execução

Um resolver é uma função associada a um campo do schema que sabe como obter o valor desse campo. O runtime GraphQL executa resolvers em uma árvore que espelha a estrutura da query — cada campo tem seu resolver, e resolvers filhos recebem o objeto pai como primeiro argumento.

Assinatura de um resolver

# A assinatura padrão de um resolver (pseudocódigo agnóstico de linguagem):
# resolve(parent, args, context, info) → valor

# parent: o objeto retornado pelo resolver pai (null para campos raiz)
# args:   os argumentos passados ao campo na query
# context: objeto compartilhado entre todos os resolvers de uma requisição
#          (autenticação, dataloaders, conexão com banco, logger)
# info:   metadados sobre o campo atual, schema, path — raro na prática

Cadeia de resolvers — como a execução funciona

Dado o schema e a query abaixo, o runtime executa os resolvers nesta ordem:

# Query
query {
  order(id: "abc") {    # → Query.order(parent=null, args={id:"abc"})
    status              # → Order.status(parent=order, args={})
    customer {          # → Order.customer(parent=order, args={})
      name              # → Customer.name(parent=customer, args={})
    }
    items {             # → Order.items(parent=order, args={})
      productName       # → OrderItem.productName(parent=item, args={})
      quantity          # → OrderItem.quantity(parent=item, args={})
    }
  }
}

Resolvers de campos escalares (status, name, productName) tipicamente simplesmente retornam a propriedade do objeto pai — o runtime tem resolvers default que fazem isso. Resolvers de campos de relação (customer, items) precisam ir ao banco ou a outro serviço buscar os dados.

Resolvers de campos de mesmo nível na query são executados em paralelo (Query.order e Query.customer, por exemplo). Resolvers de campos filhos executam após o pai retornar. Isso significa que o grafo de execução é determinístico em relação à árvore da query, mas paralelo dentro de cada nível.

Context — objeto compartilhado por requisição

// O context é construído uma vez por requisição e passado a todos os resolvers
// Contém: usuário autenticado, dataloaders, conexão com banco, logger, trace

// Exemplo de context (C# com Hot Chocolate)
public class AppContext
{
    public UserPrincipal? CurrentUser { get; init; }
    public OrderDataLoader OrderLoader { get; init; }
    public CustomerDataLoader CustomerLoader { get; init; }
    public IOrderRepository Orders { get; init; }
    public ILogger Logger { get; init; }
    public Activity? Trace { get; init; }
}

O problema N+1 e DataLoader

O problema N+1 é o desafio de performance mais comum em GraphQL. Ocorre quando um resolver de relação dispara uma query de banco separada para cada item da lista pai — resultando em 1 query para a lista e N queries para os relacionamentos.

O problema

# Query que lista pedidos com dados do cliente
query {
  orders(first: 20) {
    edges {
      node {
        id
        customer {   # ← problema: 20 queries separadas para customer!
          name
          email
        }
      }
    }
  }
}

# Sem DataLoader, o resolver Customer resolve assim:
# 1. SELECT * FROM orders LIMIT 20          → 20 orders
# 2. SELECT * FROM customers WHERE id = ?   → customer do order[0]
# 3. SELECT * FROM customers WHERE id = ?   → customer do order[1]
# ... até order[19]
# Total: 21 queries. Para 100 pedidos = 101 queries.

DataLoader — batching e caching

DataLoader é um utilitário (originalmente da Facebook, agora disponível em todas as linguagens) que resolve o N+1 através de dois mecanismos: batching (agrupa todas as chaves solicitadas dentro de um tick do event loop em uma única query) e caching (deduplicação de chaves iguais dentro da mesma requisição).

# Com DataLoader, a sequência de execução é:
# 1. SELECT * FROM orders LIMIT 20                    → 20 orders
# 2. (todos os resolvers de Customer registram suas chaves no loader)
# 3. SELECT * FROM customers WHERE id IN (?)          → 1 query com N IDs únicos
# Total: 2 queries independente de quantos pedidos.

# Pseudocódigo do DataLoader:
class CustomerDataLoader:
    def __init__(self, db):
        self._db = db
        self._cache = {}
        self._queue = []

    async def load(self, customer_id: str) -> Customer:
        # Adiciona à fila, retorna uma Promise
        ...

    async def _batch_load(self, keys: list[str]) -> list[Customer]:
        # Chamado com TODOS os keys acumulados no tick atual
        customers = await self._db.query(
            "SELECT * FROM customers WHERE id = ANY($1)", keys
        )
        # Retorna na mesma ordem dos keys (DataLoader exige isso)
        customer_map = {c.id: c for c in customers}
        return [customer_map.get(k) for k in keys]

Além do N+1: query complexity e profundidade

GraphQL permite que clientes escrevam queries arbitrariamente complexas. Uma query maliciosa (ou apenas descuidada) pode criar explosão combinatória:

# Query com profundidade excessiva (cada level dispara novos fetches)
query {
  orders {
    customer {
      orders {
        customer {
          orders {  # ← recursão de dados via grafo circular
            ...
          }
        }
      }
    }
  }
}

# Proteções necessárias no servidor:
# 1. Max depth limit (ex: profundidade máxima 7)
# 2. Query complexity scoring — cada campo tem custo, lista tem custo multiplicado
# 3. Query timeout
# 4. Persisted queries (apenas queries pré-aprovadas em produção)

Paginação — Relay Cursor Connections

GraphQL não prescreve um padrão de paginação — mas a especificação Relay Cursor Connections se tornou o padrão de facto recomendado. Ao contrário de paginação por offset (page=2&size=20), cursor connections são estáveis: inserções ou deleções entre páginas não causam itens duplicados ou pulados.

Estrutura do Connection type

# O padrão Relay usa três tipos relacionados:
# 1. Connection — o resultado paginado
# 2. Edge — o wrapper de cada item com cursor e metadados
# 3. PageInfo — informações de navegação

type OrderConnection {
  edges: [OrderEdge!]!
  pageInfo: PageInfo!
  totalCount: Int!  # campo adicional comum (não no padrão Relay, mas útil)
}

type OrderEdge {
  node: Order!      # o item em si
  cursor: String!   # opaque cursor — posição deste item
}

type PageInfo {
  hasNextPage: Boolean!
  hasPreviousPage: Boolean!
  startCursor: String   # cursor do primeiro item desta página
  endCursor: String     # cursor do último item desta página
}

# Uso na query — forward pagination
query {
  orders(first: 10) {
    edges {
      cursor
      node { id status totalCents }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
    totalCount
  }
}

# Próxima página — passe o endCursor como after
query {
  orders(first: 10, after: "cursor-opaco-da-pagina-anterior") {
    edges {
      node { id status }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

# Backward pagination (menos comum)
query {
  orders(last: 10, before: "cursor-inicio") {
    ...
  }
}

Implementação de cursors

Cursors são opacos para o cliente — o servidor pode usar qualquer estratégia interna. As mais comuns:

• Base64 de ID: base64("order:abc123") — simples, funciona quando a ordenação é por ID sequencial ou UUID ordered
• Base64 de timestamp + ID: base64("2024-01-15T10:30:00Z:abc123") — para ordenação por data com desempate
• Offset serializado: base64("offset:40") — fácil de implementar mas perde a vantagem de estabilidade
• Keyset pagination: WHERE (created_at, id) < (?, ?) — a implementação SQL que corresponde ao cursor baseado em campo de ordenação, muito eficiente com índice composto

Tratamento de erros

GraphQL tem um modelo de erros em duas camadas que frequentemente confunde desenvolvedores vindos de REST.

Camada 1 — erros de protocolo (campo errors de nível superior)

Erros de sintaxe na query, campos inexistentes no schema, violações de tipo, autenticação falha, e erros não tratados em resolvers vão para o campo errors do protocolo GraphQL. O HTTP status retornado pode ser 200 mesmo com erros (a query foi processada, apenas parcialmente).

{
  "data": {
    "order": null  // campo virou null porque o resolver lançou erro
  },
  "errors": [
    {
      "message": "Order not found",
      "locations": [{ "line": 2, "column": 3 }],
      "path": ["order"],
      "extensions": {
        "code": "NOT_FOUND",
        "orderId": "order-xyz"
      }
    }
  ]
}

Camada 2 — erros de negócio no payload da mutation

Erros de validação, regras de negócio e estados inválidos devem ser expressos no type system como parte do payload da mutation. O HTTP status é sempre 200, data está presente, e o cliente olha para data.createOrder.errors:

{
  "data": {
    "createOrder": {
      "order": null,
      "errors": [
        {
          "field": ["items", "0", "quantity"],
          "message": "Quantidade deve ser maior que zero"
        },
        {
          "field": ["customerId"],
          "message": "Cliente não encontrado"
        }
      ]
    }
  },
  "errors": []  // sem erros de protocolo
}

Subscriptions — dados em tempo real

Subscriptions são o mecanismo de GraphQL para dados em tempo real — o cliente recebe eventos do servidor à medida que ocorrem. A subscrição é estabelecida uma vez e o servidor envia dados quando o evento relevante acontece.

Transporte: WebSocket e SSE

O protocolo graphql-ws (substituto do depreciado subscriptions-transport-ws) usa WebSocket com uma fase de handshake e framing de mensagens. Para ambientes onde WebSocket é problemático (proxies corporativos, balanceadores sem suporte), SSE (Server-Sent Events) com o protocolo graphql-sse é alternativa viável — permite somente streaming server→client, que é o caso de 90% das subscriptions reais.

Implementação no servidor

# A subscription precisa de:
# 1. Definição no schema
# 2. Resolver que retorna um async generator / observable
# 3. Infraestrutura de pub/sub (Redis, Kafka, EventEmitter)

type Subscription {
  orderStatusChanged(orderId: ID!): OrderStatusChangedEvent!
}

# Resolver (pseudocódigo)
async def order_status_changed(root, info, orderId):
    pubsub = info.context.pubsub
    async for event in pubsub.subscribe(f"order:{orderId}:status"):
        yield OrderStatusChangedEvent(
            order=await info.context.order_loader.load(orderId),
            previous_status=event.previous_status,
            new_status=event.new_status,
            changed_at=event.changed_at,
        )

Introspection — o schema é auto-descritivo

GraphQL tem um sistema de introspection built-in: qualquer cliente pode consultar o schema do servidor usando queries especiais no namespace __. Isso possibilita ferramentas como GraphiQL, Apollo Studio e VS Code GraphQL extension funcionarem sem configuração manual.

# Query de introspection — listar todos os tipos
query IntrospectionQuery {
  __schema {
    types {
      name
      kind
      description
      fields {
        name
        type { name kind ofType { name kind } }
        args { name type { name } }
      }
    }
    queryType { name }
    mutationType { name }
    subscriptionType { name }
  }
}

# Inspecionar um tipo específico
query {
  __type(name: "Order") {
    name
    kind
    fields {
      name
      type {
        name
        kind
        ofType { name kind }  # para tipos wrapped como [Order!]!
      }
    }
  }
}

# O campo __typename em qualquer nível — útil para Union types
query {
  search(query: "notebook") {
    __typename  # retorna "Product", "Order", etc.
    ... on Product { id name }
    ... on Order { id status }
  }
}

Federation — GraphQL em microsserviços

Em arquiteturas com múltiplos microsserviços, cada serviço pode possuir parte do schema GraphQL. Federation (Apollo Federation v2 é o padrão dominante) permite compor esses subgraphs em um supergraph unificado, com um router que distribui partes da query para os serviços corretos.

Arquitetura federation

# Serviço de Orders — subgraph de pedidos
# Define Order e estende Customer com campo orders
type Order @key(fields: "id") {
  id: ID!
  status: OrderStatus!
  totalCents: Int!
  customerId: ID!
}

# Estende Customer (definido no serviço de Customers)
extend type Customer @key(fields: "id") {
  id: ID! @external          # campo externo — vem do serviço de Customers
  orders(first: Int): OrderConnection!
}

type Query {
  order(id: ID!): Order
}

# Serviço de Customers — subgraph de clientes
type Customer @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
  # orders vem do serviço de Orders, não precisa definir aqui
}

# Router (Apollo Router ou GraphQL Mesh)
# Recebe a query do cliente, determina quais subgraphs precisam ser consultados,
# executa as sub-queries em paralelo quando possível, e combina os resultados

# Query do cliente — o router resolve transparentemente
query {
  customer(id: "cust-123") {
    name          # → Customers subgraph
    email         # → Customers subgraph
    orders {      # → Orders subgraph (com reference resolver)
      edges {
        node {
          id
          status
          totalCents
        }
      }
    }
  }
}

Reference resolvers — como o router une os dados

# O serviço de Orders precisa de um "reference resolver" para Customer
# Quando o router busca orders de um customer, ele passa a entidade Customer
# com apenas o campo @key (id) para o serviço de Orders completar

# Resolver de referência no serviço de Orders:
def resolve_reference(customer, info):
    # customer tem apenas {"id": "cust-123"} (o @key)
    # retorna os dados de orders para esse customer
    return {"id": customer["id"]}  # orders são resolvidos pelo campo resolver normal

Persisted Queries e Automatic Persisted Queries (APQ)

Em produção, enviar a query completa como texto em cada requisição tem desvantagens: queries grandes aumentam o payload, e clientes arbitrários podem enviar queries maliciosas. Persisted Queries resolvem isso com queries pré-registradas — identificadas por hash e armazenadas no servidor.

Automatic Persisted Queries (APQ)

APQ é um protocolo que funciona sem configuração de lista branca: na primeira requisição, o cliente envia apenas o hash SHA-256 da query. Se o servidor não reconhece, retorna PERSISTED_QUERY_NOT_FOUND; o cliente então envia o hash + a query completa; o servidor armazena e processa. Nas requisições seguintes, apenas o hash é enviado.

# Requisição 1 (cache miss)
POST /graphql
{
  "extensions": {
    "persistedQuery": {
      "version": 1,
      "sha256Hash": "b60b...hash"
    }
  }
}
# Resposta: { "errors": [{ "message": "PersistedQueryNotFound" }] }

# Requisição 2 (enviando query completa)
POST /graphql
{
  "query": "query GetOrder($id: ID!) { order(id: $id) { id status } }",
  "extensions": {
    "persistedQuery": { "version": 1, "sha256Hash": "b60b...hash" }
  }
}
# Servidor armazena, responde com dados

# Requisições seguintes — apenas hash
POST /graphql
{
  "extensions": {
    "persistedQuery": { "version": 1, "sha256Hash": "b60b...hash" }
  },
  "variables": { "id": "order-abc" }
}

Trusted Documents — allowlist estrita

Para segurança máxima, Trusted Documents (também chamado de Safelisted Queries) requerem que apenas queries pré-aprovadas em deploy possam ser executadas. O CI/CD extrai todas as queries dos clientes, calcula os hashes, e os armazena no servidor. Queries ad-hoc são rejeitadas. Isso elimina o risco de introspection e de queries de alta complexidade em produção.

Quando usar GraphQL

GraphQL vence quando:

• Múltiplos clientes com necessidades diferentes — mobile pede menos campos que web, dashboard pede mais que a app — sem versionar APIs ou criar endpoints específicos
• Dados altamente relacionais — quando o cliente precisa navegar um grafo de relações em uma única requisição (ex: pedido → cliente → histórico → recomendações)
• Times de frontend com autonomia — o time de front pode iterar sem depender do time de backend para criar novos endpoints ou adicionar campos
• BFF (Backend for Frontend) — GraphQL como camada de agregação que consolida múltiplos microsserviços backend
• APIs com schema estável que evoluem gradualmente — adicionar campos é não-breaking por padrão

GraphQL perde quando:

• Simplicidade é prioridade — para CRUD simples, REST é menos complexo de implementar, debugar e monitorar
• Caching via HTTP — GraphQL usa POST para queries (em teoria GET pode ser usado, mas é raro); CDNs e proxies não cacheam POST. Caching requer implementação no servidor (APQ + cache de resultado por hash)
• Uploads de arquivos — o protocolo GraphQL não tem suporte nativo a multipart; requer workarounds com graphql-multipart-request-spec
• Equipes pequenas sem tooling — DataLoader, complexity analysis, federation, persisted queries — a pilha de GraphQL produção-pronta é substancialmente mais complexa que REST
• Serviços de baixa latência crítica — o overhead de parsear e validar a query, resolver o plano de execução, e gerenciar DataLoaders adiciona latência comparado a um endpoint SQL direto
• Comunicação entre serviços internos — para service-to-service, gRPC com Protobuf é mais eficiente e oferece contrato mais rigoroso

Decisões de engenharia

Exercícios práticos

1. Implemente um schema GraphQL para um sistema de blog com tipos Post, Author e Comment. Adicione queries com paginação Relay Connections, mutations createPost e addComment com payload de erros, e um DataLoader para evitar N+1 ao buscar autores de uma lista de posts. Critério: query posts(first: 10) { author { name } } deve gerar exatamente 2 queries ao banco (uma para posts, uma para todos os autores), verificável via logging. Mutations devem retornar errors: [] em sucesso e errors: [UserError] em falha sem alterar o HTTP status.
2. Reproduza o problema N+1 intencionalmente: crie um resolver de author em Post que faz uma query de banco por chamada. Use logging para contar as queries. Depois adicione DataLoader e verifique que o número de queries cai para 2 independente da quantidade de posts. Critério: com 20 posts e sem DataLoader, o log deve registrar 21 queries; com DataLoader, exatamente 2 — independente de quantos posts a query retornar (testar com 1, 10 e 50 posts).
3. Implemente query complexity analysis: atribua custo 1 para campos escalares e custo n × custo_do_filho para listas (onde n é o argumento first). Rejeite queries com complexidade total acima de 500. Critério: query posts(first: 10) { title } (custo ≈10) é executada normalmente; query posts(first: 100) { comments(first: 100) { text } } (custo 10.000) é rejeitada com erro QUERY_COMPLEXITY_EXCEEDED antes de qualquer acesso ao banco.
4. Adicione uma Subscription postPublished que emite eventos quando novos posts são criados. Use Redis pub/sub como broker e teste com dois clientes WebSocket simultâneos. Critério: ao criar um post via mutation, ambos os clientes WebSocket abertos recebem o evento em até 200ms. Reiniciar um cliente e criar um segundo post faz apenas o cliente reconectado receber o novo evento (sem replay de eventos anteriores, semântica at-most-once).
5. Desafio de federation: divida o schema de blog em dois subgraphs — users-service (Author, autenticação) e content-service (Post, Comment). Configure um Apollo Router local que una os dois. Critério: Apollo Router exposto na porta 4000; query { author(id: "1") { name posts { title } } } retorna corretamente com dados vindos de ambos os subgraphs; logs do router mostram duas chamadas a subgraphs distintos para essa query.

Perguntas de entrevista