Miért jött létre a GraphQL?

Miért jött létre, és milyen problémát old meg?

A GraphQL a Facebook mérnökeinek fejfájásából született. 2012-ben a mobilalkalmazásuk újraírása közben szembesültek azzal, hogy a REST API-ok nem elégítik ki a komplex mobilos igényeket. Két alapvető problémát azonosítottak.

Overfetching – túl sok adat lekérése

REST API esetén egy végpont mindig ugyanannyi adatot ad vissza, függetlenül attól, hogy a kliensnek mennyire van szüksége.

Példa: Ha egy felhasználói profiloldalt töltesz be, és csak a nevet és a profilképet szeretnéd megjeleníteni, a REST API mégis visszaadja az összes mezőt:

{
  "id": "1",
  "name": "Kovács Péter",
  "email": "peter@example.com",
  "phone": "+36201234567",
  "address": "Budapest, Kossuth tér 1.",
  "created_at": "2023-01-15",
  "last_login": "2024-03-10",
  "preferences": { ... },
  "subscription": { ... }
}

Ebből a válaszból csak a name és a profileImage kellett volna – a többi feleslegesen utazott a hálózaton.

Underfetching – túl kevés adat, több kérés szükséges

A másik véglet: egy végpont nem tartalmaz elég adatot, ezért több egymás utáni kérést kell indítani.

Példa: Egy blogbejegyzés oldalán meg szeretnéd jeleníteni a cikket, a szerzőt és a hozzászólásokat. REST-tel ez három kérés:

GET /posts/1
GET /users/42
GET /posts/1/comments

Ezek a kérések szekvenciálisan vagy párhuzamosan futnak, de mindenképpen koordinációt igényelnek. GraphQL-lel ez egyetlen kérés:

query GetPost {
  post(id: "1") {
    title
    content
    author {
      name
      avatar
    }
    comments {
      text
      createdAt
    }
  }
}

Verziókezelési probléma

REST API-oknál, ha változik az adatmodell, általában új verziót kell bevezetni (/api/v2/users). GraphQL esetén az új mezőket egyszerűen hozzáadják a sémához, a régiek megmaradnak – visszafelé kompatibilis marad az API.

Rövid összefoglaló

Az overfetching azt jelenti, hogy a szerver több adatot küld, mint amennyire szükség van.
Az underfetching azt jelenti, hogy egy kérés nem elég, több lekérdezés kell.
GraphQL mindkét problémát megoldja: a kliens pontosan azt kéri, amire szüksége van.
Nincs szükség API verziókezelésre, mert a séma visszafelé kompatibilis módon bővíthető.