Laravel ve Go servisleri arasında mesaj şeması için Protobuf mu, JSON Schema mı?
Soru
Ana monolitim Laravel (PHP), veri işleme ve bildirim servislerim Go. Aralarında RabbitMQ ve Redis üzerinden yoğun asenkron mesajlaşma var. Go kesin tipli ama Laravel'de gevşek array'ler veri kaybına ve validasyon hatalarına yol açıyor. Dilden bağımsız, performanslı ve geriye uyumlu bir serialization standardı nasıl kurmalıyım — Protobuf mu, JSON Schema mı? Hataya açık noktalar neler?
Cevap
Kısa cevap: Asıl çözüm hangi wire format’ı seçtiğiniz değil, contract-first çalışmanız. Şemayı tek doğruluk kaynağı yapıp iki tarafı da ona zorlayınca sorun büyük ölçüde biter.
Yaşadığınız sıkıntı format sorunu değil, sözleşme sorunu: Go tarafı tipi dayatıyor, PHP tarafı gevşek array’le “idare ediyor” ve veri tam sınırda kayboluyor.
- Protobuf: tip + performans + codegen istiyorsanız bu.
.protodosyası tek doğruluk kaynağıdır; hem PHP hem Go için kod üretirsiniz, alan adlarını elle senkronlamazsınız. Geriye uyumluluğun tek kuralı var: alan numaralarını asla yeniden numaralandırmayın veya geri kullanmayın; sadece yenioptionalalan ekleyin. Binary olduğu için hafif ve hızlıdır. - JSON Schema: JSON-native ve debug edilebilir kalmak istiyorsanız bu. Mesaj insan-okur kalır, şemayı iki uçta da validate edersiniz. Operasyonu hafiftir ama garantisi zayıftır — kimse şemayı uygulamazsa yine eski noktaya düşersiniz. Yoğun trafik için Protobuf daha sağlam tercih.
- Asıl hata noktanız gevşek PHP array’i. Mesajı uygulamanın derinliğinde değil, tam sınırda tipli bir DTO’ya validate edip deserialize edin. Geçersizse oraya, kuyruğa girmeden reddedin. Array’i app içine sızdırırsanız hatayı 10 katman sonra yakalarsınız.
- İsim verin: drift, optional/required ve zero-value tuzakları. Şema kayması (drift),
optionalilerequiredkarışması, Go’da “boş değer” (0/"") ile “alan hiç yok” semantiğinin aynı görünmesi, versiyonsuz breaking change — hepsi klasik. Versiyonlamayı baştan kurun. - Para ve zamanı serileştirmede dikkat. Parayı
floatdeğil integer minor unit (kuruş) olarak taşıyın; zaman damgalarını RFC3339/UTC verin. Bu ikisi en sık sessizce bozulan alanlar.
Sonuç: Laravel↔Go yoğun asenkron trafikte ben olsam Protobuf + bir schema registry seçerdim — tipi gerçekten dayatır, codegen elle senkron derdini bitirir, performansı bedava gelir. JSON Schema’yı yalnızca trafiğin hafif ve insan-debug ihtiyacının yüksek olduğu yerde tutun. Ama hangisini seçerseniz seçin, kuralı değiştirmeyin: gevşek array’i sınırda öldürün, tipli DTO’ya çevirin, breaking change’i versiyonlayın.
İlgili Yazılar
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.