Webアプリケーションフレームワークの多様化やフロントエンジニアの守備範囲の拡大などの変化が起きている2022年現在、適切にフロントエンドアーキテクチャを設計するにはどうしたらいいのか - TechFeed JavaScriptエキスパートの@ahomu氏に、TechFeed CEOの白石俊平がオンラインでお話をうかがいました。本稿では現代のフロントエンドアーキテクチャ設計のポイントと、静的なオウンドメディアを実例としてアーキテクチャを検討するプロセスをお届けします。
今回話を伺ったエキスパート
フォローしよう！
2022年におけるフロントエンドアーキテクチャ設計のポイント
– まずは現代のフロントエンドアーキテクチャ設計におけるポイントについて、あらためて教えていただけますか。
2022年現在のフロントエンド界隈では、React / Angular / Vueなどを使ったコンポーネントベースの開発がある程度浸透しています。ある程度の規模のプロジェクトでは、Next.jsやNuxt.jsを使うのがデファクトスタンダードになりつつあります。たとえば最近プログラミングスクールを出てエンジニアになった方でもNext.jsやNuxt.jsは使えるという場合が多く、これらのフレームワークがエントリポイントとしてかなり普及していると感じます。
TechFeed Experts Night #4で他のエキスパートの方がご紹介された通り、2022年現在ではフレームワークの選択肢がかなり多くなってきています。開発者がこれまでNext.jsを使って見つけた改善点が形になりつつあり、次の時代への過渡期にあることを示しています。
このようにさまざまな選択肢を踏まえつつ、自身のプロダクトやメディアがどのような特性を備えるべきかということから逆算し、HTML / キャッシュ /JavaScriptそれぞれの要因を整理しながら最適な組み合わせを作っていくのが現代のフロントエンドアーキテクチャ設計のポイントです。
HTML/キャッシュ戦略/JavaScriptの量という3つの要因をそれぞれどう考えるべきかは以前お話したセッション「Webフロントエンドとアーキテクチャ事情の持論を喋る」が参考になります。これらの3要因は、速度とユーザー体験を左右する最も重要なポイントです。
これらの基本的な3要因を決めた上でコードレベルの設計/デザインを考えるときには、ひとつのフレームワークに依存するのか、もしくは疎結合/交換可能性(新しいソリューションが出たときの交換しやすさ)を重視して細かいライブラリを組み合わせて作るかということが次の選択肢です。
さきほどお話したように、現在は次の時代への過渡期であり、さまざまな改善が加えられた新しい選択肢が出てきている段階ですので、良さそうな最先端の尖ったライブラリがたくさんあるものの、それらにすぐ飛びつくのはリスクがあります。長期的にプロダクトをメンテナンスする必要があるのであれば、交換可能性を意識して組み合わせを考えなければなりません。
– HTML/キャッシュ/JavaScriptの基本的な3要因に加えて、現代のフロントエンドアーキテクチャを設計する際には1枚岩のフレームワークを選ぶか、いろいろなライブラリを組み合わせて交換可能にしていくかを検討する必要があるということですね。
そうですね。また、これらのポイントに加えて、フロントエンドの領域が広がりつつあることも現代のフロントエンド設計ではおさえておくべきでしょう。フロントエンドフレームワークを選ぶこととは別の話として、@mizchiさんがCDN Edge Workerのセッションで紹介されたように、エッジコンピューティング(CDNなどのエッジで処理を行う)もフロントエンド設計の一部に含まれつつあります。
– なるほど。ちなみにエッジコンピューティングについては、できること/やりたいことはわかるけれども、使うのはけっこう大変なのではないか、費用対効果を考えるとそこまでがんばってもどれだけ速くなるのか、速くなったとして収益にどのようなインパクトがあるのかという疑問もあり、みなさんが実際にどのくらい使っているのか気になります。
これは私の感覚ですが、CDNで静的に配信するだけで安価に速度を向上できますが、さらにエッジでいろいろなことができるソリューションを使うとなると、コストが大きく変わってきます。コストのことを考えると、ひとつのプロダクトの中でも低コストで単純なCDNと、高コストで高機能なエッジコンピューティングソリューションを組み合わせるような選択もありえると思います。
私が以前エッジコンピューティングソリューションを使ってみたときには、アプリケーションの複雑な処理のごく一部分だけでもエッジに移行するだけで、アプリケーションのコードや考慮ポイントが大幅に減ることはあり得ると感じました。このように、要所要所で節度を保って使うぶんには効果的ですが、最近のエッジコンピューティングソリューションで提供される機能を節度なく片っ端から使った場合に費用対効果が見合うかというと疑問です。
ケース1 - 静的なオウンドメディア
– それでは実例をもとにフロントエンドアーキテクチャをどう設計するか、お話を聞きたいと思います。セッションでもご紹介された「Offers Magazine」のような静的なオウンドメディアの特性を考えると、どのようなアーキテクチャにしていくのが望ましいでしょうか。
Offers Magazineは典型的な例ですが、静的なオウンドメディアであり、リアルタイム性はありません。適宜キャッシュパージさえできればよく、キャッシュのライフサイクルもやや長めに取れます。ユーザーのクリックなどのアクションへのリアクションも、リンク先に遷移するくらいのことしか求められていません。
このような静的なメディアで選択肢にあがるのは次の2つです。
- シンプルなサーバーサイドレンダリング(RemixやNext.js) … とくにRemixはエッジでも実行できるので、HTMLをエッジで生成してそのままキャッシュに食わせるという効率的な構成も狙える
- 静的生成(Jamstackなど)
いずれにせよ、生成したHTMLをCDNのキャッシュに食わせるというキャッシュ戦略が前提です。基本的には静的生成がいいのですが、使い慣れた道具がNext.jsなのであれば、Next.jsをHTMLの生成に専念させるように、サーバサイドレンダリングで使うのもありでしょう。この場合はCDNにキャッシュされていない初回のリクエストではOriginでのHTML生成に時間がかかりますが、生成したHTMLを一度CDNに喰わせてしまえば、以後は静的なファイルと配信するのと大して変わらなくなります。
次にJavaScriptについてです。静的なオウンドメディアであれば、クライアントサイドレンダリングやハイドレーションは明らかに必要ないので、配信されるJavaScriptは少なければ少ないほどよいということになります。極論を言えば、jQueryプラグインをちょっとしたエフェクトをつけるために使う程度に抑えるというのもありです。ただ、現代的な開発体験を維持しつつ、動的な部分や少しだけエフェクトをつけたいところだけ最小限のJavaScriptを配信できるようにするという点で、Island architectureも選択肢としてありかもしれません。
– たくさんの選択肢がありますが、もしahomuさんがいま本気で静的オウンドメディアのフロントエンドアーキテクチャを設計するとしたら、どれを選択しますか。
いま本気でやるとしたら、私の中ではアーキテクチャとしてJamstackがもっとも堅い候補で、フレームワークとしてはAstroを選ぶと思います。
– フレームワークとしてNext.jsは選ばないでしょうか。
Next.jsもStatic Site Generationができるはずなので、それを使えばやれなくはないですが、機能やできることが多すぎて大げさな仕組みなのでNext.jsは選ばず、より軽量なフレームワークを選びます。
– Jamstackで静的にサイトを生成するものの、一部分だけJavaScriptがある場合、今の段階であれば何でやるでしょうか。さすがにjQueryはないですかね。
たしかにjQueryはないと思いますが、Jamstackがサポートしているフレームワーク(GatsbyやAstro)でクライアントサイドスクリプトを配信する何らかの機能が用意されている場合があります。
– なるほど。ちなみに、Offers Magazineについて、今後このようなアーキテクチャにしていきたいというポイントはありますか。
Offers MagazineはCMSとしてWordpressを使用していますが、Wordpressの管理画面や記事の編集画面などだけを使い、Ruby on Railsでデータを抽出してHTMLを生成するという構成にしています(WordpressをHeadless CMSとして使っている)。
Headless CMSとして使う場合も、結局Wordpressをどこかでホスティングしなければならず、この点は改善したいです。その場合の選択肢は次の2つです。
- Headless CMSとして使う前提のWordpressホスティングサービスにデータを移行する
- WordPressからmicroCMSなどの別Headless CMSサービスに移行する
これらのHeadless CMSからコンテンツデータを取得して、静的にHTMLを生成するようなアーキテクチャ(Offers デジタル人材総研と同様のアーキテクチャ)を目指したいですね。
Jamstackで使うフレームワークについては、Astro以外にもqwikなどの他の選択肢もあり得るので、選択するときには他のものも調べてみたいですね。
-- 基本的にはデータをHeadless CMSに移行して、HTMLを生成する処理を置き換えてしまいたいということですね。この置き換えはそこまで大変ではないという予想が立っているのでしょうか。
そうですね。比較のためにご紹介すると、Offersには大きく4つのアプリケーションがあります。
- 一般の候補者様がログインして使うアプリケーション (toCアプリケーション)
- 企業クライアント様がログインして使うアプリケーション (toBアプリケーション)
- Offers Magazine (オウンドメディア)
- Offers Jobs (企業クライアント様が求人を出せるページ)
大きな技術課題は、これらの4アプリケーションがRuby on Railsと密結合していることで、.erbファイルにたまにVue.jsが紛れ込んだりしている状態です。現代的なフロントエンド開発体験や交換可能性を考慮すると、マイクロフロントエンドアーキテクチャを目指すべきだと考えています。
これらの4アプリケーションの中でもっとも簡単なOffers Magazine(オウンドメディア)については、Jamstackでサラッと作っておしまいにしたいですね。
-- インタビューの続きは後編で！
