- Dagger Cloud v3 जारी करते समय नया UI WebAssembly(WASM) और Go में लिखा गया
- Go का इस्तेमाल आम तौर पर web UI development में नहीं होता, लेकिन "codebase एकीकरण और performance optimization" के लिए यह तरीका चुना गया
- इस लेख में "इस चयन की पृष्ठभूमि, implementation के दौरान आई चुनौतियाँ, और अंतिम परिणाम" साझा किए गए हैं
मौजूदा समस्या: दो codebase से होने वाली अक्षमता
- Dagger, DAG(Directed Acyclic Graph) आधारित तरीके से काम करता है, और इसे TUI(terminal UI) तथा web dashboard(Dagger Cloud) में visualise किया जाता है
- पहले TUI, Go में और web UI, React/TypeScript में implement किया गया था
- लेकिन दोनों UI के बीच sync बनाए रखना मुश्किल था, और खासकर web UI में real-time में बड़े पैमाने के data को process करते समय performance समस्याएँ आती थीं
- जटिल OpenTelemetry event stream (लाखों नहीं, बल्कि दसियों हज़ार span) को process करते समय React UI की performance गिरावट और speed समस्या खास तौर पर सामने आई
- एक ही feature को दो बार implement करना पड़ता था, जो छोटी team के लिए बड़ा development burden था
- इसलिए codebase एकीकरण और performance optimization को लक्ष्य बनाकर नए approach पर विचार किया गया
चुना गया समाधान: Go + WebAssembly
- Go के साथ codebase एकीकरण
- TUI पहले से Go में implement था, इसलिए web UI को भी Go में लिखने पर code reuse संभव था
- team में Go developers अधिक होने से team productivity बढ़ी और maintenance आसान हुआ
- WebAssembly(WASM) का उपयोग
- Go code को सीधे browser में चलाने के लिए WebAssembly अपनाया गया
- हालांकि Go + WASM ecosystem अभी पूरी तरह mature नहीं है, इसलिए कुछ चुनौतियाँ थीं:
- component library की कमी → UI सीधे बनाना पड़ा
- browser की WASM memory limit (2GB) → बड़े data के लिए optimization ज़रूरी
- लेकिन memory optimization से TUI और Web UI दोनों को फायदा मिल सकता था
project risk कम करने की रणनीति
- Go-app framework का उपयोग
- PWA(Progressive Web App) development के लिए Go-आधारित framework चुना गया
- यह React जैसा component-based model देता है, जिससे migration आसान हुई
- prototype बनाना और validation
- मौजूदा UI को जितना संभव हो Go-app में फिर से implement करके मुख्य issues पहचाने गए
- WASM पहले से open standard के रूप में documented था, और बड़े सवालों के जवाब Go-app documentation में मिल गए
- सबसे बड़ी समस्या memory usage limit थी, जिसे हल करने के लिए design और optimization की ज़रूरत थी
prototype से production तक का रूपांतरण
performance optimization रणनीति
- बड़े log rendering का optimization
- 2 लाख से अधिक lines के log data को संभालते समय rendering performance बेहतर करनी थी
- इसके लिए virtual terminal rendering library(midterm) को optimize किया गया
→ TUI और Web UI दोनों की performance बेहतर हुई
- JSON parsing speed में सुधार
- Go WASM में JSON parsing धीमी थी → WebSocket-आधारित smart backend design किया गया
- Go के
encoding/gob का उपयोग कर data transfer optimize किया गया
- WASM file size optimization
- शुरुआती WASM file size: 32MB
- Brotli compression लागू करने पर यह 4.6MB तक घट गया
- CDN पर compression संभालना मुश्किल था, इसलिए build process में ही सीधे compression लागू किया गया
अन्य सुधार
- अपेक्षित memory समस्या के अलावा बाकी ज़्यादातर चिंताएँ निराधार निकलीं
- UI components लिखना मुश्किल नहीं था, और दूसरी services(Tailwind, Auth0 आदि) के साथ integration में भी कोई समस्या नहीं हुई
- WebAssembly में NPM packages का उपयोग संभव था → JavaScript के साथ interoperability सुनिश्चित हुई
- Go-app में component update का तरीका React की तुलना में अधिक flexible था, जिससे optimization की आज़ादी बढ़ी
- Go profiling tool(pprof) और browser built-in profiler के साथ performance analysis संभव था
- PWA support की वजह से इसे desktop/mobile app की तरह चलाया जा सकता है, यानी browser खोले बिना भी app इस्तेमाल किया जा सकता है
migration के बाद मिले फायदे
- UI consistency में सुधार
- TUI और web UI ने एक ही codebase इस्तेमाल करना शुरू किया, जिससे ज़्यादा consistent UX मिला
- performance और memory usage में सुधार
- बड़े data को संभालते समय rendering speed बेहतर हुई और memory usage कम हुआ
- team productivity में सुधार
- पहले Web UI और TUI को अलग-अलग optimize करना पड़ता था,
अब एक बार optimization करने पर दोनों interfaces पर एक साथ लागू किया जा सकता है
- इससे नई features development पर अधिक ध्यान देना संभव हुआ
क्या Go + WASM में migration करना चाहिए?
- आम तौर पर इसकी सिफारिश नहीं की जाती, लेकिन कुछ स्थितियों में यह उपयोगी हो सकता है:
- ऐसी team जिसमें Go developers ज़्यादा हों
- जटिल UI जहाँ TypeScript/React performance limit दिखा रहे हों
- TUI और Web UI के बीच code sharing की ज़रूरत हो
- ऐसा environment जहाँ development speed को अधिकतम करना ज़रूरी हो
- अगर ये शर्तें पूरी होती हैं, तो Go + WASM एक अच्छा विकल्प हो सकता है
लेकिन अधिकांश मामलों में मौजूदा web technologies(React, TypeScript आदि) अधिक उपयुक्त हैं
6 टिप्पणियां
क्या यह पुराने GWT जैसा है?
उम्... TS की तुलना में क्या यह ज़्यादा type-safe development होगा, यह जानने की उत्सुकता है।
किसी भी तरह से देखें तो यह आसान समस्या को मुश्किल तरीके से हल करने जैसा लगता है...
सोच से ज़्यादा Go-आधारित फ्रंटएंड बनाना प्रभावी है। इसके use case बढ़ने की वजह वाजिब है।
फिर भी इसे आज़माकर देखने का मन है।
Hacker News की राय
एक राय यह है कि छोटी टीम होने के कारण उन्हें तेज़ी से डिप्लॉय करना था
उनके पास मज़बूत Go engineers की टीम थी और UI इतना जटिल था कि TypeScript/React के साथ उसे scale करना मुश्किल था
पहले चिंता थी कि यह "canvas पर render" करने वाला framework होगा, लेकिन ऐसा नहीं है
उन्होंने <a href="https://go-app.dev/" rel="nofollow">https://go-app.dev/</a>; का उपयोग करके frontend बनाने का फ़ैसला किया
एक राय यह है कि Go इस तरह के काम के लिए उपयुक्त नहीं है
कुछ महीनों बाद यह देखना दिलचस्प होगा कि भारी stack से बेहतर performance वाले लेकिन कुछ हद तक असामान्य stack में बदलाव से सकारात्मक नतीजे मिलते हैं या नहीं
go-app के creator ने यह पोस्ट देखी और हैरानी जताई, साथ ही product की सफलता की कामना की
Go WASM में JSON parsing धीमी होने के कारण architecture बदलना पड़ा और WebSockets के ज़रिए gradual data loading के लिए "smart backend" बनाना पड़ा
एक राय यह है कि WASM कुछ खास niche use cases के लिए ठीक है, लेकिन सामान्य web apps बनाने के लिए उपयुक्त नहीं है
उनका मानना है कि सभी components (frontend/backend/app) में एक ही language का उपयोग करना बहुत मूल्यवान है