Protobuf ve JSON: Wire Format Gerçekten Ne Zaman Önemlidir

JSON Vergisi

Gönderdiğiniz her JSON payload bir vergi öder:

• Ayrıntılılık: alan adları her mesajda tekrarlanır
• Ayrıştırma yükü: dize ayrıştırma, ikili kod çözme işleminden daha yavaştır
• Schema zorlaması yok: alıcı her alanı savunmacı biçimde doğrulamak zorundadır

Çoğu web uygulaması için bu vergi görünmezdir. Büyük ölçekte — saniyede milyonlarca mesaj veya yavaş bağlantılardaki mobil istemciler — önemli hale gelir.

Protobuf Size Ne Kazandırır

Protocol Buffers (proto3), Google'ın ikili serileştirme formatıdır. Tipik bir JSON payload'ı, Protobuf eşdeğerinden 3–10x daha büyüktür. Serileştirme 5–10x daha hızlıdır.

message User {
  int64 id = 1;
  string name = 2;
  string email = 3;
}

Alan numaraları (1, 2, 3) gerçekte iletim hattına çıkandır — alan adları değil. Protobuf'un bu kadar kompakt olmasının nedeni budur.

Gerçek Maliyet: Schema Yönetimi

Protobuf'un performansı bir bedelle gelir: .proto dosyalarını korumanız ve her dil için bir kod üreticisi çalıştırmanız gerekir. Yeni bir alan eklemek, şemayı güncellemeyi, istemcileri yeniden oluşturmayı ve dağıtımları koordine etmeyi gerektirir.

JSON şemaları, hiçbir şeyi yeniden oluşturmadan değiştirilebilir.

Ne Zaman Geçiş Yapmalı

Şu durumlarda Protobuf'a geçin:

• Hem üreticiyi hem de tüketiciyi kontrol ediyorsanız
• Mesaj hacmi ~10k/sn'yi aşıyorsa veya payload boyutu ortalama ~1KB'yi geçiyorsa
• Zaten gRPC kullanıyorsanız
• Mobil bant genişliği gerçek bir kısıtlamaysa

Şu durumlarda JSON'da kalın:

• Halka açık bir API oluşturuyorsanız
• İnsan tarafından okunabilir loglara ihtiyaç duyuyorsanız
• Ekip büyüklüğünüz schema koordinasyonunu pahalı kılıyorsa

Orta Yol: Katı Schema ile JSON

Protobuf'a uzanmadan önce additionalProperties: false ile JSON + JSON Schema'yı deneyin. Araç yükü olmadan schema zorlaması ve daha küçük payload'lar elde edersiniz (gzip uygulandıktan sonra JSON ve Protobuf genellikle birbirinden %20 dahilinde kalır).