14 puan yazan GN⁺ 2025-02-26 | 6 yorum | WhatsApp'ta paylaş
  • Dagger Cloud v3'ün yayınlanmasıyla birlikte yeni arayüz WebAssembly (WASM) ve Go ile yazıldı
  • Go normalde web UI geliştirmede kullanılmasa da, bu yaklaşım "kod tabanını birleştirmek ve performansı optimize etmek" için seçildi
  • Bu yazı, "bu tercihin arka planını, uygulama sürecindeki zorlukları ve nihai sonucu" paylaşıyor

Mevcut sorun: iki kod tabanının yarattığı verimsizlik

  • Dagger, DAG (Directed Acyclic Graph) tabanlı çalışır ve bunu TUI (terminal UI) ile web panosunda (Dagger Cloud) görselleştirir
  • Daha önce TUI Go ile, web UI ise React/TypeScript ile uygulanmıştı
  • Ancak iki UI arasında senkronizasyon zordu; özellikle web UI'da büyük miktarda veriyi gerçek zamanlı işleme sırasında performans sorunları ortaya çıktı
  • Karmaşık OpenTelemetry olay akışlarıyla (yüz binlerce span) uğraşılırken React UI'ın performans düşüşü ve hız sorunları belirginleşti
  • Aynı işlevselliği iki kez uygulamak gerekiyordu; bu da küçük bir ekip için büyük bir geliştirme yükü oluşturuyordu
  • Bu nedenle kod tabanını birleştirme ve performansı optimize etme hedefiyle yeni bir yaklaşım değerlendirildi

Seçilen çözüm: Go + WebAssembly

  • Go ile kod tabanını birleştirmek
    • TUI zaten Go ile geliştirildiği için, web UI da Go ile yazılırsa kod yeniden kullanılabilir
    • Ekipte çok sayıda Go geliştiricisi olması ekip verimliliğini artırıyor ve bakımı kolaylaştırıyor
  • WebAssembly (WASM) kullanımı
    • Go kodunu doğrudan tarayıcıda çalıştırabilmek için WebAssembly benimsendi
    • Ancak Go + WASM ekosistemi henüz yeterince olgun olmadığından bazı zorluklar vardı:
      • Bileşen kütüphanesi eksikliği → UI'ın doğrudan geliştirilmesi gerekiyor
      • Tarayıcıdaki WASM bellek sınırı (2GB) → büyük verilerle çalışırken optimizasyon gerekiyor
      • Ancak bellek optimizasyonu hem TUI hem de web UI için fayda sağlayabilir

Proje riskini en aza indirme stratejisi

  • Go-app framework'ünü kullanmak
    • PWA (Progressive Web App) geliştirme için Go tabanlı bir framework seçildi
    • React'e benzer bileşen tabanlı bir model sunduğu için geçiş kolaylaştı
  • Prototip hazırlama ve doğrulama
    • Mevcut UI, mümkün olduğunca Go-app ile yeniden uygulanarak temel sorunlar belirlendi
    • WASM zaten açık bir standart olarak dokümante edilmişti ve başlıca sorular Go-app dokümantasyonunda çözülebiliyordu
    • En büyük sorun bellek kullanımı sınırıydı; bunu aşmak için tasarım ve optimizasyon gerekiyordu

Prototipten prodüksiyona geçiş süreci

Performans optimizasyonu stratejileri

  • Büyük ölçekli log render etme optimizasyonu
    • 200 binden fazla satır log verisi işlenirken render performansını iyileştirmek gerekiyordu
    • Bunun için sanal terminal render kütüphanesi midterm optimize edildi
      → hem TUI hem de web UI performansı arttı
  • JSON ayrıştırma hızını artırmak
    • Go WASM'de JSON ayrıştırma yavaştı → WebSocket tabanlı akıllı bir backend tasarlandı
    • Veri aktarımını optimize etmek için Go'nun encoding/gob paketi kullanıldı
  • WASM dosya boyutunu optimize etmek
    • Başlangıçtaki WASM dosya boyutu: 32MB
    • Brotli sıkıştırması uygulandı → 4.6MB'a düştü
    • CDN üzerinde sıkıştırmayı yönetmek zor olduğundan, sıkıştırma doğrudan build sürecine eklendi

Diğer iyileştirmeler

  • Beklenen bellek sorunu dışında kaygıların çoğu yersiz çıktı
  • UI bileşenlerini yazmak zor olmadı ve diğer servislerle (Tailwind, Auth0 vb.) entegrasyonda da sorun yaşanmadı
  • WebAssembly içinde NPM paketleri kullanmak mümkün oldu → JavaScript ile birlikte çalışabilirlik sağlandı
  • Go-app, React'e kıyasla bileşen güncelleme yöntemlerinde daha esnek olduğundan optimizasyon özgürlüğü daha yüksekti
  • Go profil oluşturma araçları (pprof) ve tarayıcı yerleşik profiler'larıyla performans analizi yapılabildi
  • PWA desteği sayesinde masaüstü/mobil uygulama olarak çalıştırmak mümkün oldu; tarayıcı açmadan da uygulama kullanılabiliyor

Geçişten sonra elde edilen kazanımlar

  • UI tutarlılığında artış
    • TUI ve web UI aynı kod tabanını kullanınca daha tutarlı bir UX sağlandı
  • Performans ve bellek kullanımında iyileşme
    • Büyük miktarda verilerle çalışırken render hızı arttı ve bellek kullanımı azaldı
  • Ekip verimliliğinde artış
    • Önceden web UI ve TUI ayrı ayrı optimize edilmek zorundaydı
      şimdi ise tek bir optimizasyon iki arayüze de aynı anda uygulanabiliyor
    • Bu sayede yeni özellik geliştirmeye daha fazla odaklanılabiliyor

Go + WASM'e geçmeli misiniz?

  • Genel olarak önerilmiyor, ancak bazı koşullarda faydalı olabilir:
    • Go geliştiricisinin bol olduğu ekipler
    • TypeScript/React'in performans sınırına dayandığı karmaşık UI'lar
    • TUI ile web UI arasında kod paylaşımı ihtiyacı
    • Geliştirme hızının en üst düzeye çıkarılmasının gerektiği ortamlar
  • Bu koşullar karşılanıyorsa Go + WASM iyi bir alternatif olabilir
    Ancak çoğu durumda mevcut web teknolojileri (React, TypeScript vb.) daha uygundur

6 yorum

 
minho2da 2025-02-27

Eskiden GWT gibi bir şey mi?

 
bbulbum 2025-02-26

Hm... TS'den daha tip güvenli bir geliştirme olup olmayacağını merak ediyorum.

 
colus001 2025-02-26

Ne kadar baksam da, sanki kolay bir problemi zorlaştırarak çözüyorlarmış gibi geliyor...

 
riki3 2025-02-26

Düşündüğümden daha etkili bir yaklaşım, Go tabanlı frontend geliştirmek. Kullanım alanlarının artmasının bir nedeni varmış.

 
halfenif 2025-02-26

Yine de denemek istiyorum.

 
GN⁺ 2025-02-26
Hacker News görüşleri
  • Küçük bir ekip olarak hızlı dağıtım yapmaları gerektiği yönünde bir görüş var

    • Ancak prototip oluşturmaları neredeyse bir ay sürmüş, Go-app UI bileşenlerini kendileri yazmak zorunda kalmışlar ve Go WASM'in JSON ayrıştırmada yavaş olması nedeniyle mimari önemli ölçüde değiştirilmiş
    • Bunun özgeçmiş odaklı programlama gibi duyulduğunu söyleyenler var
  • Güçlü bir Go mühendisliği ekibi vardı ve TypeScript/React ile ölçeklenmesi zor bir karmaşık UI söz konusuydu

    • Demo, web frontend konusunda deneyimi sınırlı bir ekip izlenimi veriyordu
    • Kayıt sayfası ekrana sığmıyor, dashboard içindeki tıklamalarda tam ekranda bir spinner çıkıyor ve sayfa yeniden yükleniyor
    • İkonlar yüklenirken alt-text görünüyor
    • React'in ölçeklenmemiş olmasına sevinen bir görüş de var
  • Bunun "canvas'a render" eden bir framework olmasından endişe edilmiş ama öyle değilmiş

    • WASM ile DOM arasındaki birlikte çalışabilirliğin yeterince hızlanmış olması olumlu bulunuyor
    • Ancak 32MB'lık binary büyük bir dezavantaj
  • Frontend'i oluşturmak için <a href="https://go-app.dev/" rel="nofollow">https://go-app.dev/</a>; kullanmaya karar vermişler

    • Go-app, Golang ve WebAssembly kullanarak PWA geliştirmek için bir paket
  • Go'nun bu tür işler için uygun olmadığı görüşü var

    • Rust kullanarak daha iyi sonuç aldıklarını söylüyorlar
    • Rust ile oluşturulan wasm binary'leri ortalama 240kb boyutunda oluyor ve aktarım sırasında iyi sıkıştırılıyor
  • Birkaç ay sonra, daha ağır bir stack'ten daha yüksek performanslı ama biraz sıra dışı bir stack'e geçişin olumlu sonuç verip vermediğine dair bir takip yazısı ilginç olurdu

    • Böyle projeler için frontend geliştiricisi işe almak, React geliştiricisi bulmaktan daha kolay olmayacaktır
  • go-app'in yaratıcısı bu gönderiyi görüp şaşırmış ve ürünün başarılı olmasını dilemiş

  • Go WASM'in JSON ayrıştırmada yavaş olması, mimari değişikliğe ve WebSockets üzerinden kademeli veri yüklemesi için "akıllı backend" oluşturmalarına yol açmış

    • gob verisinin güvenlik sorunlarıyla ilgili endişeler var
  • WASM'in belirli niş kullanım alanlarına uygun olduğu, ancak genel web uygulamaları oluşturmak için uygun olmadığı görüşü var

    • go-app ile yapılan bir uygulama 3.6MB'lık WASM kodu yüklüyor
    • Blazor da benzer şekilde, basit bir uygulama için bile ilk yüklemede en az 1MB gerektiriyor
  • Tüm bileşenlerde (frontend/backend/app) aynı dili kullanmanın büyük değer taşıdığı düşünülüyor

    • Buna karşılık, "Typescript everywhere" yaklaşımını kullanıp frontend'de React, backend'de NodeJS, uygulamada ise Capacitor kullananlar da var