TechFeed JavaScriptエキスパートの@ahomu氏に現代のフロントエンドアーキテクチャ設計のポイントを伺ったインタビューの後編をお届けします。後編では、動的なサービスを実例としてアーキテクチャを検討するプロセスをご紹介し、さらにフロントエンド設計の今後についても展望していただきました。インタビュー前編もあわせてお読みください。聞き手は前編と同じくTechFeed CEOの白石俊平が務めます。
今回話を伺ったエキスパート
フォローしよう！
ケース2 - 検索機能など動的なサービス
– それでは動的なサービスの場合にはどのようなフロントエンドアーキテクチャにすべきでしょうか。
Offersの候補者検索機能のように、企業クライアントがログインして使う画面など動的なサービスの場合、フロントエンドには手堅い作り(Typescriptによる型付け、ドメインロジックの切り離し、適度な粒度でのコンポーネント分割など)が求められます。
一方でログインが前提のサービスでは、ログイン直後にある程度読み込みに時間がかかるのは受け入れられていますので、初期表示の速度をそこまで突き詰める必要はないかと思います。速いに越したことはないですがやはり手堅さ優先ですね。
このように手堅さを優先する場合、周辺ライブラリやコミュニティの成熟度を考慮する必要があります。一番市場で調達しやすいノウハウで手堅く作れる、複雑なものを作るときもどうすればよいかわかっている/経験値が溜まっているという点で、Next.jsやReactを選択します。
--静的なオウンドメディアとは異なり、動的なサービスはシンプルにNext.jsで普通に作ろうということになるのですね。
静的なオウンドメディアであれば、AstroやQwikなど比較的新しいものを試しやすいのですが、手堅さが求められる動的なサービスではその余地はあまりないですからね。
現状のチームにはVue.jsのノウハウもあるのでNuxt.jsも選択肢に上がっているのですが、市場から採用できるフロントエンドエンジニアの多くがReactが得意ということもあり、今後フロントエンドエンジニアの人数が増えた場合や手堅く作ることへのコミットのしやすさを考えると、むしろReact(Next.js)にするのもありだと考えています。
– 社内の人員構成/採用などの要素もこれらの選択に影響してくるわけですね。では、HTML/キャッシュ/JavaScriptの基本的な3要素を見ていきましょうか。セッションでは、動的なサービスではキャッシュは難しく、SPAとして構成して、HTMLはクライアントサイドで生成するパターンをご紹介いただきました。
ログインが必要な動的なサービスの場合、画面をまたいで状態を引き継ぐ必要がありますので、SPAにするしかないと思います。サーバサイドで状態を保持して状態を引き継ぐ古典的なMVCの手法は、もはやイメージできる人も少なくなってきています。
--SPAとなるとJSの肥大化が気になりますが、JSの最適化についてはどうでしょうか。
これは非常に泥臭い戦いになります。新技術による賢い最適化もあるとは思いますが、先ほどの手堅さを優先するということになると、今の時点ではそこまで新しいものにチャレンジすることはないと思います。もう少し成熟してくれば、一定規模のWebアプリケーションであってもTTI(Time to Interactive)を犠牲にせずにハイドレーションを実現するフレームワークを選択できるようになるのではないかと期待しています。
まとめ - プロダクトの特性やユーザー体験に合わせた適切なフロントエンドの設計を
--今回は静的なオウンドメディアと動的なサービスの2つの場合に分けて、フロントエンドアーキテクチャをどのように設計するか、深くお話を聞くことができました。これまでのフロントエンドアーキテクチャといえば、SPAだけに偏りがちだったかと思いますが、今回ご紹介いただいたように、静的なオウンドメディアの場合にはMPAのほうがいいという判断に変わっていたり、変化が起きているようですね。
静的なオウンドメディアでのSPAからMPAへの切り替えは、プロダクトの特性や実現したいユーザー体験にあわせた適材適所のソリューション選択の結果です。
実際にSPAからMPAに切り替わっている例として、Ameba Newsさんの発表をご紹介します。Ameba Newsさんの場合は静的なメディアに該当しますが、もともとはReactとexpressを組み合わせたSPAだったものを、MPAに切り替えています。本来どのようなユーザー体験を目指すべきかを踏まえて、適切なソリューションを選択した良い例だと思います。
--なるほど。これらの変化は適材適所のフロントエンドアーキテクチャ設計の結果ということですね。それでは最後に、フロントエンドアーキテクチャ設計のポイントをあらためてまとめていただけますか。
今回お話した内容を踏まえて、現代のフロントエンドアーキテクチャ設計において重要視すべきポイントは次の2つです。
- プロダクトの特性/実現したいユーザー体験からアーキテクチャを逆算する
- 並行して、既存の組織やチーム状況、採用戦略を踏まえつつ、コードのメンテナンス性、成熟度、すでに使っている技術との親和性などを組み合わせて最終的に判断する
フロントエンドアーキテクチャを設計するときには、これら2つのポイントを両輪で考えなければなりません。
--ちなみに、現在ではなく数年前であれば、Offers Magazineはどのような作りにしていたでしょうか。たとえば2020年や2021年ごろのフロントエンド界隈がもっとSPAに傾倒していた時代、なんでもNext.jsで作ろうとしていた時代ではどうでしょう？
実は当時からなんでもNext.jsを使う風潮には危機感をおぼえていたので、結論は変わらないと思います。
もう少しさかのぼって、2018年ごろに個人ブログで「JavaScriptよ。文明を捨て、自然に還れ。」という記事を発信しています。
当時はJavaScriptでできることは全部JavaScriptで、という方向にフロントエンド開発界隈が傾いていたと思います。その結果、開発体験はたしかに良くなりましたが、npm installで気軽にモジュールを追加して無邪気にバンドルサイズを膨れ上がらせてしまい、結局はみんなキャッシュでどうにかバンドルの読み込みを速くしようと苦しんでいました。これは2022年現在も続いている問題です。
JavaScriptでなんでも実現できることに開発者が満足している一方で、プロダクトで実現したいことに対してJavaScriptのサイズばかりが大きくなり、TTIが大きくなりユーザー体験を犠牲にしているということは、フロントエンドの大きな問題だと考えています。
最近は、開発体験とプロダクトにフィットする適切な力加減を併せ持つソリューションが揃ってきていると思います。今後はJavaScriptで何でもやるという時代から、プロダクトの特性やユーザー体験に合わせた適切な設計への揺り戻しが強くなると思っています。
