rail44

## 3rd Party JavaScriptのための開発環境の整備 広告スクリプトは、一般的なWebアプリケーションのフロントエンドと比較すると、動作させたい端末のOS、ブラウザ、バージョンなどが多岐に渡ります。 そのため、既存の広告スクリプトは `var hoge = fugafuga()` のように新しいキーワードである `let` や `const` を用いることも出来なければ、Promiseのような非同期プログラミングのための機構、更にはモジュールシステムも用いることが出来ていませんでした。 その上で、私の取り組みの意義としては、「モダンなWebフロントエンド開発の体験を、3rd Party JavaScriptにも持ち込む」と表すことができます。 具体的な取り組みと、その中での技術剪定や判断の軸について述べていきます。 - TypeScript - eslint - jest - CIによるテスト/ビルド環境の整備 これらのスタックについては、あまり深く触れずともその効果の程は広く知られる所ですし、あまり私自身の実力を伝えるのに寄与しないと思われるので割愛します。 ### 独自のモジュールシステム モジュールシステムは、現代でこそモダンなブラウザでES Modulesのimport文が使えるようになっていますが、広告スクリプトを動作させたいブラウザの範囲を考えると採用することはできません。 そこで、薄いAMD互換(Asynchronous Module Definition)のモジュールローダーをスクラッチで開発しました。 SystemJSなどの既存のモジュールローダーの採用も選択肢ではありましたが、小さいファイルサイズを実現させたいという要求が強いことと、既存の物は実現したい理想像に対してあまりにジェネリックな使い方を想定していることから機能が重厚すぎるという点から、このような判断に至りました。 ### 独自のビルドシステム 次に、ES Modulesの形式で構築されているTypeScriptのプロジェクトツリーから、スクラッチで書いたモジュールローダーによって動作するdistribution対象のJavaScriptへビルドする仕組みを導入する必要がありました。 ただ、webpackがデフォルトで行うようなチャンクサイズによる自動的なファイル分割は課題に適していませんでした。 なぜなら、広告を読み込む場合には表示させたい商材の特性に応じて必要なモジュールが決定的に定まるため、そのロードのタイミング等は自分達の手で制御したくなるためです。 そこで、こちらについてもrollupをライブラリとして用いるパッケージャを開発することで解決しました。 rollupの機能を用いてプロジェクトの依存ツリーを構築し、予め設定ファイルに記述しておいたエントリポイントにしたいファイル毎に分割し、スクラッチで書いたモジュールローダーを用いた形式で、コミットリビジョンの接頭辞付きでdistディレクトリに書き出す、といったことをしています。 ### 薄いPromise polyfillの導入 広告スクリプトは広告配信サーバーのJSON APIのクライアントとして動作したり、他社の広告スクリプトのロードを待ってから動作するなど、非同期な処理がそれなりに出現します。 この処理をPromiseのような仕組み無しで記述することはそもそも難易度が高いですし、try-catch句のようなエラー処理をコールバックの度に挿入する必要性が生じてしまいます。 しかし、一般的なcore-jsなどによるpolyfillの注入は著しくファイルサイズを増加させますし、3rd party scriptとしての性格上、導入されたwebサイト側のpolyfillとの衝突の危険性があります。 そこで、自分たちにとってはメソッドチェーン形式(.then / .catch)での非同期処理が出来れば十分だという判断をし、こちらも最低限のPromiseとの互換性を持ったPromiseLikeクラスを開発しました。 ### 広告スクリプトを配置するCDNの構築 AWS Cloudfrontを用い、JavaScriptを配信するための環境を整備しました。 特筆すべき点としては、キャッシュの設計とbrotliという比較的新しい圧縮形式を採用したことで、スクリプトそのものの読み込みの高速化を図りました。 また、開発時の検証を容易にするため、Pull Requestを作成することでそのブランチのビルド成果物を実際に動作させ、広告を表示できるような仕組みを構築しました。 AWS S3にアップロードされたビルド成果物を、lambda@edgeを用いてリクエストヘッダから選択することで実現しています。 ### その他 あまり特筆する点が少ないことから割愛しますが、上記スクリプトへ渡るパラメーターのための、バックエンド、リレーショナルデータベース、管理画面への開発も、既存の基盤を元に行いました。 用いた技術スタックは以下のような物です。 - Golang - PHP - Perl - MySQL - ProtoBuf - React 総じて、WebブラウザやHTTP、JavaScriptの詳細な仕様の理解が求められるプロジェクトでした。 また、自己評価ですが、構造化やメタ視点により課題の本質を捉える力が比較的高めで、それを活かして業務を行ったと思います。

上記プロジェクト1で構築した基盤上に、動画広告配信のための各種モジュールと、その表示フォーマットのためのテンプレートシステムを開発しました ## VASTと呼ばれる業界標準フォーマットのパーサーと動画プレイヤーの実装 動画広告については、業界団体であるIABが勧告しているVASTというXMLを用いたフォーマットが標準となっています。 そこで、動画広告を表示するためにはXMLをパースして動画ファイルや広告サイズ、どれぐらいの再生位置でトラッキングをするかなどの情報を取得し、適切な動画プレイヤーとしてWebブラウザに表示する必要があります。 業界団体が公開しているPDFによる仕様書を読み込み、実装すべき物を判断し、実際に形にするというサイクルを行ったと言えます。 この機能は外部ライブラリを導入しつつ開発することが出来ました。リアーキテクチャ以前の広告スクリプトではこのような事自体が不可能だったので、上記プロジェクトの設計の成果とも言えます。 また、この動画広告モジュールは**動画でない**広告の場合には不要であるため動的ロードをするモチベーションが生じますが、これについてもモジュールローダーにその機能を組み込んでいたためスムーズに行うことができました。 ## SolidJSによる広告テンプレートの開発 動画広告は通常の静止画による広告と比較すると、プレイヤーの閉じるボタンや音量ボタンの存在や、ブラウザとしてin-viewかどうかで動画の再生を制御したいという要求から、Web上のUIとしての複雑度が増しています。 それまではWebブラウザのDOM APIを直接用い、document.createElementメソッドやstyle属性を操作することで広告要素を構築していましたが、上記の複雑さから増加したイベント種をハンドリングするには限界がありました。 そこで、広告配信に適した - バンドルサイズが少なく - 高速に動作し - フレームワークというよりライブラリとして用いることのできる UIライブラリを剪定しました。 剪定は実際にテンプレートをPreact、Svelte、SolidJSの3種で開発し、そのバンドルサイズなどの変化を実際に計測しつつ、書き味を考慮しえ行いました。 上記3つの軸で比較検討を行った結果、SolidJSが最適であると判断し、複雑な商材であっても宣言的にUIを記述出来るようになりました。