REST vs GraphQL vs gRPC — როდის აირჩევდი თითოეულს?

Question

IT Interview Practice · Accepted Answer

ეს სამი განსხვავებული API პარადიგმაა, თითოეული ოპტიმიზებული სხვადასხვა შეზღუდვისთვის. უნივერსალური გამარჯვებული არ არსებობს — სწორი არჩევანი დამოკიდებულია **მომხმარებელზე, მონაცემის ფორმაზე და ქსელზე**.

## სამივე ერთი შეხედვით

```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

Resource-ზე ორიენტირებული უბრალო HTTP-ზე. **აირჩიეთ ის** public API-ებისთვის, CRUD service-ებისთვის და ყველაფრისთვის, რაც HTTP caching-ისგან, ყველგანმყოფობისა და სიმარტივისგან სარგებლობს. მისი სისუსტეებია **over-fetching** (მთელ `/users/42`-ს იღებთ, თუნდაც ერთი ველი გჭირდებოდეთ) და **under-fetching** (`N+1` პრობლემა: აიღეთ user, შემდეგ იციკლეთ თითო order-ის ასაღებად).

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

## GraphQL

ერთი endpoint, სადაც **client ზუსტად აკონკრეტებს, რა უნდა** ერთ query-ში, რაც over/under-fetching-ს აგვარებს. **აირჩიეთ ის** მდიდარი frontend-ებისთვის (განსაკუთრებით mobile, სადაც round trip-ები ძვირია) და როცა ბევრ client-ს იმავე მონაცემის სხვადასხვა ფორმა სჭირდება.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
ტრეიდ-ოფები: HTTP caching უფრო რთულია (ყველაფერი `POST`-ია `/graphql`-ზე), და გულუბრყვილო resolver-ს შეუძლია ძვირი `N+1` database query-ების დამალვა.

## gRPC

კონტრაქტზე დაფუძნებული RPC **Protobuf-ის** გამოყენებით **HTTP/2**-ზე. ბინარული და multiplexed, ამიტომ სწრაფი და კომპაქტურია streaming-ის მხარდაჭერით. **აირჩიეთ ის** **შიდა service-to-service** კომუნიკაციისთვის microservice-ების backend-ში, სადაც წარმადობა და მკაცრი ტიპიზაცია მნიშვნელოვანია. სისუსტე: ცუდი browser-ის მხარდაჭერა (სჭირდება proxy, როგორიცაა grpc-web) და ადამიანით არ იკითხება.

## არჩევა

```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.)
```

## რატომ არის ეს მნიშვნელოვანი

senior დონეზე, ინტერვიუერებს ნაკლებად აინტერესებთ განმარტებები და მეტად ის, შეგიძლიათ თუ არა **არჩევანის გამართლება შეზღუდვების წინააღმდეგ** — ეს კითხვა სინამდვილეში არის „შეგიძლიათ თუ არა ტექნოლოგიის მორგება პრობლემაზე hype-ის დევნის ნაცვლად?". ყველაზე ძლიერი პასუხები ეყრდნობა ტკივილს, რომელსაც თითოეული აგვარებს: GraphQL არსებობს, რომ მოკლას over/under-fetching მომთხოვნი frontend-ებისთვის, gRPC არსებობს, რომ შიდა service call-ები სწრაფი და მკაცრად ტიპიზებული გახადოს, ხოლო REST რჩება ნაგულისხმევად, რადგან HTTP caching, tooling და უნივერსალური ნაცნობობა უზარმაზარი პრაქტიკული უპირატესობებია public და CRUD-სტილის API-ებისთვის. მთავარია, senior ინჟინერი აღნიშნავს, რომ ეს **არ არის ან-ან** — გავრცელებული არქიტექტურაა REST ან GraphQL public edge-ზე gRPC-თ backend microservice-ებს შორის — და ასახელებს კონკრეტულ ტრეიდ-ოფებს (GraphQL-ის caching და `N+1` რისკები, gRPC-ის სუსტი browser ისტორია). სწორედ ეს მსჯელობა შესაბამისობასა და ღირებულებაზე, და არა ფუნქციების ჩამოთვლის უნარი, არის სიგნალი.

სამივე ერთი შეხედვით

REST

GraphQL

gRPC

არჩევა

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები