データ分析基盤チームでエンジニアをしている鳥井です。

最近はこちらの「AWS Batch, Step Functionsを活用した機械学習向けジョブスケジューラーの構築 」で紹介されている内製のデータ分析プラットフォーム「Crois」のWebフロントの開発を主に担当しています。

Croisはいわゆるジョブスケジューラーなのですが、エンジニアからITプランナーまでが利用できるようにさまざまな機能が用意されています（詳しくは上記記事をご覧ください）

CroisのWebフロント（以下、Crois Web）ですが、もともとはFlaskで開発し、そのあとVueによるSPA（Single Page Application）へとリニューアルしました。

自分はもともとサーバーサイド寄りのエンジニアで、フロント開発はjQueryでがんばるといった感じで初級レベルでした。

SPA開発にも興味はあったものの未経験だったため、1人でのSPAへの移行ではいろいろと考えたり苦労をしました。

今回はそのことを簡単に記事にしてみたいと思います。

1. Flask版の開発

Croisの開発が決まったとき、社内向けのデータ分析プラットフォームとしてさまざまな内製プロダクトから利用できるように、APIを提供することも同時に決まっていました。

そのため、Crois Web担当になったときにSPAでの開発も検討したのですが、

• 経験がなかったので開発に時間がかかりそうだった
• JSフレームワークは移り変わりが早く、振り回されないか不安だった

などの理由から、いったん慣れている Flask + Jinja2 で開発していき、落ち着いた頃に改めてSPA版を検討することにしました。

そのあと、プラットフォームとして必要なページを一通り開発し終え、他案件も落ち着いたため、改めてSPA版を検討したところ、

• SPAにしてブラウザから直接APIリクエストをしたほうがレイテンシがよい
• テンプレートでのPython変数の展開と、JSによる操作が併存して見通しがよくなく、SPAでJSのみにした方が開発しやすそう
• テンプレート、CSS、JSの各ファイルが増えて管理が煩雑、SPAならある程度まとめられる
• API結果をページにまたがって持っておくのには、SPAの方がやりやすい

といった（当たり前としてある）利点が改めて大きく感じられました。

また調べるうちにJSのフレームワーク開発競争もだいぶ落ち着いてきたことがわかりました。

この先、Crois Webをよりリッチに使いやすくしていくには、 コードベースが小さいうちにSPAとして開発し直して上記問題を解決したほうがよいはずだと考え、 SPA版を開発していくことを決めました。

2. フレームワークの選定

Crois WebのSPA版開発を行う上でいくつかのフレームワークを調査し、React、Vue、Angularが候補として上がりましたが、最終的にはVueを選びました。

Vueを選んだ主な理由は以下になります。

• 手元で試した中で個人的に一番書きやすかった
  • とくにSFC (Single File Components)により、 関心のあるHTML/CSS/JavaScriptを一箇所に見やすくまとめることができ、継続的な開発にプラスに働きそうだった。
• 既存のプロジェクトに導入しやすそうだった
• SPA化に必要な周辺ライブラリもひととおり揃っており、それらを必要に応じて段階的に導入可能だった
• GitHubのStar数でReactを抜くなど勢いがある
• ドキュメントや検索記事も充実している

このとき部内ではJSフレームワークとしてはReactが広く使われており、 Vueを使ったプロダクトはなく近くに知見を持った人はいませんでした。

しかし、上にあげた理由から1人でも開発しきれそうだと思ったのと、 React以外のフレームワークの知見を持ったメンバーが部内にいたほうが全体としてもプラスになるのではという考えから、 VueによるSPA版の開発をスタートする決断をしました。

Vueを選んだことによるメリットとしては、とにかくコードが書きやすかったことが大きかったです。

一方で、デメリットとしては、手探りで開発を始めたためベストプラクティスからずれてしまった部分が生じてしまったことが挙げられます。 （リファクタリングしながらベストプラクティスへと修正していっています）

3. SPA版の開発と移行

VueもSPAも初めてでしたが、公式ドキュメントやデモプロジェクト、 ブログ記事などを頼りに、SPA版の開発はなんとか進められました。

ただ、SPA版への移行まである程度時間がかかったため、いったんSPA版のページを書き終えても、 Flask版への機能改修や機能追加が入るとSPA版にも同じ変更を加えたりなどの2度手間が発生することがありました。

理想的にはページ単位ごとに移行を行っていくのが理想的だったのですが、 不慣れなためルーティングの制御やFlask版とSPA版それぞれでの状態管理がうまくできず、 いっせいにSPA版へと切り替えることにしました。（ビッグバンリリース！）

入念に動作確認は行いましたが、致命的なバグが発生したときのため、Flask版へのリンクを残すなどの安全策をとっていました。 幸いにも大きな問題が発生することなく移行が完了して、ホッとしたことを覚えています。（細かなバグはいくつかありました）

ひととおりSPA版の開発経験を積んだ今、もう一度SPA版の開発と移行を行えるなら、 2度手間開発やビッグバンリリースは絶対に避けたいので、 ページ単位ごとに少しずつSPA版へと置き換えていくという理想的な移行作業を行いたいところです。

4. SPA移行を終えて

個人的にいろいろと苦労したSPA移行ですが、1. Flask版の開発であげた利点を得られたほかに、

• レンダリング、APIリクエストなどすべての挙動をブラウザデベロッパーツールを通じて監視・操作できるのでデバッグしやすい
• ページパーツのコンポーネント化により、再利用性が高まり、開発効率が上がった

などの利点も得られました。

これらの利点によって、

• 機能・デザインの本質的な部分に集中して開発しやすくなった

ことにより開発者としての利益を得られ、さらにそれにより

• ユーザーによりよいUI体験を提供しやすくなった

ことが今回の移行で得られた一番の価値だと感じています。

個人的には、モダンなフロント開発スキルを磨けたこともこれから開発を続けていく上で大きいと感じています。

これからもSPA移行によって得られた利点と経験を生かして、Crois Webをよりよいものにし続けていきたいです。

まとめ

APIサーバを用意するという前提はありますが、SPAの方が機能改修・追加が容易で、スピーディにリッチなUI開発が可能になることが実感できました。

JSフレームワークの移り変わりが不安な方やフロントに不慣れな方も、新しくWebフロント開発をする機会があればSPAをぜひ検討してみてください。

広告

RCOアドテク部ではフロント開発にかぎらず、一緒にデータ分析基盤を作ってくれる優秀なエンジニアを募集しています。

採用ページ