React FrontendをGOとWebAssemblyに置き換えました

数週間前、私たち ダガークラウドV3を発売しました、完全に新しいユーザーインターフェイス ダガークラウド。 V3とそのV2の前身の主な違いの1つは、新しいUIが書かれていることです WebAssembly（WASM） goを使用します。一見、これは奇妙な選択のように思えるかもしれません – 通常、Web UIをプログラムすることを決定するときにあなたが考える第一言語ではありません – しかし、私たちには十分な理由がありました。このブログ投稿では、WebAssemblyを選択した理由、実装の課題（およびそれらの周りでどのように機能したか）を選択した理由、および結果を説明します。

2つのコードベース=より多くの作業、より少ない機能

短剣は、多くの場合並行して、作戦のダグを構築し、それらを評価することで機能します。本質的に、これは表示するのが難しいことです。ユーザーがそれを理解できるようにするために、私たちは提供します 2つのリアルタイム視覚化インターフェイス：Dagger Terminal UI（TUI）、The Dagger CLIと、オンラインWebダッシュボードであるDagger Cloudに含まれています。 Dagger TuiはGoに実装され、Dagger Cloud（Pre-V3）がReactで書かれています。

明らかに、両方のユーザーインターフェイスを可能な限り互いに近づけることを望んでいます。しかし、Daggerのイベントストリームをリアルタイムで解釈し、UIを作成する実際の行為は非常に関与しています。私たちが見たより複雑なイベントストリームのいくつかは、数十万のオペンテレメトリースパンを持っています。それらの周りのデータ構造の管理は非常に迅速に非常に複雑になります。 Web UIは、処理する必要がある膨大な量のデータに追いつくことができず、遅くて遅くなります。このパフォーマンスのボトルネックを修正するために、Reactアプリケーションの別の実装モデルに強制されました。

そのため、1つの言語とエコシステム（TypeScript/React）、もう1つはまったく異なる言語とエコシステム（GO）で、同じことを達成しようとする2つのインターフェイスで最終的に2つのインターフェイスを行いました。それらの間の論理。小さなチームとして、私たちは速く出荷する必要があります。すべての機能を2回再実装する必要があることは、速度に対する大規模な税金でした。

私たちは、2つの主要な目標を持つDagger Cloudへの新しいアプローチについて考え始めました。

• 重複を排除し、新しい機能を出荷するのをより効率的にするために、コードベースを統合します

• ターミナルUIの速度とパフォーマンスに合わせて、サクサクできびきびしたWeb UIの約束を果たします

Go + WebAssemblyを選択します

私たちの最初の目標は、ダガークラウドとTUIの両方に1つのコードベースを再利用できることでした。私たちはそれをGO CodeBaseにするためにかなり早く決定しました。技術的には、TUIにTypeScriptを使用して、TUIにTypeScriptを使用することもできました。しかし、私たちは主にGOエンジニアのチームなので、GOを選択することで、チームの他の人が貢献しやすくなり、機能を追加したり、数時間ドロップインして問題をデバッグしたりしました。単一の言語の標準化に加えて、それは私たちに柔軟性を与え、私たちのチームのサイロを壊しました。

ブラウザでGOコードを直接実行することにした後、WebAssemblyが論理的な次のステップでした。しかし、まだいくつかの課題がありました：

• Go + WebAssemblyの組み合わせは、Reactや他のJavaScriptフレームワークほど成熟していません。既製のコンポーネントライブラリから引き出すことはできません。開発者のツールはそれほど豊富ではありません。ほとんどのUIコンポーネントをゼロから構築する必要があることを知っていました。

• ほとんどのブラウザーでは、WebAssemblyアプリケーションには2 GBのメモリ制限があります。大きな痕跡を表示する際にこれが問題になると予想し、メモリの使用を最小限に抑え、UIを安定させるために多くの最適化を行う必要があることを知っていました。しかし、これは完全に悪くはありませんでした。ここでのシルバーの裏地は、WebAssembly UIに対して行われたメモリ使用の改善も、現在共有コードベースになっているため、TUIユーザーにも利益をもたらすことでした。

プロジェクトのリスクを解除します

決定を下したら、次の質問は「これをどのように構築するのですか？」でした。新しいWebAssemblyベースのUIを作成することにしました Go-Appフレームワーク。 Go-Appは、特に高レベルのフレームワークです プログレッシブWebアプリ（PWAS） WebAssemblyで。高速コンピレーションやネイティブの静的タイピングなど、重要なGOの利点を提供し、ReactのようなコンポーネントベースのUIモデルにも従い、遷移が容易になります。

GO + WebAssemblyの組み合わせは主流ではないため、Daggerチーム内でその実現可能性について健康的な懐疑論がありました。たとえば、Go-App UIコンポーネントには実際のエコシステムはありませんでしたが、自分で書く必要があることはわかっていましたが、これがどれほど簡単か困難であるかはわかりませんでした。また、他のサービス（Tailwind、Auth0、Intercom、Posthog）との統合、および同時に何百ものライブデートコンポーネントをレンダリングすることについても懸念がありました。

これらの質問に答えてプロジェクトをリスクを解決するために、私はGO-APPでできるだけ多くのUIを再実装することを目標に、1か月近くのプロトタイピングを費やしました。結局のところ、ブロッカーは多くありませんでした：WebAssemblyはすでに 十分に文書化されたオープン標準 そして、他のほとんどの質問が答えられました Go-App独自のドキュメント。予想通り、最大の課題はメモリの使用制限であり、慎重な設計と最適化が必要でした。

プロトタイプから生産まで

概念の実証が得られたら、チームの快適さレベルが大幅に向上し、プロダクションの実装を提供するためにプロジェクト「Awesome Wasm」を開始しました。これが旅のいくつかのメモです：

• メモリの使用は、プロジェクトの成功に対する最も実存的な脅威でした。クラッシュせずに200k以上のログ出力をレンダリングする方法を考え出すのに多くの時間を費やしました。これにより、最適化が深まりました 仮想端子レンダリングライブラリ、TUIメモリの使用量を同時に劇的に削減しました（すでに述べたように、コードベースを共有することは、あるインターフェイスの重要な最適化が他のインターフェイスで「無料」になることを意味します！）

• GO WASMは大量のJSONを解析するのが遅いため、劇的なアーキテクチャの変更と、Goのめったに使用されない使用を使用して、WebSocketを介してインクリメンタルなデータ読み込みのための「スマートバックエンド」の作成につながりました。 エンコード/GOB形式。

• 当初、WASMファイルは約32 MBでした。適用して Brotli圧縮、私たちはそれを約4.6 MBに引き下げることができました。私たちはCDNでBrotli圧縮をオンザフライで実行しようとしましたが、ファイルが大きすぎたため、最終的にはビルドプロセスに圧縮ステップを含めました。

• 記憶の課題とは別に、他の最初の心配のほとんどは根拠がないことが判明しました。 UIコンポーネントは書くのがそれほど難しくありませんでした。他のサービスとの統合は簡単で、コンポーネントの更新をリアルタイムで処理するための優れたテクニックを見つけました。

• 私が見つけた多くの有用なNPMパッケージがあったので、GOでそれらを使用できるかどうか疑問に思いました。 WebAssemblyにはGoとJavaScriptの両方に簡単なインターフェイスがあるため、 browserifyを使用してnpmパッケージをロードするダガーモジュール。このモジュールにより、GOアプリケーションに含めることができるJavaScriptファイルを生成できます。これは、主にGOで作業できることを意味し、その後、必要に応じて、ネイティブJavaScriptに実装されているヘルパーをロードする方法があります。

• 免責事項：私はReact Professionalではないので、それを念頭に置いて… Reactはコンポーネントを実装する非常に厳格な方法を持っていたように思えましたが、Go-Appははるかに柔軟でした。 Go-Appでは、いつでもコンポーネントをいつでも更新できます。これにより、最適化のためにさらに多くの自由度が得られます。たとえば、150,000以上の出力をレンダリングするコンポーネントを最適化する必要がありました。さまざまなアプローチを試してから、最適なアプローチを選択する能力を持つだけで、エクササイズ全体がはるかに簡単になりました！

• Go-Appには、ブラウザに組み込まれたReactのような開発者ツールがありませんが、Go独自のツール（PPROF）に加えて、プロファイリングとデバッグのためにブラウザに組み込まれたデフォルトのプロファイラーを使用することができました。これは、関数の呼び出しを検査し、CPUとメモリの使用を追跡し、メモリ使用量を最適化するためのさまざまなアプローチの有効性を評価するのに非常に役立ちました。

• Go-Appを使用することの副次的な利点を発見しました。DaggerCloudはPWAとして構築されているため、デスクトップまたはモバイルアプリケーションとしてインストールできます。これにより、最初にブラウザを開く必要なく、ネイティブアプリケーションのようにDagger Cloudを起動し、フルスクリーンエクスペリエンスを取得するか、デスクトップタスクバー/ドックに専用のアイコンを使用できます。

ダガークラウドV3をソフトローンチしました 短剣の司令官 数週間前、フィードバックを収集し、その後すぐにすべての人が利用できるようにしました。

利点

WASMへのReactからの切り替えにより、特に大規模で複雑なトレースをレンダリングする場合、すべてのダガーインターフェイスでより一貫したユーザーエクスペリエンスが発生し、全体的なパフォーマンスとメモリ使用量が削減されました。

エンジニアリングの観点からも、私たちのチームにとっての利点は重要です。最適化には、実際に機能を実装するのと同じように、それ以上ではないにしても多くの作業が含まれます。そのため、Web UIの最適化に時間を費やし、TUIを最適化する時間を増やし、代わりに新しい機能の提供に集中する必要がないことは素晴らしいことです。

これをすべきですか？

Dagger Cloud V3には、Dagger Communityが賑やかになり、最近フィールディングしてきたより一般的な質問の1つは、誰がこれを行うことを検討すべきか、誰がすべきではないかということです。

私たちは、GOでフロントエンドを作ることを一般的に推奨していないことを明確にしたいと思います。私たちにはそれをするいくつかの非常に良い理由がありました：強いゴーエンジニアのチーム。タイプスクリプト/反応がうまく縮小しなかった複雑なUI。 2つのコードベース間の標準化と再利用の要件。そして、速度を高めるための全社的な任務。それはかなり具体的な状況です。同様の状況にある場合、これは確かに評価する価値のあるオプションです。そうでない場合は、最初に検討する必要がある他のツールと標準があります。

Dagger Cloud V3はまだベータ版であり、私たちはあなたに興奮しています 試してみてください。実装について詳しく知りたい場合、または新しいUIを共有するためのフィードバックがある場合は、私たちの不一致に参加して お知らせください あなたが思うこと！