GraphQL v enterprise: Kdy dává smysl a kdy zůstat u REST¶

GraphQL má za sebou dekádu v produkci — od Facebooku přes Shopify po Atlassian. V 2026 už nejde o hype, ale o zralou technologii s jasnými případy použití. Problém je, že většina firem ho nasazuje špatně.

Co GraphQL řeší (a co ne)¶

Skutečné výhody¶

Eliminace over-fetchingu. REST endpoint vrací celý objekt. Mobilní klient potřebuje 3 pole z 50. S GraphQL si řekne přesně o to, co chce.

# Klient si vybere přesně co potřebuje
query {
  customer(id: "123") {
    name
    email
    lastOrder {
      total
      status
    }
  }
}

Jeden endpoint, více zdrojů. Místo 5 REST volání pro dashboard (zákazník + objednávky + faktura + adresa + preference) jeden GraphQL dotaz.

Silné typování. Schema je kontrakt. Frontend i backend vědí přesně, co API vrací. Auto-generování TypeScript typů, validace, dokumentace zdarma.

Evoluce bez verzování. Přidání nového pole nebreakne existující klienty. Deprecation na úrovni polí, ne celých endpointů.

Co GraphQL neřeší¶

• Výkon na serveru — přesouvá komplexitu z klienta na server. N+1 problém je reálný.
• Caching — HTTP caching funguje na URL. GraphQL POST requesty ho obcházejí.
• Bezpečnost — arbitrární dotazy = potenciální DoS. Musíte řešit query depth, complexity limits, rate limiting.
• Jednoduchost — pro CRUD API je REST jednodušší a přímočařejší.

Kdy GraphQL v enterprise ANO¶

1. BFF (Backend for Frontend) vrstva¶

Máte mikroslužby s REST API a potřebujete agregovat data pro frontend. GraphQL jako BFF vrstva je ideální:

Mobile App ──→ GraphQL BFF ──→ User Service (REST)
Web App   ──→ GraphQL BFF ──→ Order Service (REST)
                             ──→ Payment Service (REST)

Frontend týmy si definují dotazy podle potřeby. Backend služby zůstávají REST (jednoduché, cacheable).

2. Více klientů s různými potřebami¶

Web potřebuje detailní view, mobil kompaktní, IoT zařízení minimum dat. Jeden GraphQL endpoint obsluhuje všechny bez custom endpointů.

3. Rychle se měnící produktové požadavky¶

Startup nebo produkt v early stage, kde se schema mění týdně. GraphQL umožňuje frontendistům iterovat bez čekání na backend.

4. Data mesh / federation¶

Velká organizace s desítkami týmů. Apollo Federation nebo podobné řešení umožňuje každému týmu vlastnit svou část grafu:

# Team A vlastní User
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

# Team B rozšiřuje User o objednávky
extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}

Kdy GraphQL NE¶

CRUD API pro interní služby¶

Máte mikroslužbu, která dělá CRUD nad jednou entitou. REST je jednodušší, rychlejší na implementaci, lépe cacheable.

High-throughput služby¶

API s miliony requestů za sekundu, kde záleží na každé milisekundě. GraphQL parsing a validace přidává overhead. gRPC je lepší volba.

File upload / streaming¶

GraphQL nemá nativní podporu pro binární data. Multipart upload existuje (specifikace), ale je to hack.

Jednoduchý backend, jeden klient¶

Pokud máte jeden frontend a jednoduchý backend, GraphQL přidává komplexitu bez benefitu.

Produkční architektura¶

Schema design¶

Schema-first přístup je standard v enterprise:

1. Designujte schema s produktovým týmem
2. Vygenerujte typy pro backend i frontend
3. Implementujte resolvery
4. Schema je kontrakt — změny přes PR review

# Schema jako kontrakt
type Query {
  """Vrátí zákazníka podle ID. Vyžaduje auth scope: customer:read"""
  customer(id: ID!): Customer

  """Fulltextové hledání zákazníků. Max 100 výsledků."""
  searchCustomers(query: String!, limit: Int = 20): CustomerConnection!
}

type Customer {
  id: ID!
  name: String!
  email: String!
  createdAt: DateTime!
  orders(first: Int = 10, after: String): OrderConnection!
  # deprecated field — use `name` instead
  fullName: String @deprecated(reason: "Use `name` field")
}

N+1 řešení: DataLoader¶

Nejčastější performance problém. Řešení: DataLoader pattern (batching + caching):

# Bez DataLoaderu: N+1 dotazů
# customer.orders → SELECT * FROM orders WHERE customer_id = 1
# customer.orders → SELECT * FROM orders WHERE customer_id = 2
# ... N dotazů

# S DataLoaderem: 1 dotaz
# batch_load_orders([1, 2, 3, ...]) →
# SELECT * FROM orders WHERE customer_id IN (1, 2, 3, ...)

Security hardening¶

V produkci MUSÍTE řešit:

Query depth limiting — omezení hloubky vnořených dotazů (typicky max 10):

# Toto by bez limitu prošlo a zabilo server:
query {
  user {
    orders {
      items {
        product {
          reviews {
            author {
              orders {
                # ... nekonečně
              }
            }
          }
        }
      }
    }
  }
}

Query complexity analysis — každé pole má cost, součet nesmí překročit limit.

Persisted queries — v produkci nepřijímáte arbitrární dotazy. Klient pošle hash, server lookup-ne registrovaný dotaz. Eliminuje injection i DoS.

Rate limiting — per-field nebo per-operation, ne per-request.

Monitoring¶

GraphQL endpointy vrací vždy HTTP 200 (i při chybě). Standardní monitoring nefunguje. Potřebujete:

• Per-resolver metriky — latence, error rate na úrovni polí
• Query complexity tracking — průměrná/maximální komplexita dotazů
• Slow query log — dotazy nad threshold
• Field usage analytics — které pole nikdo nepoužívá → kandidát na deprecation

Nástroje: Apollo Studio, GraphQL Hive (open-source), Grafana + custom exporter.

Technologie v 2026¶

Kategorie	Doporučení
Server (Node.js)	Apollo Server 4, Yoga (Envelop)
Server (JVM)	Netflix DGS, Spring for GraphQL
Server (Python)	Strawberry, Ariadne
Server (.NET)	Hot Chocolate
Federation	Apollo Federation 2, Cosmo Router
Klient	Apollo Client, urql, Relay
Codegen	GraphQL Code Generator
Monitoring	Apollo Studio, GraphQL Hive

Doporučený přístup pro české firmy¶

1. Začněte BFF vrstvou — nechte backend služby na REST, přidejte GraphQL agregační vrstvu
2. Schema-first — schema designujte společně s frontend týmem
3. Persisted queries od začátku — bezpečnost a výkon
4. DataLoader vždy — bez výjimky, i pro “jednoduché” resolvery
5. Federation až když potřebujete — ne předčasně, komplexita je reálná

GraphQL není náhrada REST. Je to doplněk pro specifické use-case. Nasaďte ho tam, kde řeší reálný problém, a nechte REST tam, kde funguje.

---

CORE SYSTEMS navrhuje a implementuje API architektury pro enterprise klienty — REST, GraphQL i gRPC. Ozvěte se pro architektonickou konzultaci.