VMテンプレートを効率的にデバッグする方法

背景#

アリババに入社して最初に取り組んだプロジェクトは、非常に古いビジネスであり、フロントエンドとバックエンドが分離されておらず、ほとんどのロジックがバックエンドのVelocityテンプレート内にありました。

フロントエンド開発者として、バックエンド環境のサポートなしにVMテンプレートをデバッグしようとすることは、本当に非常に苦痛なことでした。

なぜなら、どのような要件であっても、以下の手順が必要だったからです。

バックエンドプロジェクト内でVMコードを修正する
aone上でバックエンドプロジェクトをデプロイする。このステップには約30分かかります。
デプロイ成功後、ブラウザをリフレッシュして検証する

つまり、コードを一行修正するだけでも、少なくとも30分のコストがかかるということでした。さらに、開発中はバックエンド担当者のサポートに大きく依存していました。例えば、フロントエンドでブランチフローのAプロセスを表示したい場合、バックエンド担当者にAプロセスのデータを出力してもらう必要があり、その後30分待つ。フロントエンドでブランチフローのBプロセスを表示したい場合も、また30分かかる。もしバックエンド担当者が忙しくてサポートできない場合、フロントエンド開発は一時的に中断せざるを得ませんでした。

一つの要件を終えた後、この開発プロセス全体が本当に苦痛であり、効率も非常に低いことに気づきました。私が2日で完了できると思っていた要件が、丸々1週間かかり、さらに徹夜してようやく何とか進捗に追いついたほどです。

また、アリババの技術は想像していたほど先進的ではないと感じましたが、これもチャンスだと捉え、何か良い解決策はないかと考えました。

方案#

様々な調査と議論の結果、ローカル開発時のVMデバッグ機能を解決するため、velocityjs を使用してフロントエンドでVMテンプレートをレンダリングすることに決定しました。velocityjs は nodejs を介してVMテンプレートを解析し、HTML文字列を生成します。

velocityjs があれば、話は簡単です。あるモジュールのデバッグでは、モックデータとVMテンプレートを見つけ、それをレンダリングしてブラウザに返すだけです。

最終的な解決策は以下の通りです。

実現#

上記の解決策があれば、実装は非常に簡単です。リクエストが来た際の処理フローは以下の通りです。

ローカルのNodeサービスは3000番ポートで実行されます。
ホストを 127.0.0.1 xxx.alibaba.com にバインドします。
オンライン商品のURL https://wholesaler.alibaba.com/xxx/xxx.html の wholesaler を xxx に置き換えることで、http://xxx.alibaba.com:3000/xxx/xxx.html を得ます。
ローカルのNodeサービスはリクエストを受け取った後、まずオンラインサーバーにアクセスし、その商品の元のHTMLと、非同期レンダリングに使用されるモジュールデータ PAGE_SCHEMA を取得します。
PAGE_SCHEMA は、国際サイトの特定のウェブサイトにおいて、バックエンドがVMをレンダリングする際に、そのVMモジュールをレンダリングするためのデータをフロントエンドに同時に返し、グローバル変数 window の下にマウントするものです。
ローカルでデバッグしたいモジュールのVMテンプレートを見つけます。
モックデータ、またはオンラインの PAGE_SCHEMA のモジュールデータを使用してVMテンプレートをレンダリングします。
レンダリングされたVMテンプレート文字列で、元のHTMLの対応するDOMノードを置き換え、再構築されたHTMLを取得します。
再構築されたHTMLをブラウザに返し、ローカルデバッグの目的を達成します。

最終的な結果：上記の環境設定が完了した後、例えば module-xxx というモジュールをデバッグしたいとします。その場合、ローカルで直接バックエンドプロジェクト内のVMテンプレートを修正し、ブラウザをリフレッシュするだけで、変更のフィードバックを得ることができます。しかも、デバッグ状態にあるのはこのモジュールだけであり、他のモジュールはオンライン上の元の状態のままです。