https://holidays.plasticheart.info
使い勝手が悪い
昨年にふと思い立ち、自分に需要があるからと頑張って日本の休日APIを作ったのだが、結局1年動かし続けてユーザー数は悲しいかな0人だった。そもそもすでにAPIベースで日本の休日を取得できるサービスがあるので、私のような怪しい一個人が急に立ち上げたサービスよりも、すでに実績があってユーザー登録やアカウント連携なしに無料で使えるサービスのほうがいいに決まっている。
逆に良かった点としてはユーザーがいなかったので、これ幸いとすぐにサービスを停止できたことだ。データベースもAPIサーバーも10分くらいですべて削除して綺麗にできた。
時代はJavaScript
かといって、自分に需要のあるネタではあるので、何かしらの形で存続したかった。すべてJavaScriptで記述することもできたが、ロジック的に性能が求められる部分もあるので、ちょうどいい機会と思ってRustによるWebAssemblyに手を出してみた1。
これなら今流行りのJavaScriptで利用できるし、ネットワークの疎通さえあれば使えるので、ウェブアプリケーション全盛期にはもってこいだ。
意外と簡単にできた
数日前まではWebAssemblyという言葉は知っていて、RustやC++で開発したモジュールをJavaScriptから呼び出せるくらいの認識だったので、MDNのドキュメントを参考にWebAssembly用のプロジェクトにしてみた。Application層やPresentation層といった余分なコードはすべて削ぎ落とし、主要ロジックのDomain層だけになった。保守するコードが減ってとても喜ばしい。asyncのコードもDependency Injectionもない。
JavaScriptとデータを受け渡しする部分も、あらかじめDTO2を作っておいてJsValueで受けてからお決まりのserdeで一発。拍子抜けするくらいに簡単だったので、もしこうした計算ロジックが主体となるライブラリを作るならWebAssemblyは選択肢になりうると感じた。
しかし、MDNのドキュメントの内容には余計な部分と足りない部分があったので、思い通りの形になるようにGeminiと対話しつつ改良した。主には、
- Cargo.tomlの最適化
- Wasmを呼び出すJavaScriptグルーコードの容量削減とMinify
- Wasmを呼び出すJavaScriptグルーコードへのさらなるコードの追加
を行っている。残念なことにWasmの容量は減らなかったが、当初15KBほどあったグルーコードは7KBくらいまでに減った。
WebAssemblyいいですね
初めてから実質2日くらいでサービスを新しい形に刷新できているので、WebAssemblyの開発自体の難易度はそれほど高くない。しかしRustやC++といった一定の技術力が必要な言語が要求されることが一番の難点にも感じるし、そもそもそこまでして高速化したいものがあるのかという視点もある。どちらかといえば特定のロジックをモジュール化できて、たまたまそれが高速に動くくらいの認識のほうがいいのかもしれない。
代替案としてC#のBlazorを使っても開発できるようだが、簡単なことをするだけなのに呪文が長くなりそうだとか3、Microsoftのお家芸でいつサポートを打ち切るのかわかったものではないという不安要素は残る。