Kaip sistemos komponentai bendrauja vienas su kitu (API)?

Question

Accepted Answer

Sistemoje komponentai (paslaugos, klientai) bendrauja per **API** ir įvairius protokolus — sinchroninius (REST, gRPC) ir asinchroninius (žinučių/eilės). Supratimas, kaip komponentai bendrauja, yra esminis kelių dalių sudarytų sistemų projektavimui.

## Sinchroninis bendravimas (užklausa/atsakymas)

```text
The caller WAITS for a response (blocking):
  REST (HTTP) → most common; resources over HTTP (JSON) → simple, ubiquitous, web-friendly
  gRPC → high-performance RPC (binary, HTTP/2) → fast, typed; good for internal services
  GraphQL → flexible queries (client requests exactly what it needs)
→ for: direct request/response where the caller needs an answer now
```

## Asinchroninis bendravimas (žinučios)

```text
The caller does NOT wait (decoupled, non-blocking):
  MESSAGE QUEUES (RabbitMQ, SQS) → send a message; a consumer processes it later
  EVENT STREAMING (Kafka) → publish events; consumers react
  PUB/SUB → broadcast events to subscribers
→ for: decoupling, background work, handling spikes, event-driven systems
  ✓ resilience (queue buffers), scalability, decoupling  ✗ more complexity, eventual consistency
```

## Pasirinkimas ir svarstymai

```text
SYNC → when the caller needs an immediate response; simpler request/response
ASYNC → when decoupling, resilience, or background processing matters (don't block)
→ Also: API design (clear contracts), versioning, error handling, timeouts/retries,
  authentication, rate limiting → robust communication between components
```

## Kodėl tai svarbu

Supratimas, kaip komponentai bendrauja per API, yra pagrindinis, nes **sistemos susideda iš kelių dalių, kurios turi bendrauti**, todėl bendravimo supratimas yra būtinas joms projektuoti.

Sistemos susideda iš paslaugų ir klientų, kurie sąveikauja, ir tai, kaip jie bendrauja, yra esminis sistemos projektavimo aspektas.

Supratimas **sinchroninio bendravimo** (užklausa/atsakymas, kai skambusis laukia) — **REST** (visur paplitęs HTTP/JSON metodas), **gRPC** (aukšto našumo RPC vidinėms paslaugoms), ir GraphQL (lanksčios užklausos) — apima bendrus būdus, kuriais komponentai daro tiesioginius skambučius tikėdamiesi atsakymo.

Supratimas **asinchroninio bendravimo** (nekuplituoto, neblokuojančio) — **žinučių eilės** (žinučių siuntimas vėlesniam apdorojimui), **įvykių srautai** (Kafka), ir pub/sub — yra taip pat svarbus, nes jis leidžia **atsiskirti, patvarumą (eilės slopinant apkrovą), mastelabilumą ir įvykiais varomąsias sistemas**, iškaina daugiau sudėtingumo ir galutinio nuoseklumo.

Supratimas **sinchroninio ir asinchroninio skirtimo bei kada naudoti kiekvieną** — sinchroninį, kai skambusis reikalingas nedeliui atsakymas, asinchroninį, kai svarbu atsiskyrimas, patvarumas arba foninė apdorojimas — yra svarbi projektavimo svarstyba, iš esmės veikianti sistemos charakteristikas.

Supratimas papildomų svarstymo atvejų (aiškių API sutarčių, versijų valdymo, klaidų valdymo, laiko ribojimo/bandymų, autentifikacijos, greičio ribojimo) atspindi tvirto bendravimo projektavimą.

Kadangi sistemos susideda iš bendraujančių dalių ir tai, kaip jie bendrauja (sinchroninis ir asinchroninis, protokolai ir projektavimo svarstymai) iš esmės formuoja sistemą, ir kadangi komponentų bendravimo supratimas yra būtinas kelių komponentų sistemų projektavimui, komponentų bendravimo per API supratimas yra esminis, pagrindinis sistemos projektavimo žinios — pagrindinis kelių sąveikaujančių dalių sudarytų sistemų projektavimui, apimantis sinchroninį ir asinchroninį bendravimą, kuris sujungia komponentus, ir centrinis pasiskirstytų, paslaugomis pagrįstų sistemų, kurios šiandien paplitusios, architektūrai.