この記事では、前回（ Python で gRPC の単体テスト）に引き続き、 Python で gRPC を使う際の知見をご紹介します。
主に、メタデータとインターセプターの実装法と、そのテスト方法がメインになっています。
まだ experimental API だったり非 public クラスだったりしているので、公式のアナウンスがあるまではプロダクション利用は難しいようにも思いました。
wasm-bindgen で hyperapp を実装しようとした （墓標）
勉強を兼ねて hyperapp の関数を Rust + wasm-bindgen で実装して、 hyperapp の動作高速化を狙ったが、 WebAssembly の制約があり詰まってしまった。
寝る前に思いついて 4 時間だけやっただけなので回避策を見落としただけかもしれないし、 WebAssembly の進化で問題無くなるかもしれない。
yew (Rust) や asm-dom (C++) のように、すべてを wasm 内で実装するのは抵抗があった。
(P)react の高速化ができれば既存の資産を使いつつ高速化できるし、他にも超重量級コンポーネントだけを wasm 化する戦略を採れると思った。
Webpack でルーターのような動作をさせるパターン
昔のプロジェクトでページ描画に使われている依存ファイルについては、あるディレクトリ以下のどこかに実際の対象ファイルがあり、それを探して選び出してくるという関係になっていました。つまり、 require() などに直接変換すれば良いというものではありませんでした。
closure-loader がそんな感じではあります。
今回は、ルーターのような働きをする関数を設けて依存性解決を行います。入れ子だったり流入口が複数ある場合に役立つのかもしれません。
サンプルプロジェクトはこちら
この中では、独自ダグの単純な置き換えだけをやっています。（属性やタグ内の内容はまだ渡せません。）
interpolate-by-query-loader を公開しました
Webpack で似たような entryPoint が大量に並ぶなと感じたため、こちらもユースケースは多くないかもしれませんが、 loader を新たに作りました。
これを使うと、テンプレート化したような entryPoint 用ファイルを 1 つだけ用意して query をくっつけて entry 定義するだけで、 entryPoint を量産できます。
何かある場合は GitHub のリポジトリにお願い致します。
yarn add -D interpolate-by-query-loader |