Next.js(App Router) の活用について_技術顧問hiroppyさんとの取り組み

こんにちは！エンジニアの髙橋です。

Rebase は 2023年12月より hiroppy さんを技術顧問に迎え、プロダクト開発体制の強化に取り組んでいます。

hiroppy さんとの定例及び非同期のコミュニケーションを通じて、様々な技術的な示唆を得ています。そして、実際それを自社サービスの instabase（以下インスタベース） と TOIRO の開発と運用に反映しています。

2023年11月27日にリリースした新規プロダクトのTOIROの開発には、Next.js(App Router)　が使われています。

今回の記事では、Next.js に関する質疑応答の一部を抜粋してお伝えいたします。※質問及び回答内容は当時のものであり、現在の仕様と異なることがあります（2023年12月時点）

Ruby on Rails から Next.js へ移行した場合のメリット・デメリットの整理

Q.

現在インスタベースは Ruby on Rails と React で運用しており、フロントエンドのサーバーとして Next.js の導入を検討しています。

改めて Next.js を導入する場合のメリットとデメリットは何が考えられるでしょうか？

A.

考えられるメリットとしては下記があります。

1. Haml 等の HTML が肥大化してくると View 周りのメンテナンスが難しくなるので、コンポーネント管理を React で統一することでメンテナンスをしやすくする
2. 様々なレンダリング手法があるため、サービスに合った方法を選択できる
3. フロントエンドのインフラが隠蔽されており、コードを書くことに集中できる
4. フロントエンドエンジニアを採用しやすくなる

一方デメリットとしては、

• レンダリング用のサーバーが増え、監視・管理コストが増える
• SSRなどにより、テンプレートエンジンを使ったページよりもキャッシュの使い方によっては表示速度が遅くなる可能性がある
• バックエンドエンジニアがフロントエンドを触りづらくなる
• App Routerを採用する場合、まだルーティング周りのバグが残っており、アップデートのたびに壊れる可能性がある
• App Routerを採用する場合、UIで表現できない制約がある

デメリットもあるので、一概に Next.js に移行しようとは言いづらいです。また、Pages Routerは安定してますが、App Routerはまだ不安定な点がありどちらを選択するかという点も考える必要があります。TOIROではApp Routerを利用し、本番で稼働させており、多くの知見があるのでどちらを選択するかは決定しやすいのかなと思っています。

リプレイスには大きなコストがかかるので、Ruby on Railsの何が問題でNext.jsでどう解決できるのかを含め慎重に考えていければと思います。移行すると決めたら、1ページずつ徐々にNext.jsに移行する方法が良いのかなと思います。フロントエンドエンジニアの採用への影響もあるので、会社として今のフェーズと相談し、どこに投資するのか決めるのが大切だと思います。

Q.

instabase では CDN を利用しているため、Next.js のキャッシュを使う必要性は低いと考えています。

Next.js のキャッシュを無効化し、それ以外の機能を利用することについてどう思われますか？

A.

App Routerの場合でお話します。Next.jsのキャッシュは様々なレイヤーに存在し複雑なため、server側のNext.js のキャッシュを無効化して利用することも選択肢の一つだと思います。max-ageが短いページではNext.jsのキャッシュを有効にしたほうが良いので、特定のページだけ有効化する戦略も選択肢の一つです。また、実験段階の Partial Prerenderingが入ることにより、複雑性が今よりは減るかなと思います。なのでPartial Prerenderingが安定的になった頃にまた再考するのが良いでしょう。

ServerAction について

Q.

TOIRO では ServerAction を一部導入していますが、それに関して何か懸念点やデメリットはありますか

A.

Server Action中でどこまでの処理を書くかによりますが、Web だけではなく、ネイティブアプリの構想がある場合に、コードの二重管理が発生する可能性があります。またセキュリティに対してのベストプラクティスも確立されていません。実験段階のTaintのAPIが使いづらく、完璧に秘匿データの保護ができるかというと書き方によっては保証ができません。stable ではありますが、そのような細かい部分がまだ安定しているとは言いづらいのでサービスとしてどこまで許容できるか判断が必要です。世の中にWebサービスで利用した知見がまだ少ないので使った感想を発信していってください。

layout.tsx と page.tsx の棲み分けについて

Q.

meta 情報は layout.tsx と page.tsx どっちに書くのが適切でしょうか？

また、 layout.tsx と page.tsx の棲み分けはどのように判断すれば良いでしょうか？

A.

ページ固有の情報であれば page.tsx に書くのが適切です。layoutに書いてしまうと他のページのmetaへ影響を与えかねないからです。ただ、同じ記述を page.tsx にそれぞれ書く必要はないので、 共通のmeta情報は layout.tsxに記述し、マージしていくのが今のところ良いかなと思います。

Next.jsのドキュメントではどちらがいいのか？という方針は持っていないため、layout.tsx と page.tsx の棲み分けはチームの方針として決めていいと思います。

まとめ

いかがだったでしょうか？

もちろん、この記事で抜粋している内容に限らず、hiroppy さん自身の Try＆Error から得られた知見や最新技術への意見交換等を積極的に行っています。定例会後、Rebase エンジニアの中でも積極的な議論が行われ、実際のプロダクト開発にもその成果が反映できていると実感しています。

最後になりますが、今後も hiroppy さんとの様々な取り組みを発信していきますので、ぜひご期待ください！

※ 今回は、hiroppy さんにインスタベース上で抑えたメタバース空間からミーティングに参加していただきました。メタバース空間の詳細は、ぜひ以下のページよりご覧ください。

https://corp.rebase.co.jp/news-posts/20240122