GraphQL vs REST — kdy co použít

Facebook open-sourcoval GraphQL v roce 2015 a od té doby se kolem něj vytvořil obrovský hype. GitHub nasadil GraphQL API v4, Shopify taky. Znamená to, že REST je mrtvý? Ani náhodou. Ale jsou scénáře, kde GraphQL vyhrává na plné čáře.

Problém jménem over-fetching¶

Klasický REST endpoint GET /api/users/42 vrátí kompletní objekt uživatele — jméno, email, adresu, historii objednávek, preference. Mobilní aplikace potřebuje jen jméno a avatar. Stáhne 15 KB místo 200 B. Vynásobte tisíci requesty a máte problém.

GraphQL řeší over-fetching elegantně: klient definuje, co chce. Server vrátí přesně ta pole, která si vyžádáte. Nic navíc.

Under-fetching a N+1 problém¶

Opačný problém: potřebujete uživatele, jeho objednávky a ke každé objednávce produkty. V REST to znamená tři endpointy a waterfall requestů. V GraphQL jeden query:

{
  user(id: 42) {
    name
    avatar
    orders(last: 5) {
      id
      total
      items {
        product { name, price }
        quantity
      }
    }
  }
}

Jeden request, přesně ta data, která potřebujete. Pro mobilní klienty a komplexní UI je to game changer.

Typový systém a introspekce¶

GraphQL má silný typový systém definovaný schématem. Každé pole má typ, každý argument je validovaný. Schema je zároveň dokumentace — GraphiQL (interaktivní playground) vám ukáže všechny dostupné query, mutace a typy. Žádný Swagger, žádný Postman, schema je single source of truth.

type User {
  id: ID!
  name: String!
  email: String!
  orders(last: Int): [Order!]!
}

type Order {
  id: ID!
  total: Float!
  items: [OrderItem!]!
  createdAt: DateTime!
}

type Query {
  user(id: ID!): User
  users(filter: UserFilter): [User!]!
}

Kde REST stále vyhrává¶

HTTP caching — REST endpointy mají URL, které se přirozeně cachují (CDN, browser cache, reverse proxy). GraphQL posílá POST requesty na jeden endpoint — cache je výrazně složitější. Apollo Client řeší client-side cache, ale CDN? Složité.

Jednoduchost — REST API pro CRUD operace nad jedním resource je triviální. GET, POST, PUT, DELETE — každý vývojář to zná. GraphQL přidává resolver layer, schema definition, query complexity analysis. Pro jednoduchý backend je to overhead.

File upload — REST: multipart form. GraphQL: spec na to nemá standard, existují workaroundy (multipart request spec), ale není to nativní.

Error handling — REST vrací HTTP status kódy. GraphQL vždy vrátí 200 OK, chyby jsou v response body. Pro monitoring a alerting je to méně intuitivní.

Kdy přejít na GraphQL¶

Máte více klientů (web, iOS, Android) s různými datovými potřebami? GraphQL. Máte komplexní relační data s vnořenými objekty? GraphQL. Máte jeden jednoduchý klient a CRUD API? Zůstaňte u REST.

My jsme GraphQL nasadili na projektu s React frontendem a mobilní aplikací. Tři měsíce po migraci: 40 % méně API requestů z mobilní aplikace, frontend tým si sám definuje queries bez čekání na backend. Win-win.

Nástroje ekosystému (2017)¶

Server: Apollo Server (Node.js), graphql-java, Graphene (Python). Klient: Apollo Client, Relay (Facebook). Tooling: GraphiQL, eslint-plugin-graphql, graphql-code-generator (TypeScript typy z schema).

Ekosystém rychle roste. Apollo je de facto standard pro JavaScript. Relay je mocnější, ale složitější — doporučujeme začít s Apollo.

Praktické tipy z nasazení¶

• Query complexity limiting — bez něj vám kdokoliv pošle nested query, která položí databázi
• DataLoader pattern — řeší N+1 problém na resolver úrovni (batching + caching)
• Persisted queries — klient posílá hash místo celého query stringu (bezpečnost + performance)
• Schema-first vs code-first — my preferujeme schema-first, je to čitelnější
• Verzování — GraphQL schema se neverzuje URL (/v1, /v2), pole se deprecated a přidávají se nová

GraphQL není náhrada REST — je to alternativa¶

Používejte GraphQL tam, kde řeší reálný problém: komplexní data, více klientů, over-fetching. Pro jednoduché CRUD API, webhooky a server-to-server komunikaci je REST stále výborná volba. Nejlepší architektura? Často hybrid — REST pro jednoduché endpointy, GraphQL pro komplexní queries.