こんにちは、READYFORバックエンドエンジニアの森です。
花粉症シーズンの到来と共に、リモートのありがたさを感じています。
READYFORでは昨年約1年かけて、実行者さんの利用するプロジェクト管理画面のうち、プロジェクト編集画面のリニューアルを行いました。
この記事では、約1年に渡るリニューアルを、3つのチャレンジと共にダイジェストでお送りします。
チャレンジ1：フロントエンドの分離
元々1つのRailsアプリ上でフロントエンドとバックエンドが密結合していたため、プロジェクト管理画面に限らず改修が難しいところもあり、以前からフロントエンドを分離したいという話は挙がっていました。
今回は大幅にリニューアルすることもあり、今後の開発面のコストや実行者さんの体験も考えて、フロントエンドを分離し、Next.jsでSPA化する方向で進めていきました。
SSGで出力した静的ファイル群でのアプリケーション実現や、Reduxでの秩序のあるグローバル状態管理など、新しい取り組みをたくさん盛り込んだ開発となりました。
中でもReduxについては知見が少なく、たくさん試行錯誤してしまったのですが、立ち上げ当初にしっかりと設計を行っていたおかげで、コードがカオスになることなくリリースまでやり遂げられました。
運用を開始してみて、UI/UX面での改善、リファクタリング、パフォーマンスチューニングのしやすさなどの面で、SPA化による恩恵を早くもたくさん感じています。
Railsからフロントエンド分離していく大きな一歩となりました。
Redux の初期設計については、Takepepeさんに多大なるご協力をいただきました。
資料にまとめていただいているので、ぜひご参照ください。
全体的なフロントエンドの技術選定等については、こちらの記事にまとめられています。
また、2月5日に「実践！フロントエンド分離戦略」という、フロントエンドメンバーによるフロントエンド分離の取り組みについての勉強会を開催しました。
セッション資料を含めた振り返り記事も公開していますので、こちらもぜひご覧ください！
チャレンジ2：スキーマ駆動開発
開発は「スキーマ駆動にした方が良さそう」となり、以下の流れで進めていきました。
- 画面レベルでAPIリクエストが発生する箇所等の認識合わせをする
- OpenAPI仕様に則ってスキーマに落とし込む
- フロントエンド、バックエンド双方のレビューの後マージ
- フロントエンド、バックエンドそれぞれで開発を開始
最初の方は「こんな感じ…？」と手探り状態でしたが、何度かスキーマ修正を繰り返すうちに、認識合わせ→スキーマ修正→開発の流れが自然とできるようになり「スキーマ駆動できていそう…！」という感覚になってきました。
一方で、APIの疎通確認がQA直前になってしまったりして、QA序盤にうまく通信できないなどドタバタしてしまったところもあったので、疎通確認はどのタイミングで行うか？など、課題に感じるところもありました。
ある程度できたところで確認ポイントを置くことで回避はできそうですが、確認ポイントを置きすぎるとスキーマ駆動の旨味がなくなってしまうと思うので、良い方法を探っていきたいところです。
スキーマの管理
スキーマを定義しているYAMLファイルは別リポジトリで管理し、フロントエンドのリポジトリ、APIを含むREADYFOR本体のリポジトリそれぞれで、gitのsubmoduleを利用してスキーマファイルを参照できるようにしています。
- フロントエンド
スキーマを元に、OpenAPI GeneratorでTypeScriptの型ファイルを自動生成 - バックエンド
テストコードでスキーマをチェック
というように各々のリポジトリでスキーマを利用しているので、それぞれで参照できるようにして良かったな〜、と思っています。
チャレンジ3：バックエンドのAPI開発
正直なところ、あまり踏み込んだチャレンジができなかったのですが、検討段階まで進んでいたところとして、下記のようなものがあります。
- APIはREADYFOR本体から分離するのか、同居させるのか
フロントエンド同様、APIもREADYFOR本体から分離することも考えていました。
ですが、仕様が見えにくいところもあり、どこからどこまでを分離させるか？など定まりきっていない状況での分離は難しいと考え、同居する形をとりました。
今後は、APIも分離する方向での検討ができればと思っています。
- GraphQLかREST APIか
技術選定時点では、GraphQLにするのか、REST APIにするのか、という検討も行なっていました。
検討はしたものの、実装予定のAPIがリソースに対する操作になることなどを踏まえ、当時はGraphQLを採用するメリットがあまり無かったこともあり、REST APIを採用しています。
また、チャレンジとは少しずれますが、API追加に伴いカバレッジを落とさないようにする、というのは決めていました。
カバレッジ向上の記事にあるように、READYFOR本体があまりカバレッジが高くない状態だったため、開発中は「テストは何が何でも書いていく」という気持ちで実装とテストを一緒に追加していました。
結果、追加したAPIや関連するコードに関しては、ほぼテストコードも揃っている状態になり、その後の修正も安心して進められているので、貫いた甲斐があったなぁと思います。
おわりに
プロジェクト編集ページのリニューアルにあたっては、いくつかチャレンジできた分、技術的負債の回収も進み、次の手を打ちやすくなるような改善もできたのかなと思っています。
今回はプロジェクト編集画面でしたが、プロジェクト管理画面は他のページもあるので、すでに次のページのリニューアルが始まっています。
プロジェクト編集画面のリニューアルで得た知見を活用しつつ、負債の回収や改善もぐいぐいと進めていければと思います。
やっていき！！
