Kako komponente komuniciraju u sustavu (API-ji)?

Question

Accepted Answer

U sustavu, komponente (servisi, klijenti) komuniciraju kroz **API-je** i različite protokole — sinkrone (REST, gRPC) i asinkrone (porukovanje/redovi čekanja). Razumijevanje kako komponente komuniciraju je temeljno za projektiranje sustava sastavljenih od više dijelova.

## Sinkrona komunikacija (zahtjev/odgovor)

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

## Asinkrona komunikacija (porukovanje)

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

## Odabir i razmatranja

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

## Zašto je to važno

Razumijevanje kako komponente komuniciraju preko API-ja je temeljno jer su **sustavi sastavljeni od više dijelova koji moraju komunicirati**, pa je razumijevanje komunikacije bitno za njihovo projektiranje.

Sustavi se sastoje od servisa i klijenata koji međusobno djeluju, a kako komuniciraju je fundamentalan aspekt projektiranja sustava.

Razumijevanje **sinkrone komunikacije** (zahtjev/odgovor gdje pozivajući čeka) — **REST** (sveprisutni HTTP/JSON pristup), **gRPC** (visokoučinkovit RPC za interne servise) i GraphQL (fleksibilne upite) — pokriva česte načine kako komponente prave izravne pozive očekujući odgovor.

Razumijevanje **asinkrone komunikacije** (odvojena, neblokirajuća) — **redovi poruka** (slanje poruka za kasniju obradu), **strujanje događaja** (Kafka) i pub/sub — je jednako važno, jer omogućava **odvajanje, otpornost (redovi koji buferiraju opterećenje), skalabilnost i sustave vođene događajima**, uz cijenu veće složenosti i konačne konzistentnosti.

Razumijevanje **razlike između sinkrone i asinkrone komunikacije i kada koristiti koju** — sinkrona kada pozivajući trebam trenutni odgovor, asinkrona kada je odvajanje, otpornost ili obrada u pozadini bitna — je ključno razmatranje u projektiranju koje značajno utječe na karakteristike sustava.

Razumijevanje dodatnih razmatranja (jasni ugovori API-ja, verzioniranje, rukovanje greškama, vremenske granice/pokušaji, autentifikacija, ograničenja brzine) odražava projektiranje čvrste komunikacije.

Budući da su sustavi sastavljeni od dijelova koji komuniciraju i kako komuniciraju (sinkrono nasuprot asinkrono, protokoli i razmatranja u projektiranju) temeljno oblikuje sustav, i budući da je razumijevanje komunikacije komponenti bitno za projektiranje sustava s više komponenti, razumijevanje kako komponente komuniciraju preko API-ja je bitno, temeljno znanje o projektiranju sustava — temeljno za projektiranje sustava sastavljenih od više dijelova koji međusobno djeluju, pokrivajući sinkronu i asinkronu komunikaciju koja povezuje komponente, te je centralno za arhitekturiranje distribuiranih, servisnih sustava koji su česti danas.