Interoperability of webassembly with javascript

Editor's Notes

• #5: モダンWebアプリケーションで、スタティックWebアプリは選択肢のひとつとして注目されています。Web APIやサーバーレス・ファンクションで小さな機能を作ってマイクロサービス化、マッシュアップするアーキテクチャは、インクリタルデプロイやブルーグリーンテストのようなCD/CIライフサイクルマネージメントに向いているからです。
• #6: コンテンツを配信するというのは、乱暴な言い方をすれば問題解決領域から得られたコンテンツを何かしらのプラットフォームでユーザーに届けると言えると考えます。クラウドネイティブなソリューションでは、コンテンツ配信の仕掛けをどのように作るか？を計画する際に、コンテンツ配信を如何にコスト効率よく運用していくか？についても考慮する必要があります。 開発者からの目線で考えると、変更がつきもののクラウドネイティブソリューションでは、変更の際の範囲、影響、正常動作検証作業、リソース管理単位が最も小さいことが理想的です。 そのためドメインではマイクロサービス化した複数の機能の組み合わせでソリューションを構築し、適切なプラットフォームから配信する方法が選択肢のひとつになります。
• #7: プラットフォームから配信するコンテンツがHTMLやXML、VideoやeBookなどのスタティックなコンテンツであれば、サービスサイドの動的なコンテンツ作成を必要とすることなくAzure CDNなどのContents Delivery Network（CDN）を利用することができます。また、CDNの中には動的サイトアクセラレーション（DSA）というサービスサイドレンダリングを行う機能（サービスサイドプログラムや外部Web APIを利用したサービスサイドマッシュアップによってコンテンツを動的に生成する方式）をサポートするCDNサービスプロバイダーがあります。AWS CloudFrontは、DSAの一部の機能TCP制御の最適化（スライド右上）を行っています。【クリック】DSAを利用しないCDNを使ってインタラクティブ操作を行うためにはエッジ側のHTMLクライアントから通信を開始する必要がありJavaScriptを使って動的にコンテンツを変化させていきます。
• #8: CDNではスタティックなコンテンツが配信されます。つまり、通常のJavaScriptやJavaScriptフレームワークであるReact、Angular、Vueはサーバーサイドレンダリングモデルですので、最初のリクエストに対する最初のレスポンスでコンテンツは一度レンダリングされます。ステートの変更は再度リクエストを発行することになります。 Blazorの場合サーバーホスティングモデルがありSignalRでステートの変更はサービスサイドからプッシュされますが、CDNでスタティックなコンテンツを配信したい場合はBlazor　WebAssemblyモデルを使用することになります。
• #10: CDNでスタティックなコンテンツを配信する場合、ステートの変更を常に意識する必要があるためユーザーの操作、またはポーリングによってサービスを再リクエストします。この時の仕組みをもう少し掘り下げます。 React、Angular、VueなどのJavaScriptフレームワークはPromise based HTTPクライアントであるAxiosなどのフレームワークで再リクエスト部分の製造の省力化を図れます。Blazor WebAssemblyを採用する場合もAxiosを使えますが、.NETをエッジ側のブラウザで実行するので.NETアーキテクチャを利用するほうがさらに効率的にコンテンツ配信を構築できます。 そのような理由から、CDNによるスタティックなコンテンツ配信というシナリオの学習の入口としてBlazor WebAssemblyは親しみやすい技術ということです。 重要なことは、ユーザーインタラクティブな機能を作成する場合、サービス側との通信の発生を最小限に抑えながら最新のステートを得るようにします。そのため、エッジ側のJavaScriptとWebAssemblyの相互通信を計画しながら作業内容をエッジ側にオフロードする設計が必要になります。
• #11: エッジ側にオフロードする設計のサンプルとして、ストリームでフリーのSVGを受け取り、エッジ側でユーザーが色付けして自分のアイコンを作るというものです。このアプリをスタティックWebアプリとして構築するのでこのような構成になります【スライドを説明】。
• #12: サンプルアプリソリューションを稼働させるためにはBlazorのデバッグ機能が必要になります。Visual Studio Codeの機能拡張「Blazor WASM デバッグ拡張機能」をインストールします。
• #13: プログラムはdotnetのテンプレートから作成します。Windowsターミナル（コマンドプロンプト）で「dotnet new list」でテンプレートの一覧が出ます。「dotnet new blazorwasm –h」でオプションの一覧が出ます。スタティックなWeb AppはBlazor　WebAssemblyでホストはしないアプリとして作成するのでオプションを確認します。既定でfalseなのでそのまま「dotnet new blazorwasm」を実行できます。プロジェクトを作成するディレクトリを必要に応じて用意し、Windowsターミナルでカレントディレクトリにしてから実行してください。 ホストしても良いのですが、ASP.NETサーバーのStart.csを変更する記事がインターネットには多数配信されています。間違ってそれを適用すればASP.NETサーバーに依存することになり、Blazor　WebAssemblyの可搬性は失われます。ASP.NETサーバーで稼働すること、他に移植しないことが分かっているものについてはホストしたBlazor　WebAssemblyを作成しても問題ありません。
• #14: Extentionも追加しておきます。このセッションでは必要ありませんが、重要な作業なのでいくつかの例をご紹介します。
• #15: Graph SDKはBlazor WebAssembly用のMicrosoft Graph Authentication APIをサポートしたものが配信されています。
• #16: 新たなGraph Authに対応するWebAssembly側パッケージも用意されています。
• #17: カレントディレクトリには様々なファイルが作成されますので、Windowsエクスプローラーで確認してください。Visual Studio Codeでこのフォルダを開きます。
• #19: 最初に開いたときに必要なファイルのダウンロードが自動的に開始します。
• #20: 最初のダウンロードが終わったらデバッグの起動の設定を行います。「Properties-launchSettings.json」の「profiles-SVGIconColoring(プロジェクト名)-applicationUrl」のアドレスを「.vscode-launch.json」の「configurations-url」として設定しておきます。
• #21: Run & Debugで実行を行います。ブラウザが起動して、しばらくアセンブリをダウンロードしてコンテンツが表示されます。この最初のレイテンシを覚えておいてください。
• #22: スタックはサーバーとブラウザが起動しています。ブラウザを閉じるとサーバーのスタックだけ残ります。続けて実行パネルの赤い四角をクリックするとサーバーも終了します。
• #23: 今回は認証の実装を行いませんが、Blazor WebAssemblyとJavaScriptの相互通信を簡単に説明するため、サインインのリンクとJavaScriptのプロンプト表示、入力された名前をサインインのリンクに表示するという一連の流れをコーディングします。コンテンツのページヘッダの部分の「About」の手前に「SignIn」というリンクを設定します。これは「Shared-MainLayout.razor」を編集します。
• #24: HTML側はAboutの前にこの2行を追加します。AタグにセットされているBlazorの「@onclick」に「SignIn」を呼ぶように指定してありSignInではSetSignInTextというJavaScriptファンクションを呼ぶように指定しています。JavaScriptとのインターオペラビリティとしてBlazorではIJSRuntimeクラスが提供されており、JavaScriptを非同期で呼び出す際にその処理を待つInvokeAsync、処理を待たないInvokeVoidAsyncがあります。 初期状態では「SignIn」という赤い文字が表示されており、それをクリックするとJavaScriptが実行され、実行結果が表示されるというものです。
• #25: DOMに書かれたBlazorのonclickイベントがBlazorのSignInタスクを呼び出し、JavaScriptのSetSignInTextファンクションを呼び出しました。JavaScriptは必ずindex.html（またはindex.htmlにインクルードしたJavaScriptに定義します）。
• #26: ここではJavaScriptのpromptでユーザーが入力した名前を返すようにしています。入力されなかった場合はそのまま赤い文字「SignIn」を返します。
• #27: 画面の流れ
• #28: フリーSVGサイトのアイコンはユーザーの最初のサイトアクセスで表示するようにします。ユーザーがログインしているかしていないかに関わらず一覧は表示できますので、サービス側で呼び出します。
• #29: サービス側でレンダリングするコンポーネント「Pages-Index.razor」で作成していきます。SVGsコレクションにIcon Fontsから取得したSVGを下部の「@code」で詰め込んでいますのでforeachでHTMLを書き出だしています。一覧の下部にユーザーが選択した画像が表示されるようになっています。その下に「message」としてプログラムのプロンプトを設置しています。アラートやワーニング、インフォを表示する場所です。
• #30: SVGsコレクションの作成のコードの中身は、アイコンのURL、IMGタグのSRCアトリビュートの値、アイコンのSVG、アイコンのURLです。基本的にはURLで取得しますが、ユーザーが選択肢し、その後オリジナルのURLが無効になったりオフライン時の操作用として、ユーザーが色を変えたい時などに使います。MarkupString型を使っているのは、のちにHTMLコンテンツなどに出力するときにBlazor既定のサニタイズに影響を受けない取り扱い易い形で保持するためです。
• #31: SVGsコレクションの作成のコードの中身は、HttpClientでSVGを取得してきます。今回はサンプルとしてID155117から10個取得してきます。今後の拡張として、非同期で順次10個ずつ取得するようなコードを書くことができます。読み込んだレスポンスはストリームなのでXmlDocumentのLoadXmlメソッドで読み込んでOuterXmlプロパティのシリアライズされた値をXMLタグのまま保持するようにMarkupString型に変換して格納しています。また、その際にURLを保持しています。
• #32: 初期画面でアイコンの一覧が表示されます。
• #33: 最後にアイコンが選択された時の動きを作成していきます。これはJavaScriptの機能になるのでindex.html側に定義します。のちにユーザーの選択状態を保存できるように「currentUser」オブジェクトを用意しておいて選択したアイコンのXML（SVG）と色、アイコンのURLとユーザーのIDを保持するようにします。選択されたアイコンのHTML DOMのIDにはアイコンのURLが設定してあります。 このアイコンはコピーして選択エリア（アイコンの色を編集する作業エリア）に貼り付けるので、DOMのIDを「selectedImage」に変更しています。画像が残っていたら削除して新たにコピーすることでユーザーのアイコンの変更で作業エリアのアイコンが変更されるようにします。そしてペンのアイコンを3本作って作業エリアの左に並べ右に選択されたアイコンを表示しています。
• #35: ペンにはJavaScriptのsetColorファンクションが設定してあるので、ペンの選択でペンの色を取得し現在のユーザーのオブジェクトの色属性と選択されたアイコンの作業エリアのコピーの色の設定に使います。作業エリアのアイコンのsrc属性からSVGのXMLを取得しDOMParserでパースします。SVGのアイコンはgタグをいくつか持っています。アイコンのようにシンプルなXMLの場合固定のインデックス0番で問題ありません。そのノードを指定された色で塗っています。
• #38: Static Web AppはCDNを利用したメンテナンス効率のの良いCD/CI環境を構築するためのひとつの選択肢であること、特にサービスメッシュパターンを採用しているのであればメッシュエンドポイントに集約したしたサイドカーやステートマネージメント機能と各マイクロサービスがきれいに分離できます。 特に現在はCDNが動的サイトアクセラレーションをサポートしており、またその手法もDSNのすべてを行っている企業からAWSのようにTCPのチューニングのみを行っているところまで多岐にわたります。
• #39: アーキテクチャを検討する際はリクエストとレスポンスの関係を意識しながらステート管理を計画していくこと重要であり、どのフレームワークを採用するかかについては人員配置を考慮した調達を考慮すればよいのですが、それより重要なことはユーザーストーリーのどの部分をエッジ側に配置し、どの部分をサービスサイドに任せるかの計画が重要です。 また、CDNでの静的コンテンツ配信を目的にASP.NETサーバーから解放されるBlazor WebAssemblyにおいてはCORS制限に引っかかるGraph APIでのAuthについて、マイクロソフトが最新のSDKを提供し始めていることも重要なポイントでした。
• #40: コード解説では、ソリューションのリソースのどの位置に何を配置するかが重要でした。ユーザーインタラクティブな部分をすべてJavaScriptに任せるのも良いのですが、エッジ側でシリアライズされるXMLなどの再オブジェクト化などを考慮すると.NETランタイムで行わせる方が楽だったりします。 ユーザーストーリーのトランザクション境界分離の側面とプログラム効率の配分、シリアライズ／デシリアライズのコスト配分が重要です。