Santa TOEIC hizmetini sunan Riiid'de gRPC/Protobuf'u oldukça aktif biçimde kullanıyoruz.
Ben Riiid'e katıldıktan çok kısa bir süre sonra, bundan böyle backend ekibinin frontend'e (mobil/web) sunduğu tüm API'lerin gRPC ile birleştirileceği bildirildi.
Web frontend'de gRPC/Protobuf yığınını kullanmak için daha önce protoca JS/TS eklentisi takarak kullanmak ya da Protobuf.js'ten yararlanmak gibi yöntemler vardı.
protocun resmi JS eklentisi çok eski tarzda kod üretiyordu ve ekosistemdeki eklentiler de bizim gereksinimlerimizin tamamını karşılamıyordu. Bir de native binary (protoc) bağımlılığı gibi bir zahmet vardı. (Bugünlerde M1 cihazlarda protoc kurmanın zor olması gibi bir sorun da var.)
Biz o zamana kadar Protobuf.js kullanarak çeşitli ürünler geliştirmiştik; ancak şirkette yapılan tüm ürünlerde platformlar arası iletişimdeki bütün arayüzler için Protobuf kullanılınca, Protobuf.js'in bizim ihtiyaç duyduğumuz olgunluk seviyesinde olmadığını fark ettik.
Mesaj adı aynıysa başka bir namespace içindeki mesajla karıştırılması, global namespace'te bir enum'dan sonra mesaj bildirimi gelince mesaj tip kodunun üretilmemesi ya da üretilen TypeScript tip tanımlarının JS davranışıyla farklı olması gibi çeşitli sorunlarla karşılaştık.
Bu süreçte, belirli bir ürün için gerekli protobuf şemalarını ayıklayıp derleyen bir sistem kurmak amacıyla pollapo adında bir protobuf paket yöneticisi geliştirdik.
(O dönemde başka protobuf bağımlılık yöneticileri de vardı ama ya hataları bulunuyordu ya da iç içe bağımlılıkları desteklememe gibi sorunları vardı. Ayrıca buf'un sunduğu paket yönetimi özelliği o sırada sadece geliştirilmekte olduğuna dair bir blog yazısı düzeyindeydi ve biz pollapoyu yapıp şirket içi geçişi tamamlayana kadar da tamamlanmamıştı.)
pollapo ile ürün başına derlenen şema sayısını ciddi ölçüde azalttık ve aynı mesaj adı gibi nedenlerle oluşan hataları düşürdük; ancak buna rağmen hâlâ hatalar ve build sorunları vardı, bunları çözmek için protobuf'tan TypeScript'e bir derleyiciyi kendimiz geliştirdik.
Santa TOEIC şu anda protobuf.js'i tamamen kaldırıp yerine pbkit'e geçişi tamamlamış durumda.
Santa TOEIC dahil Riiid'de geliştirilen uygulamalar webview'ı yoğun biçimde kullanıyor.
Webview, cihaz/kullanıcı bilgisi veya o anda gösterilen içerik bilgisini almak için native ile iletişim kuruyor ve bu sıradaki arayüz de Protobuf servis şeması kullanılarak tanımlanıyor.
pbkit, servis kodu üretirken ağ katmanını gRPC yerine başka bir protokolle değiştirebilmek için bir arayüz sunuyor.
pbkit derleyicisini kullanan web frontend mühendislerinin, mobil native ile iletişim kurarken bunun gRPC isteği mi yoksa mobil mühendislerle kararlaştırılmış App Bridge protokolü üzerinden mi olduğunu bilmesine gerek kalmıyor.
Ayrıca Chrome eklentisini de bizzat geliştirdiğimiz için, mobil ile yapılan iletişim içeriği de Chrome Geliştirici Araçları'ndaki pbkit sekmesinde, ağ sekmesine bakar gibi rahatça incelenebiliyor.
Protobuf şema derleyicisini doğrudan kendimiz yaptığımız için, kod düzenleyicide Go to Definition gibi özellikleri hızlıca geliştirebileceğimizi düşündük ve bir VSCode eklentisi de yaptık.
Mevcut VSCode'a özel protobuf eklentileri çoğunlukla sadece sözdizimi vurgulama düzeyinde özellikler sunarken, pbkit VSCode eklentisinde düzgün çalışan bir Go to Definition özelliği bulunuyor.
Bundan sonra swift/kotlin/python gibi başka diller için destek, sunucu kullanım senaryoları desteği, dokümantasyon üretim araçları, lint/format araçları gibi şeyler geliştirmeyi planlıyoruz.
Bu araçları birlikte geliştirecek mühendisler de arıyoruz: https://riiid.com/ko/career/dx-software-engineer
İlginizi bekliyoruz.
pbkit deposu: https://github.com/pbkit/pbkit
VSCode eklentisi: https://marketplace.visualstudio.com/items?itemName=pbkit.vscode-pbkit
Chrome eklentisi: https://chrome.google.com/webstore/detail/pbkit-devtools/fjacmiijeihblfhobghceofniolonhca
8 yorum
Şirketimizde birkaç yıl önce gRPC ile arasında gidip geldikten sonra Thrift’i seçmiştik. Thrift’in de JS generator’ı eksikti, bu yüzden kendimiz düzeltmiştik ama bunun yapılacak iş olmadığını fark ettik. Bu yüzden keşke gRPC’yi seçseydik diye düşünmüştüm, ama anlaşılan orada da durum pek iç açıcı değilmiş.
Daha sonra biz GraphQL’i seçtik ve ben memnunum. Bazen iletişim overhead’i endişelendiriyor ama binary tabanlı protokolleri kullanamıyorum.
Havucunuzda çok iyi kullanıyoruz!! ( _ _ )
Bunu dahili API mesh'i için iyi değerlendirmeye çalışıyoruz haha
Vay canına, harikasınız!
Bu arada, şirket içinde zaten production’da kullanılacak kadar olgunlaştıysa,
v0.0.44gibi pre-alpha hissi veren bir sürümü artık kullanmasanız da olur gibi görünüyor.Sadece sürüm numarasına bakıp kullanmayacak kişiler olabilir, ağlama yüzü
Vay, derleyiciyi doğrudan kendiniz yapmışsınız. Harika! (golang kodunun nasıl üretildiğini merak etmiştim; anlaşılan şu anda yalnızca deno ve node.js destekleniyor.) Ben genelde protoc veya buf ile birlikte ts-proto kullanıyorum; üretilen ts kodunun ts-proto ile farkının ne olduğunu merak ediyorum.
Biraz dolambaçlı bir yoldan gidiyormuş gibi hissettiriyor https://github.com/trpc/trpc
bichi / Sunucu API'si gRPC protokolüyle sunuluyorsa, tRPC bunun desteklenmesi için olan bir şey değil, değil mi~?
gRPC ile ilgili yazılar her zaman hoş karşılanır :)