こんにちは！
LOB アドベントカレンダー一発目はもじばけおからお送りさせていただきます。すきな言語はハイパーテキストプリプロセッサーです！
今回は TypeScript + React というフロントエンドの技術選定について、どういう経緯やロジックで決定したものなのかをお送りします。
これから新規プロジェクトを開始される方の参考になればさいわいでございます。
前提
LOB がやっていること
一言で言うと、広告プラットフォームを開発しています。
事業内容等々はコーポレートサイトに書いてあるとおりですが、要するに楽天経済圏のアセットを活かしたプロダクトを作っています。
TypeScript + React にたどり着くまで
細かい説明は端折らせていただきますが、事業上最初に作らないといけないものは以下の 3 つです。
- 秒間数十万リクエストを処理できる広告配信サーバー
- リリース時からグローバル展開できる(つまり i18n 対応された)管理画面
- 配信用 SDK (iOS, Android, JavaScript)
ここからブレークダウンしてサーバーサイド → フロントエンドの順で技術選定を行いました。
広告配信サーバーについては、わたしの好きなハイパーテキストプリプロセッサーや Python 、 Rust 、 Java や C# など、プログラミング言語はたくさんありますが、以下の条件で絞り込み、最終的に Go に着地しました。
- 高速に動作する
- 可読性が高い
- 書きやすい
- 並列処理も書きやすい
フロントエンドの技術選定開始
先に確定した広告配信サーバーに続いて管理画面をどうするか検討したのですが、どう控えめにとっても Go のテンプレートエンジンは使いやすいとは言い難いものに見え、むしろそこで使うものではないなという感触です。
とはいえ、広告配信サーバーと管理画面向けのバックエンドを同一言語にしておきたいという思いから、 Go からはブレず、 Go には API サーバーに徹してもらうことにし、いわゆる SPA として稼働するアプリケーションを作成することにしました。
そこで候補に上がったのは以下の 3 つでした。
- React
- Vue
- Angular
SPA を作る、だけであればもっと選択肢がありますが、長期間死んでしまいにくい/長期サポートされる期待が持てるものだけを固く選んでいきたいためこの3つです。
平行して検討したことは、型システムの導入です。
事業特性上、大きなエンジニア組織になっていくことが不可避であることが最初からわかっていたため、いろんなフロントエンジニアが同時に同じプロダクトを安心して触れるようにするための対策をいれておく必要を感じたためです。
型システムは Flow か TypeScript の ２ つが候補に上がりましたが、ここは簡単に TypeScript で決定しました。
理由は世に公開されているライブラリの型定義ファイルの数の多さと、 TypeScript 自体の開発の活発さです。(最近のマイクロソフトまじでがんばってますね！)
そして TypeScript を使うことが決まった段階で Vue そして Angular が候補から外れてしまいました。理由はシンプルに 1 つです。
いつまで立っても結論がでない EcmaScript 側の Decorator 問題
Vue や Angular は @Component や @NgModule などの TypeScript の Decorator に依存する形になっていくのですが、この実装に不安を覚えたためです。
憶測でしかありませんが、 TypeScript ⇔ EcmaScript 間の Decorator 周りに関しての絶望的な差分が万一でてしまったことで起きるリスクを飲み込めませんでした。
具体的には、
- TypeScript が EcmaScript に寄せた実装に変更になる
- Vue/Angular も追随
- 何らかの Breaking Changes が発生する
- アプリケーション側がフレームワーク/ライブラリのアップデートを行いにくなる
リスクを飲み込めなかった理由は、万が一が発生してしまった場合に、「アップデートにコストを取られて事業的にやりたいことが後回しになる」 or 「事業的にやりたいことを優先してアップデードするコストを取れない」 という２択問題自体への直面を回避したいからです。
さいごに
さっさと Decorator 決着してくれさえすれば、 Vue や Angular も候補にあがったのに…というお気持ちが強く、とてもモヤモヤするところではありますし、我々の React というチョイスが数年後にゼロベースで考えたときにも大正解なものである、ということではないと思っています。
プロジェクトスタート時、事業上の未来からブレークダウンし、既存のエンジニアメンバーが「その瞬間に」できる/できないを無視して技術選定した一例としてお伝えしてみました。 (ちなみに Go もプロダクション向けにゴリゴリ書いてたひと誰もいませんでした)
直前まで i18n 対応についてのテーマを書こうとしていましたが、「なぜ TypeScript + React でやっているのか」を書き始めた結果、これだけでかなりボリューミーになってしまったので i18n 周りについては別記事でご紹介させていただくことにさせていただきました。
近日中に i18n 記事を別で投稿したいとおもいます。
ではでは。