Comparez REST, gRPC et les files de messages pour la communication inter-services.

Question

Accepted Answer

Les trois options dominantes sont **REST** (HTTP/JSON), **gRPC** (HTTP/2 + Protobuf) et les **files de messages** (Kafka/RabbitMQ). REST et gRPC sont synchrones ; les files sont asynchrones.

## Comparaison

| Aspect | REST | gRPC | Message Queue |
|---|---|---|---|
| Style | Sync | Sync | Async |
| Payload | JSON (text) | Protobuf (binary) | Any (often binary) |
| Performance | Good | High | High throughput |
| Contract | OpenAPI (loose) | `.proto` (strict) | Schema/event |
| Streaming | Limited | Native (bidi) | Pub/sub |
| Best for | Public APIs, browsers | Internal hot paths | Decoupling, events |

## Exemple de contrat gRPC

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

## Exemple de messaging

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

## Choisir

- **REST** — clients externes, large compatibilité, lisible par l'homme.
- **gRPC** — interne, faible latence, appels à haut volume ; contrats stricts ; streaming.
- **Queues** — découplage, buffering, flux event-driven, survie aux pannes.

## Écueil

Utiliser gRPC/REST synchrone partout recréé un couplage étroit ; utiliser l'async pour une lecture immédiate d'un utilisateur ajoute une latence inutile.

## Pourquoi c'est important

Le choix du transport définit le couplage et le plafond de performance pour chaque interaction, donc choisir par cas d'usage — et non globalement — est ce qui maintient le système à la fois rapide et résilient.

Les systèmes matures mélangent délibérément les trois : gRPC sur les chemins chauds internes, REST à la périphérie, et les files pour les workflows.

Style	Sync	Sync	Async
Payload	JSON (text)	Protobuf (binary)	Any (often binary)
Performance	Good	High	High throughput
Contract	OpenAPI (loose)	`.proto` (strict)	Schema/event
Streaming	Limited	Native (bidi)	Pub/sub
Best for	Public APIs, browsers	Internal hot paths	Decoupling, events