Pindah dari JSON ke Protobuf. Apakah itu layak?

23

Kami memiliki layanan web REST yang dapat melayani XML atau JSON (WCF). Saya mempermainkan ide menerapkan Protobuf. Mengapa?

PROS

Lebih sedikit memuat di server.
Ukuran pesan lebih kecil - lebih sedikit lalu lintas.
Lebih mudah untuk beralih sekarang daripada nanti.

Kon

Perlu diimplementasikan
Menjadi lebih sulit untuk memecahkan masalah / mengendus pesan untuk debugging.
Saya dapat mengaktifkan GZip di server dan JSON akan menghabiskan banyak lalu lintas

Apa saran dan / atau pengalaman Anda tentang ini?

web-services wcf serialization

— katit
sumber

1

Saya melihat halaman wikipedia, dan sebenarnya lebih banyak karakter per pasangan nilai kunci, jadi mengapa dosisnya memiliki pesan yang lebih kecil?

— Ramzi Kahil

Karena serialisasi. Data biner datang sebagai biner (misalnya array byte). Selain itu, itu tidak membawa nama properti dalam pesan. Mereka pergi dengan peraturan properti. developers.google.com/protocol-buffers/docs/encoding#structure

— katit

10

Secara teknis Anda menjawab pertanyaan Anda sendiri, kompres JSON dan selesai dengan itu. Yang terpenting, Anda tidak pernah menyebut kasus bisnis aktual untuk menghabiskan uang dan waktu untuk aktivitas ini.

39

Apakah nilai bisnis penerapannya melebihi biaya?

Jika Anda menerapkan, Anda perlu mengubah tidak hanya server Anda, tetapi semua klien (meskipun Anda dapat mendukung kedua format dan hanya mengubah klien sesuai kebutuhan). Itu akan memakan waktu dan pengujian, yang merupakan biaya langsung. Dan jangan meremehkan waktu yang dibutuhkan untuk benar-benar memahami buffer protokol (terutama alasan untuk membuat field diperlukan atau opsional), dan waktu yang dibutuhkan untuk mengintegrasikan kompiler protobuf ke dalam proses build Anda.

Jadi, apakah nilainya melebihi itu? Apakah Anda dihadapkan pada pilihan "biaya bandwidth kami adalah X% dari pendapatan kami dan kami tidak dapat mendukungnya"? Atau bahkan "kita perlu menghabiskan $ 20.000 untuk menambah server untuk mendukung JSON"?

Kecuali jika Anda memiliki kebutuhan bisnis yang mendesak, "pro" Anda tidak benar-benar pro, hanya optimasi prematur.

— parsifal
sumber

23

saya memelihara apis dan seseorang sebelum saya menambahkan protobuf (karena "lebih cepat"). Satu-satunya hal yang lebih cepat adalah RTT karena payload yang lebih kecil, dan itu dapat diperbaiki dengan JSON yang di-gzip.

Bagian yang tidak menyenangkan bagi saya adalah pekerjaan relatif untuk mempertahankan protobuf (dibandingkan dengan JSON). Saya menggunakan java jadi kami menggunakan pemetaan objek Jackson untuk JSON. Menambah respons berarti menambahkan bidang ke POJO. Tetapi untuk protobuf saya harus memodifikasi file .proto, kemudian memperbarui logika serialisasi dan deserialisasi yang memindahkan data masuk / keluar dari buffer protokol dan ke dalam POJO. Itu terjadi lebih dari sekali bahwa rilis telah terjadi di mana seseorang menambahkan bidang dan lupa memasukkan kode serialisasi atau deserialisasi untuk buffer protokol.

Sekarang klien telah menerapkan terhadap buffer protokol, hampir tidak mungkin untuk lolos.

Anda mungkin bisa menebak dari ini, saran saya adalah jangan lakukan itu.

— Kevin
sumber

5

Jika Anda menulis (de) kode serialisasi untuk memindahkan data masuk / keluar dari POJO, Anda salah melakukannya. Cukup gunakan kelas yang dihasilkan protobuf secara langsung.

— Marcelo Cantos

Saya pikir dalam hal ini saya pindah / keluar dari POJO karena basis kode mendukung permintaan / tanggapan JSON, XML, dan Protobuf, dan mengingat bahwa saya tidak dapat menambahkan anotasi Jackson dan / atau JAXB ke protobuf yang dihasilkan kelas, dan saya ingin untuk menggunakan objek model yang sama di seluruh kode, saya tidak tahu bahwa saya memiliki opsi untuk hanya menggunakan kelas yang dihasilkan. Saya bisa melihat bagaimana ini akan mungkin dilakukan jika saya menulis katakanlah layanan GRPC yang hanya berbicara protobuf.

— Kevin