はじめに
イタンジのエンジニアリングマネージャの田渕です!
先日、OHEYAGOのフロントエンドのNext.jsへのリプレイスが完了しました。
振り返ってみると、リリース前はRailsのテンプレートエンジンを使っていたところから徐々に変更をしていき、最終的にはNext.jsまで辿り着いたなあ、と感慨深かったです。
「1年半ほどコツコツ改善を積み重ねて、結果的にモダンな構成まで辿り着いた」という成功例だと思うので、皆様にその変遷を紹介していきたいと思います!
この話を通して、イタンジの技術選定に対する考え方を、具体例を交えて紹介できればと思っています。
また、今後フロントエンドのリプレイス等を考えている方の参考にもなれば幸いです。
開発初期はテンプレートエンジンを利用
何を作っていくべきかを見極めるフェーズでは、テンプレートエンジンを使っていました。
サイト名もサイトのコンセプトすらも固まっていない段階だったので、フロントエンドはプロトタイピングに近かったと思います。
そのため、開発速度を重視しテンプレートエンジンを選ぶことになりました。
要件的にも基本的にはテンプレートエンジンで十分で、一部だけピンポイントでReactのコンポーネントを埋め込んでいました。
コードの共通化はReact側ではなく、RailsのPartial templatesを活用して行っていました。
リリース前までにほぼ全てをReactのMPA(Multi Page Application)にリプレイス
OHEYAGOという名前が決まったあたりで、サイトのコンセプト上、UI/UXには注力しなければいけないことが分かってきました。
UXに着目すると、jQueryやテンプレートエンジン等だけで頑張って実装するよりは、本格的にフロントエンドのフレームワークを導入するほうが良いという判断になりました。
UIに着目すると、開発速度と保守性を向上させる必要が出てきたため、コンポーネント指向とアトミックデザインの導入が決まりました。
また、チームの体制的にも、マークアップが得意なデザイナーとより効率的に共同作業するために、フロントエンドとバックエンドの分離も進めていきました。
こういった経緯で、テンプレートエンジンのコードを一新しつつ、1ページずつReactに置き換えていきました。
重要なページからReactに置き換えていったことや、徐々に置き換えていったこともあり、SPA(Single Page Application)にはせずに、MPA(Multi Page Application)になりました。
この時点ではテンプレートエンジン自体がなくなったわけではなく、テンプレートエンジンにはエントリーポイントの記述のみが残っていました。
<%= tag.div( id: 'hoge', data: { 'hoge' => @hoge } ) %> <%= javascript_bundle_tag('hoge') %>
具体的には、上のような記述だけが残っていました。
型安全なTypeScript化
当初からTypeScriptは導入されていましたが、リリース直前は結構慌ただしくなってしまったことと、単純にフロントエンドの知見不足もあり、TypeScriptの力を活用しきれてはいませんでした。
そのため、リリース後には、かなりリファクタリングに比重を置きながら開発を進め、型安全性も高めました。
先にコストを払ってコード品質を高めることで、今後の開発速度を高め、結果的により高い生産性を出すことが目的でした。
TypeScript化に関する具体的な話はこちらの記事もご覧ください。
徐々にSPA(Single Page Application)化
しばらくはMPA(Multi Page Application)で開発を進めており、その範囲でできるUX向上施策を行っていました。 具体的には、JavaScriptの容量削減や、PageSpeed Insightsの結果改善等を進めていました。
しかし、さらなるUXの向上のためにSPA化をしていく必要性が出てきました。
そのため、フロントエンドにReactRouterを導入し、部分的にSPA化を進めていきました。
しかし、完全なSPA化を行うためには、SEOやOGPのためのmetaタグの問題があり、全てをSPA化はしませんでした。
具体的には、動的に作成したOGPタグをtwitter等のサイトが評価してくれないという問題等がありました。
また、この時点でもRailsのテンプレートエンジンは残っていますが、データをテンプレートエンジンへの埋め込みではなく、APIからの取得に変えていくという変更を加えています。
<%= javascript_bundle_tag('hoge') %>
上記のようにエントリーポイントの埋め込みと、application.html.erb
でのmetaタグの描画のみを、テンプレートエンジンで行っていました。
Next.jsへの置き換え
最終的に、「完全なSPA化によるUXの向上」と、「SEO上の懸念がないサイトにすること」を両立するためには、Next.jsが必要となりました。
テンプレートエンジンに依存していたmetaタグの生成をNext.jsで行う他に、ファイルのディレクトリ構成や命名規則等を変更していく必要がありました。
実装量は多かったですが、すでにデータ自体はAPIからの取得に変わっていたため、基本的にフロントエンドだけに変更を加えれば良い状態でした。
一度新規機能の開発を止め、気合で実装し、Next.js化を一気に行いました。
まとめ
最初からNext.jsを考えていたわけではなく、その時々で「どういう課題があるか」を意識して、適切な技術選定をしていきました。
また、こういった変更ができた背景には、そもそものコード品質を意識して開発をしていたおかげでもあります。
ひたすらTypeScriptに型をつけた時間は、決して無駄ではなかったと確信しています。
このように継続的な改善を行うことで、無理なく、ビジネスを止めることなく要件を満たしていけました。
おわりに
イタンジでは、課題にしっかりフォーカスした上で、継続的に進化できるソフトウェアを開発しています。
今回の記事で、イタンジの技術選定の雰囲気を知っていただけたら幸いです!