Belajar A2A - gRPC Support

#Pendahuluan

Di episode 10 agent kalian sudah multi-tenant dan bisa berunding versi protokol. Namun bayangkan satu orchestrator yang memanggil puluhan remote agent dengan HTTP+JSON dan SSE: setiap request membawa overhead serialisasi teks, koneksi dibuka-tutup terus, dan streaming di atas HTTP/1.1 terasa seperti selang bocor. A2A punya jawaban ketiga untuk transport: gRPC.

Roadmap episode ini: kita mulai dari bagaimana gRPC menjadi binding resmi ketiga, bedah definisi protobuf untuk service A2A, keunggulan streaming dan backpressure, kriteria kapan gRPC lebih unggul dari HTTP/JSON, dan terakhir interop lewat gateway serta reuse server handler.

#gRPC: Binding Ketiga untuk A2A

Sejak awal, A2A dirancang sebagai protokol multi-transport: JSON-RPC 2.0 over HTTP dengan SSE sebagai binding utama, dan gRPC ditambahkan sebagai binding resmi sejak v0.3 (Juli 2025). Alasan penambahannya sederhana — ekosistem membutuhkan transport berperforma tinggi untuk komunikasi antar service, dan gRPC adalah standar de facto-nya: skema tegas via protobuf, transport HTTP/2, dan streaming yang didukung native.

Di A2A v1.0, gRPC bukan eksperimen — ia menjadi warga kelas satu. Agent Card mendeklarasikannya di supported_interfaces dengan protocol_binding bernilai gRPC, client bisa memilihnya seperti memilih JSON-RPC, dan SDK resmi Python, TypeScript, Go, Java, serta .NET menyediakan implementasinya.

#Definisi Protobuf untuk Service A2A

Skema gRPC didefinisikan dalam file protobuf resmi A2A — satu sumber kebenaran untuk semua bahasa. Isinya memetakan method JSON-RPC yang kita kenal dari episode 5 ke dalam RPC: MessageSend untuk message/send, SendSubscribe untuk streaming, GetTask untuk tasks/get, dan Cancel untuk tasks/cancel:

syntax = "proto3";
 
package a2a.v1;
 
service A2AService {
  rpc MessageSend(MessageSendRequest) returns (MessageSendResponse);
  rpc SendSubscribe(SendSubscribeRequest) returns (stream SendSubscribeResponse);
  rpc GetTask(GetTaskRequest) returns (GetTaskResponse);
  rpc Cancel(CancelRequest) returns (CancelResponse);
}
 
message MessageSendRequest {
  string task_id = 1;
  Message message = 2;
}
 
message MessageSendResponse {
  Task task = 1;
}

Perhatikan SendSubscribe yang mengembalikan stream — inilah bentuk gRPC dari SSE streaming yang kita bahas di episode 7. Dari skema ini, tooling protobuf menghasilkan stub client dan server dalam berbagai bahasa, sehingga pemanggilan MessageSend di Go atau Python berbicara pada service yang sama dengan definisi identik.

#Keunggulan Streaming & Backpressure

Mengapa gRPC unggul untuk streaming? Jawabannya ada di HTTP/2 dan desain protobuf:

• Multiplexing. Satu koneksi TCP HTTP/2 menampung banyak stream paralel — puluhan task bisa mengalir tanpa membuka koneksi per task seperti HTTP/1.1.
• Backpressure. HTTP/2 memiliki flow control yang menahan pengiriman bila penerima belum siap. Produsen event tidak dibiarkan membanting receiver — laju disesuaikan secara alami.
• Streaming dua arah. Selain server streaming, gRPC mendukung bidirectional stream — client dan server saling kirim event dalam satu koneksi.
• Payload ringkas. Protobuf menyerialisasi data dalam format biner jauh lebih kecil dari JSON, mengurangi byte yang melintasi jaringan secara signifikan.

Backpressure inilah yang membuat gRPC terasa "jujur": saat receiver lambat, aliran melambat dengan sendirinya, bukan membanjiri antrean tak terbatas seperti yang kerap terjadi pada SSE di HTTP/1.1.

#gRPC vs HTTP/JSON: Kapan Memilih

gRPC bukan pengganti HTTP/JSON dalam semua kasus — keduanya saling melengkapi. Kriteria pilihannya:

Aturan praktisnya: pakai gRPC untuk komunikasi internal antar agent yang kita kontrol penuh — throughput tinggi, streaming berat, lalu lintas besar. Pakai HTTP/JSON untuk permukaan eksternal — mitra, browser, debugging cepat, dan siapa pun yang tidak mau menggenggam stub protobuf. Banyak production memakai keduanya sekaligus: gRPC di dalam jaringan agent, HTTP/JSON di gerbang publik.

#Interop: Gateway HTTP↔gRPC

Karena kedua binding hidup berdampingan, kebutuhan interop muncul: client HTTP memanggil agent yang hanya mengekspos gRPC, atau sebaliknya. Ada dua strategi umum.

Strategi pertama: gateway transparan. Tooling seperti gRPC-gateway atau Envoy menerjemahkan request HTTP+JSON menjadi panggilan gRPC dan mengembalikan respons sebagai JSON. Client luar tetap memakai curl atau SDK HTTP biasa; gateway yang menangani terjemahan. Ini pola favorit untuk mengekspos service gRPC internal ke mitra eksternal.

Strategi kedua: reuse server handler. SDK resmi mendorong desain ini: executor dan task store ditulis sekali, lalu dipasang pada handler JSON-RPC maupun handler gRPC. Di SDK Python, handler gRPC dirakit dari komponen yang sama dengan versi HTTP:

Handler gRPC yang memakai executor yang sama

from a2a.server.request_handlers import GrpcHandler
 
grpc_handler = GrpcHandler(
    agent_executor=my_executor,
    task_store=task_store,
    agent_card=card,
)

Karena GrpcHandler menerima agent_executor dan task_store yang identik dengan versi HTTP, logika agent tidak pernah ganda. Satu perubahan pada perilaku task langsung berlaku untuk kedua transport. Untuk verifikasi cepat, tool grpcurl menjadi pendamping curl — panggilan grpcurl -plaintext localhost:50051 a2a.v1.A2AService/MessageSend mengetes service tanpa menulis kode apa pun:

grpcurl -plaintext -d '{"message":{"role":"user","parts":[{"kind":"text","text":"Analisis lead"}]}}' \
  localhost:50051 a2a.v1.A2AService/MessageSend

Dengan -plaintext untuk koneksi tanpa TLS lokal, grpcurl mengirim request dan menampilkan respons — cara tercepat memastikan service gRPC kalian hidup.

#Penutup

Episode 11 menutup pembahasan binding transport A2A. gRPC hadir sebagai binding ketiga sejak v0.3 dan matang di v1.0, dengan definisi protobuf sebagai sumber kebenaran skema, streaming HTTP/2 dengan backpressure, dan payload biner yang lebih ringkas. Pilihan antara gRPC dan HTTP/JSON bergantung pada konteks — internal berperforma tinggi untuk gRPC, permukaan publik untuk HTTP/JSON. Dan berkat reuse handler serta gateway, keduanya bisa hidup berdampingan tanpa menduplikasi logika agent.

Inti yang harus dibawa pulang:

• gRPC adalah binding resmi ketiga A2A, dideklarasikan lewat supported_interfaces pada Agent Card.
• Skema protobuf mendefinisikan RPC yang memetakan method JSON-RPC, termasuk streaming SendSubscribe.
• HTTP/2 memberi multiplexing dan flow control; backpressure melindungi receiver dari banjir event.
• Pilih gRPC untuk lalu lintas internal tinggi; HTTP/JSON untuk permukaan eksternal dan debugging.
• Gateway dan reuse server handler memungkinkan interop HTTP↔gRPC tanpa menulis logika dua kali.

Setelah transport, autentikasi, multi-tenancy, dan konten dikuasai, pertanyaan berikutnya adalah produktivitas: haruskah kalian menulis semua ini dari nol? Di episode 12 kita membahas ADK & Framework Integration — mengekspos agent Google ADK sebagai A2A server, memakai remote A2A agent sebagai sub-agent, hingga adapter pattern untuk LangChain, LangGraph, CrewAI, dan OpenAI Agents SDK. Sampai jumpa!