Tiga opsi dominan adalah REST (HTTP/JSON), gRPC (HTTP/2 + Protobuf), dan antrian pesan (Kafka/RabbitMQ). REST dan gRPC bersifat sinkron; antrian bersifat asinkron.
Tiga opsi dominan adalah REST (HTTP/JSON), gRPC (HTTP/2 + Protobuf), dan antrian pesan (Kafka/RabbitMQ). REST dan gRPC bersifat sinkron; antrian bersifat asinkron.
| Aspek | REST | gRPC | Message Queue |
|---|
| Gaya | Sync | Sync | Async |
| Muatan | JSON (text) | Protobuf (binary) | Any (often binary) |
| Kinerja | Good | High | High throughput |
| Kontrak | OpenAPI (loose) | .proto (strict) | Schema/event |
| Streaming | Limited | Native (bidi) | Pub/sub |
| Terbaik untuk | Public APIs, browsers | Internal hot paths | Decoupling, events |
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; }
Order Service ─publish→ [ "OrderPlaced" topic ] ─▶ Inventory
└────▶ Notifications
(producer doesn't know or wait for consumers)
Menggunakan gRPC/REST sinkron di mana-mana menciptakan kembali sambungan ketat; menggunakan asinkron untuk pembacaan langsung pengguna menambah latensi yang tidak perlu.
Pilihan transportasi menetapkan sambungan dan batas kinerja untuk setiap interaksi, jadi memilih per kasus penggunaan — bukan secara global — adalah apa yang membuat sistem tetap cepat dan tangguh.
Sistem yang matang dengan sengaja mencampur ketiganya: gRPC di jalur panas internal, REST di tepi, dan antrian untuk alur kerja.