REST vs GraphQL vs gRPC — kada kurį rinktumėtės?

Question

IT Interview Practice · Accepted Answer

Tai trys skirtingos API paradigmos, kiekviena optimizuota skirtingiems apribojimams. Universalaus nugalėtojo nėra — teisingas pasirinkimas priklauso nuo **vartotojo, duomenų formos ir tinklo**.

## Trys iš pirmo žvilgsnio

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

Į išteklius orientuotas per paprastą HTTP. **Rinkis jį** viešoms API, CRUD servisams ir bet kam, kas naudojasi HTTP caching, visuotinumu ir paprastumu. Jo silpnybės yra **over-fetching** (gauni visą `/users/42`, net jei reikia vieno lauko) ir **under-fetching** (`N+1` problema: paimk user, tada suk ciklą kiekvienam order paimti).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

Vienas endpoint, kur **klientas tiksliai nurodo, ko nori** vienoje užklausoje, išsprendžiant over/under-fetching. **Rinkis jį** turtingoms frontend (ypač mobiliajai, kur round trips brangūs) ir kai daug klientų reikalauja skirtingų tų pačių duomenų formų.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Kompromisai: HTTP caching sunkesnis (viskas yra `POST` į `/graphql`), o naivus resolveris gali paslėpti brangias `N+1` duomenų bazės užklausas.

## gRPC

Sutartimi grįstas RPC, naudojantis **Protobuf** per **HTTP/2**. Dvejetainis ir multipleksuotas, todėl greitas ir kompaktiškas su streaming palaikymu. **Rinkis jį** **vidiniam service-to-service** bendravimui mikroservisų backend, kur svarbus našumas ir griežtas tipizavimas. Silpnybė: prastas naršyklės palaikymas (reikia proxy, tokio kaip grpc-web) ir neskaitomas žmogui.

## Kaip rinktis

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## Kodėl tai svarbu

Senior lygyje interviuotojams mažiau rūpi apibrėžimai ir labiau tai, ar galite **pagrįsti pasirinkimą apribojimų atžvilgiu** — šis klausimas iš tikrųjų yra „ar gali suderinti technologiją su problema, o ne vaikytis hype?“. Stipriausi atsakymai remiasi skausmu, kurį kiekviena išsprendžia: GraphQL egzistuoja, kad nužudytų over/under-fetching reikliems frontend, gRPC egzistuoja, kad vidiniai service iškvietimai būtų greiti ir griežtai tipizuoti, o REST lieka numatytuoju, nes HTTP caching, įrankiai ir visuotinis pažįstamumas yra milžiniški praktiniai pranašumai viešoms ir CRUD stiliaus API. Svarbu, kad senior inžinierius pastebi, jog tai **ne arba/arba** — dažna architektūra yra REST ar GraphQL viešame krašte su gRPC tarp backend mikroservisų — ir įvardija konkrečius kompromisus (GraphQL caching ir `N+1` rizikas, gRPC silpną naršyklės istoriją). Būtent tas samprotavimas apie tinkamumą ir kainą, o ne gebėjimas atmintinai išvardyti savybes, yra signalas.

Trys iš pirmo žvilgsnio

REST

GraphQL

gRPC

Kaip rinktis

Kodėl tai svarbu

Susiję klausimai