## プロジェクト概要
このプロジェクトではサービスのフロントエンドを一部別アプリケーションとしての分離を行いました。
## チーム構成
- レビュアー: ２名
- フロントエンドエンジニア: １名
- バックエンドエンジニア：１名
## チーム内の自身の役割
- フロントエンドエンジニア
## 課題
関わっていたプロダクトは開発が始まった当初は Rails をベースに作られており、View 側も jQuery を用いて作られていました。その後、状態を多く持ちリアクティブに動くページを中心に React の導入が行われました。この際 React は Rails のテンプレートに対して読み込む形で使用される形となりました。React の導入により複雑な状態の表現は行いやすくなりましたが、反面 Rails との結合度が高くなってしまいました。
これにより以下のような問題が顕在していました。
- CDN からの配信が行えない
- Rails のテンプレートエンジンから生成される HTML を使っている都合上、アセットをすべて CDN から配信することができない状態でした。
- 海外からのアクセスも一定ありましたが、Rails のサーバーが日本にしかなく海外からのアクセスに対しては表示速度がネックとなるケースが多くありました。
- deploy に時間がかかる
- フロントエンドの コードベースのみの変更であっても、すべて Rails の Asset Pipeline で管理されていたためアプリケーションをすべて deploy し直す必要があり気軽に deploy が行えない状態でした。
また Rails との結合が強いことを起因としたもの以外にも以下のような問題を抱えていました。
- API レスポンスのスキーマが定まっていない
- クライアント側は Flow によって型付けは行われていましたが、サーバー側ではスキーマを管理しておらず意図せず特定のキーが消えたり、型が変わっているといったことが度々発生していました。
- 状態管理が正しく行われていない
- グローバルな状態管理には Flux が使われていましたが、正しく扱われておらずデータの流れが１方向になっていない箇所があり全体の状態遷移の把握やデータ構造の変更が非常に困難な状態でした。
## 取り組み
- サービスを１部別アプリケーションに移行
- プログラミング学習サービスだったのでユーザーさんが最も利用する演習を行うページを優先して別アプリケーションへの分離を行いました。
- 演習を行うページはコースごとに振る舞いや表示が異なり、全て１度に分離・リリースを行うことは時間面でも安全面でも難しかったので段階的なリリースが行えるようにインフラチームとの調整を行いました。
- 仕様を定めた API の開発・データの型定義
- OpenAPI を用いて API の仕様・データのスキーマを定義し、API 開発側もクライアント側も共通のスキーマを意識した開発が行えるようにしました。
- API 開発側ではレスポンスのテストを、クライアント側では API クライアント・型の自動生成を仕様書から行うようにして仕様の担保・変更に追従するコストを下げるようにしました。
- Redux の導入
- クライアント側で多くの状態を持ち、かつ複雑に遷移するアプリケーションだったので Redux を導入してそれらを扱うようにしました。
- Redux DevTools を導入したデバッグ容易性、ユニットテストを用いての動作の保証を行うようにして安全に開発が行えるような状態を目指しました。