Jämför REST, gRPC och meddelandeköer för inter-service-kommunikation.

Question

Accepted Answer

De tre dominerande alternativen är **REST** (HTTP/JSON), **gRPC** (HTTP/2 + Protobuf) och **meddelandeköer** (Kafka/RabbitMQ). REST och gRPC är synkrona; köer är asynkrona.

## Jämförelse

| Aspekt | REST | gRPC | Message Queue |
|---|---|---|---|
| Stil | Synkron | Synkron | Asynkron |
| Nyttolast | JSON (text) | Protobuf (binär) | Vilket som helst (ofta binär) |
| Prestanda | Bra | Hög | Högt genomflöde |
| Kontrakt | OpenAPI (lös) | `.proto` (strikt) | Schema/event |
| Streaming | Begränsad | Native (bidi) | Pub/sub |
| Bäst för | Offentliga API:er, webbläsare | Intern låg-latens, högt volym | Lösning, buffring, event-driven |

## gRPC-kontraktexempel

```proto
service OrderService {
  // strongly-typed RPC, generated client + server stubs
  rpc GetOrder (OrderId) returns (Order);
}
message OrderId { string id = 1; }
message Order  { string id = 1; double total = 2; }
```

## Meddelandeexempel

```text
Order Service ─publish→ [ "OrderPlaced" topic ] ─▶ Inventory
                                              └────▶ Notifications
(producer doesn't know or wait for consumers)
```

## Val

- **REST** — externa klienter, bred kompatibilitet, läsbar för människor.
- **gRPC** — intern, låg latens, höga volymer; starka kontrakt; streaming.
- **Köer** — lösning, buffring, event-drivna flöden, överlevnad vid avbrott.

## Fallgrop

Att använda synkron gRPC/REST överallt återskapar hårt koppling; att använda asynkron för en användares omedelbar läsning lägger till onödig latens.

## Varför det spelar roll

Transportslaget bestämmer kopplingen och prestanda för varje interaktion, så att välja per användningsfall — inte globalt — är vad som håller systemet både snabbt och motståndskraftigt.

Mogna system blandar medvetet alla tre: gRPC på interna varma vägar, REST vid kanten och köer för arbetsflöden.

Stil	Synkron	Synkron	Asynkron
Nyttolast	JSON (text)	Protobuf (binär)	Vilket som helst (ofta binär)
Prestanda	Bra	Hög	Högt genomflöde
Kontrakt	OpenAPI (lös)	`.proto` (strikt)	Schema/event
Streaming	Begränsad	Native (bidi)	Pub/sub
Bäst för	Offentliga API:er, webbläsare	Intern låg-latens, högt volym	Lösning, buffring, event-driven