エンジニア座談会Vol.01「開発現場の現在ーフレームワークとホスティングサービスの接近」

はじめに

　本記事はフロントエンドに関わる人々のためのメディア「CodeGrid」（https://www.codegrid.net/）より厳選した記事をお送りします。
　今回は、Jamstackやエッジサーバーレスを活用したWeb開発を得意とする制作会社「ピクセルグリッド」（https://www.pxgrid.com/）のスタッフによる2023年と2024年の業界トレンドやエンジニア個人の実感を中心にした、3回にわたる座談会をお届けします。第1回はJavaScript周辺やホスティングサービスが話題に上がりました。（※本座談会の収録は2023年11月下旬に行いました。そのため、フレームワークのバージョンやサービスの動向は、2023年中のものとなります。また、記事へのリンク先が有料記事の場合もありますので、あらかじめご了承ください）

フレームワークのバージョンアップ

中村：2023年もWeb業界のトレンドはいろいろあったと思いますが、座談会では社内でよく使った技術や、個人として実感した話をしていこうかと思っています。最初はJavaScript界隈やホスティングサービスの話をしていきましょう。まず、主なフレームワークを中心に、2023年にバージョンが上がったものを眺めてみましょうか。

• 2023年1月：Astro 2.0
• 2023年2月：Eleventy v2.0
• 2023年5月：Qwik v1.0
• 2023年6月：Svelte v4
• 2023年8月：Astro 3.0
• 2023年9月：Remix v2
• 2023年10月：Next.js 14
• 2023年11月：Vite 5.0

座談会収録後

• 2023年12月：Astro 4.0
• 2023年12月：SvelteKit 2

AstroとNext.jsの棲み分け

渡辺：Astroはバージョンアップが早い（笑）！ 2023年はバージョンアップは2つありましたね。

収録後、さらにAstro 4.0リリース

渡辺さんは「2023年はバージョンアップは2つありましたね。」と発言していますが、座談会収録後の2023年12月5日に、Astro 4.0がリリースされ、2023年のバージョンアップは3つになりました。

中村：そうですね。個人的にも、2023年はAstroが一つトレンドとしてあったのかなと思います。制作会社でもAstroを採用するというような話がいろいろんなところで上がったのを、なんとなく仕事の中で観測しています。

仕事の中でもそれ以外でも、感触として「これが流行っていそう」とか、ありますかね？

宇野：自分の観測範囲だと、やっぱりNext.jsが多いかなっていう印象はありますね。ただ、確かにAstroの話も耳には挟むようになったかな。2022年に比べると、明らかにAstroについて言及してることが増えたなっていう印象でしたね。

中村：そうですね。僕も2022年は、「なんでもNext.jsでつくっていた」みたいなイメージ。

宇野：たとえばブログみたいなサイトでもNext.jsって感じだったのが、「ブログだったらAstroでいいよね」みたいな風潮になったかな、という気がします。

中村：WebサイトとWebアプリで、ちゃんとそれぞれに向いたフレームワークを使い分けるようになってきたのかなと思いますね。

AstroはWebサイト向き、Next.jsはWebアプリ向き

Astroは「Why Astro?」に、

Astro is the web framework for building content-driven websites like blogs, marketing, and e-commerce.

https://docs.astro.build/en/concepts/why-astro/

とあるように、コンテンツ重視なWebサイト向けのフレームワークです。

それに対して、Next.jsは、公式サイトのトップのコピーに、

Next.js enables you to create full-stack Web applications by extending the latest React features

https://nextjs.org/

とあるように、フルスタックのWebアプリケーションを作るためのツールで、Webサイトに向いているフレームワークとはいえません。

宇野：そうですね。僕がフォローしてる人には、Webアプリ寄りの人たちが多いから、Next.jsが強そうに見えてるのかなっていう感じはしました。

中村：なるほど。僕は、逆にWebサイト寄りの人たちが多いから。Next.jsからAstroに、みたいな印象を受けてるんだと思うんですよ。

ベールの向こうのAstro Studio

中村：そういえば、Astroは2024年に「Astro Studio」というのを出すっていう、アナウンスが出ていましたね。それがなんなのかは何も公表されていない。

矢倉：えっと、「edge data platform」ぐらいしか書いてないです。時期としては、「public launch in early 2024」って書いてありますね。

中村：「ヘッドレスCMSでもないぞ」みたいなことは書いてたと思うんですけど。ホスティングサービスでもないし、みたいな。

矢倉：「hosted database」って書いてあるから……なんですかね？ AIとかそういうのを含めた、という感じなんですかね。なんなんでしょうね。「private beta later this year」書いてあるから、そろそろ？ でも、もう今はlater this yearだけどな（笑）。

later this year

この座談会は2023年11月末に行われていましたが、その後、2024年3月にAstro StudioプラットフォームとしてAstro DBが発表されました。

渡辺：（笑）きっと今、がんばってる。

矢倉：ま、なんかAstro自体もちょっと落ち着いてる感じがするので、今はこっちをがんばっているのかもしれないですね。

Vercelとかそういうのと比べるものとは、ちょっと違いそうな感じはしますけど。でも、フレームワークと結びついた何かサービスを提供するという動きは今年もあったし、さらに強まってきそうだなという感じがしますね。

中村：しますね。うん。

2023年に印象に残ってるものとしては、あとなんだろう。Svelteのv4も出たの2023年でしたね。

矢倉：そうですね、6月でしたかね。多分、もうv5も動いてるんじゃなかったでしたっけ？

中村：うん。2023年内に出るんだろうか。

宇野：年内は出ないんじゃないですかね。スパン考えても半年では。

矢倉：アメリカは、もうほぼ冬休みみたいなもんなんで。

渡辺：向こうはそろそろ、「年内は働かないぞ」っていう時期ですかね（笑）。うん。

AngularがSSRやSSGに注力し始めた

宇野：あと、AngularがようやくSSRとかSSG方面に力を入れていくみたいです。元々Angular UniversalっていうSSRのためのツールあったんですが、Angular CLIのリポジトリに入って、@angular/ssrっていう名前に変わりましたね。世の中の動きに追従する形にはなったのかなという印象は受けました。

中村：Angularは着実にバージョンアップしてるし、安定したフレームワークだなという印象はあります。ただ、Web制作界隈からは、あんまりもう興味が持たれていない感じはしますけどね。

宇野：「Webサイト制作」というところで見ちゃうと、どうしても“too much”なんですよね。

中村：そうですよね。以前、勉強会で出会ってお話した方も、「Angularは長く使うWebアプリで使っても、ちゃんとバージョンアップして結構手厚くサポートされているからいいフレームワークだよね」って言っていました。

宇野：あとは大人数で開発したりとか、オフショア開発とかでも活きると思いますね。Angular wayに乗れば、それなりのコードを書けるためのベースが整ってる。ライブラリとかを組み合わせなくても、とりあえずAngular単体でそれなりのことができちゃうという意味では。

中村：ちゃんと、他のフレームワークのいろんなトレンドを地味に取り込んでいますしね。

宇野：そうですね、Angular Signalsとかもありましたし。

2023年のワードの一つ？ シグナル

矢倉：シグナルか。なんか結構流行っている感じですよね、どのフレームワークも。

中村：SolidJSからですかね？

宇野：シグナルという単語が広まったのはSolidJSからと言えそうですが、SolidJS自体、以前はS.jsというライブラリに依存していたようですね。シグナルのようなリアクティブな仕組みは、KnockoutJSがずいぶん前から提供していたようです。

矢倉：シグナルは流行っていますね。あとは、Preactも、今言っていたAngularもそうだし。

宇野：あとSvelte5のRuneも。

中村：シグナルは、どんな機能と言えばいいかな？

渡辺：ReactのuseStateとかっぽいけど、そこまでレンダリングの度に実行されたりはしないよ、みたいな。

宇野：今、話しているシグナルは「値の更新を購読することができる、状態を扱うためのオブジェクト。インターフェースとしてgetterとsetterをもっていて、内部で値とサブスクリプションを管理している」という共通点を持っていそうです。useStateが値を直接読むのに対して、シグナルの場合はgetterなので、値が読まれたときに追跡することができるっていう利点があります。

渡辺：各フレームワークが「これまでと違うアプローチだよ」という差別化もあって、シグナルっていう名前を持ってきているのかなっていう感じはします。

矢倉：まあでも、いろんなフレームワークに搭載されてきているってことは、useStateとか、そこらへんにみんな課題を感じているのかなという印象を受けますね。

宇野：シグナルも、わりと2023年のワードかなっていう、感じもします。

バージョンアップに伴う苦労

中村：Eleventyもバージョンが上がって、2になりましたよね。

渡辺：改善してるのは、node_modulesが軽くなるということでしょうか。あ、でも、それはバージョン2というよりは、それ以前からかな。Browsersyncを捨てたので、そのへんの影響はあるんですけど。

中村：ピクセルグリッドの場合は、案件でEleventyを使ってる場合もあるのかな。ずどさん（高津戸）、担当している案件ではバージョンを上げたんでしたっけ。

高津戸：あ、上げましたね。でも、別にそんなに特別な機能を使おうみたいな感じでもないので。

中村：単純に速くなったりとかはしました？

高津戸：いや、あんまり感じないですね。内容によるんじゃないですかね。

中村：まあ、そうですよね。

高津戸：使っているサイトの規模がまあまあ大きくて、書き直さないといけないみたいなところがあったんですよね。感じることと言えば、Eleventyみたいなプレーンのやつでも、やっぱりアップデートするときは、コストがある程度必要になるなっていうことですかね。

中村：そうですね。でもEleventyはまだこう、バージョンアップがおとなしいからいいなと思います。Astroみたいに年に数回メジャーバージョンが上がるようなライブラリだとめちゃめちゃコストかかりますよね。

渡辺：私の案件は、メモリを食いすぎてEleventyのバージョンを戻したんです。バージョンを上げると、速いのは速いのと、ビルドの待ち時間は減るんですけど。

高津戸：ああ、あるかも。自分の案件も、一部の人でnpm run devしたらフリーズするみたいのがあったので、もしかしたらちょっとそういうのがあるのかもしれないですね。

渡辺：ビルドするときに、メモリを6GBぐらい割り当てておかないとサイトが作れないみたいな。AmplifyとかNetlifyとかでビルドする時はそのサービスの環境で、メモリの割り当ても少ないので、止まっちゃうんですよね。

別の案件でGatsbyもバージョンを上げたらそうなったんですが、それはMDXとの組み合わせがダメだったみたいです。「そこにあるMDXファイル全部メモリに載せようとしてるんじゃないか」って言ってる人もいました。多分その、速くするのに何かを並列化しようとして、コンテンツが多いとメモリに負担が行くみたいなのがあるんですかね。Eleventyは次のアップデートで改善してたので、Gatsbyも改善するといいんですが。

高津戸：なるほど。

中村：新しいバージョンほど、メモリがいっぱいある環境で速く動かすみたいな傾向があるんですかね。

渡辺：そうですね。ただ、私が案件でやっているのは1,000ページあったりするんですが、多分、開発元はそんなエグザンプルはやってないだろうから（笑）。プラグインが入ってたりするとダメなのかもしれない。

中村：50ページぐらいだったら圧倒的に速いんですけど、みたいな（笑）。

渡辺：そうそう、速い速い。けど、リアルワールドではなかなかそうはいかない。

GatsbyのGitHubリポジトリでも、「コンテンツが1,000ページあるブログなんだけどメモリ不足でビルドできない」みたいな、Issueを上げている人がいて、「あ、一緒！ 一緒!!」みたいな（笑）。

企業サポートとフレームワークの結びつき

矢倉：Gatsbyで言うとNetlifyに買収された後、テック系ではレイオフの嵐だったので、Netlifyでもレイオフがあり、あんまり人がいないみたいですね。そのあとNetlifyも「Gatsbyに投資は続けますよ」っていうアナウンスを出してはいますけど。まあなんかそういう感じを見ると、新機能の追加とか、そういった細かいメモリの問題への抜本的な対処とか、そういうのは結構望めなくなってきてるのかもしれないなという感じはしますね。

あと、Gatsbyって、クラウドを一瞬やってたじゃないですか。NetlifyのCEOが、Gatsby買収時点で、「これはあんまり将来性がない」みたいな、結構厳しめなことを言ってたりとかしていたんで、もしかするとそんなに先を見ていないのかもしれないですね。ちょっと、本意はわかんないですけど。その前後にレイオフがあったんで、さらに事態が変わってるとは思うんですけど。

渡辺：Gatsbyは次のバージョンも出る気配ないですしね。本来、多分2023年中だったと思うんですけど。今までのペースだと。

中村：買収されて勢いがなくなっちゃうというパターンは、結構ありますよね。買収されたらそこからバージョンアップ全部止まって、とか。

矢倉：そうですね。タレントだけ欲しいみたいなのもあるかもしれないですし。特に大きなところが買ってしまった場合、その企業の仕組みの中で回さないといけないみたいなのがあったりすると、むずかしいのかもしれないですね。

RemixはShopifyに買われたし、あとのPreactの人もShopifyに行ったんで、Shopifyで使われるプラットフォームのライブラリやフレームワークになっていきそうですね。Next.jsは、当然、Vercelにべったりというか。フレームワークとしても使えるけれども、やっぱり使うならVercelでやるっていう感じはありますし。最近はReactもMetaのものというよりは、もうVercelのものなんじゃない？ みたいな感じもしますし。

なんだかんだ、企業とフレームワークが結びついている感じがしますね。企業側の都合で、なにか戦略的な位置付けのものがフレームワークにも入ってきている感じがします。

Viteの存在感

渡辺：サイトとして表に出てるもんじゃないかもしれないんですけど、ライブラリを見てると、webpack／Babel系がだいぶいなくなったかな、という印象がありますね。Viteになってきた、みたいなところがあります。

中村：ああ、そうですね。Viteはかなり使われるようになっていますよね。

渡辺：そこに突然webpack勢のライブラリが入ってくると、なんか重いなと余計感じるようになり（笑）。

矢倉：Viteはあれですね、バンドラっていうのも違うけど、「開発サーバー兼バンドラ」みたいなもののデファクトになりつある感じがしますね。

宇野：そうですね。

矢倉：Vite自身もこの間バージョン5になって、開発は順調に進んでいるようですね。あと、Viteがプロダクション用のバンドルでRollupを使ってるんですけど、全体的なパフォーマンスを改善しようとして、RustでRollupのAPIを実装するようですね。

中村：それはビルドが速くなるから良さそうですね。しかもViteで対応してくれると、Viteはいろんなフレームワークの内部のビルドツールで採用されているから、いろんなフレームワークが全部速くなりそうなんですよね。

矢倉：そうですね。Viteで対応する話で言うと「こういう機能を入れたい」みたいな話がAstroのほうで出たときに、「できればそれはViteでやってくれたほうが助かる」みたいな話がディスカッションで出ていたりもしますね。

メタフレームマークと、そのさらに下にあるツール群としてViteは協調で進んでいくのかなっていう気はしますね。今、ReactとNext.js、Vercelが、がっつりっていうか、ほとんど一緒になって進んでるのと、似たような感じで動いてそうな雰囲気はしますね。

ランタイムツールの変化

中村：ランタイムのBunはどうですかね？

宇野：Bunは、ランタイムと、パッケージマネージャーと……。

矢倉：バンドラも入ってますよね。

宇野：devサーバーも入ってるんでしたっけ？

矢倉：うん。

中村：なるほど、じゃあ、いろいろ入っている（笑）。

矢倉：Bunは、そういう新しい世代のランタイムというか。速さをとにかく売りにしていると。

まあ、「本当に速いのか？」みたいな話もありますが。本番のビルド環境に使うかはわからないけど、テストとかのCIとか、一部のところで、使うと速いんじゃないかみたいなことを言っている人がいたりっていう感じですね。

ピクセルグリッドの会社サイトで試そうと思って、今、ちょっとNode.jsからBunへの置き換え作業をしてみているんですが。会社サイトだったら、速さはそんなに影響はないでしょうけど。

中村：どうですか？

矢倉：うーんと、ちょっとエラーが出たりとかして、すんなり置き換えられそうというわけではなかったですね、うちのサイトの場合は。

中村：手元でちょっとBunを試したときには、npmインストールに当たるものは速いなとは思ったんです。なので、CIとかでそれを繰り返すのであれば、まあ、最初からBunで作っておいたら、もしかしたら結構快適な開発環境になるのかな。

矢倉：まあ、npmだけに問題があるっていう場合だったら、pnpmとか、他の選択肢もあるんで、そこはちゃんと、どこがボトルネックなのかを見ないといけないとは思うんですけど。でも、そういうのいちいち考えるの面倒だってなったところに、全部入りで速いって謳ってるBunが出てきたのかもしれませんね。

宇野：あとは、Node.jsのエコシステムがどれくらい使えるか、みたいなところもありますよね。

矢倉：そうですね。一応、drop-in replacement、ただ替えただけで動くみたいなのを考えてるっぽいのですけどね。

宇野：なるほど。

矢倉：気にはなりますよね。Bun自体が、いろいろ中に入れているので。

あと、BunはWeb標準系のAPIでJSランタイムで使えるようなものを実装してるんですよね。なので、Node.jsのほうも影響を受けて、今までちょっと消極的だったWeb標準側のAPIを実装し出してるみたいなのは聞きますね。

宇野：まあ、そこらへんはいい影響というか。うん。

矢倉：Node.jsもかなり、Bunを意識はしているんだろうなという気がします。

中村：Bunが出てきてから、Denoもnpmに対応するみたいな話に変わってたりとかしましたよね。まあでも、なんかやっぱり仕組みが違うからか、DenoがNode.jsの置き換えとして使われてる印象はあんまりないんですけど。

矢倉：最初からDenoで書き始めたプロジェクトを見たりすることはちょっとありますけど、置き換えてまでみたいなのは確かに聞かないですよね。

中村：そうですね。最初からDenoで書くんだったら、いいのかな。

ホスティングサービスの状況

中村：今年もですけど、NetlifyやCloudflare Pages、Vercelなど、いわゆるホスティングサービスにWebサイトを上げることがいろいろと評価されてきていて、社外でも増えてきたかなというふうに思っています。

ずどさんはディレクターとしてお客さんと話す機会も多いと思いますけど、世間的な感触はどうでしょう。

高津戸：そうですね。2023年から新しくやった案件というより、それより前からやってる案件が多いんですが、多分もう、ホスティングサービスを使うのは当たり前になってんじゃないのかなっていう感じはしますね。

新しいプロジェクトが始まる時も、3、4年前だったら、「こういうAmplifyとかVercelとかNetlifyっていうものがありまして……」っていう説明からしてたんですけど、ある程度開発やってる会社だったら、「あー、Vercelすでに使ってます」みたいな話があって、「じゃあそこに追加しますね」とか。AWSを使っているお客さんだったら、「Amplify使いたいんですけどいいですか」って言ったら、その概念もそんなに説明しなくても、「ああ、そういうやつね」っていう認識はすぐに持ってもらえたりするなと感じているので。

ピクセルグリッドだと特にそうだと思いますし、うちと似たような開発会社、Web制作とクロスオーバーしてるようなところも多分そういう感じでやってそうだなあ。たとえば、「Next.jsでやることが多いです」みたいな話を聞いたら、いや、そこでFTPとかしてないだろって想像はできるし。

Web制作といっても広いですけど、特に開発に寄っている制作会社では普通に使われてると感じますね。僕は。

中村：AWSは、なんかこう、大きい会社だとセキュリティ的に全部クラウドサービスは統一しておきたいみたいなのとかもあって、AWSからは出れないんですよねとかあるのかなと思ったりはしますが。だから、AWS Amplifyで済むならAmplifyにしちゃおうみたいなのは、あるのかなと思いますね。

高津戸：ありますね。

中村：僕らがよく使ってるCloudflareとかだと、結構2023年はバージョンアップしたというか、いろんな機能が足されたのかなっていう印象がありますね。

宇野：Cludflare R2 Storageって2022年でしたっけ？

矢倉：去年、GA（一般公開）になったんじゃないかな。

中村：そうだね。あと、Cloudflare D1は2023年9月の発表でベータになって、ちゃんとGAになるぞっていう道筋まで発表されましたよね。そういう感じのものが増えてますよね。

あと、Vercelは、2023年は、いろんなストレージサービスを発表してますよね。僕はVercelも仕事でちょっと使ったりしたんですけど、普通に使いやすいなという印象です。

宇野：Vercelは、今まではNext.js使わないんだったら別にっていう感覚だったんですけど。

中村：Next.jsを使っていないけれどVercelを使った案件もあったんですけど、普通に使いやすいなとは思いましたね。「ちょっと、お値段高くない？」とは思うんですけど。Cloudflareがやってるようないろんな機能、Vercel KVだとか、データベースを使えるぞとか、そういう機能とかも結構充実してて。

なんとなくですけど、各種ホスティングサービスは、そこのエッジの中だけで、全部アプリケーションがつくれるようにってしていってるのかなって、思ってるんですよね。

そんなこともあって、ピクセルグリッドもエッジサーバーレスみたいなところもサポートしていこうかなというかと考えて、2023年に、会社サイトのコピーを変えました。これまでは「Jamstackの会社です」だったんですけど、今は「ピクセルグリッドはJamstackとエッジサーバーレスの会社です」になっていますね。

APIの標準化

宇野：話ちょっとずれますけど、自分は最近は各サービスが提供している公式ライブラリに、あんまり安易に手を出さないみたいな感じにはなりつつあります。たとえば、CodeGridだったらPAY.JPを使ってるので、素直に実装するなら公式が出してるpayjp-nodeとかを使うことになると思います。でも、結局、これってパラメーターをよしなにしてfetchするAPIのラッパーなので、自分で必要な機能だけをfetchで実装して使ってます。こんなふうになんとかNodeのパッケージに頼らないで済むようにしたいと考えることが多かったなって印象です。

中村：それは、ライブラリを使わなくても標準技術でちゃんといろんなものが動くようになってきたということですかね。

渡辺：それもありそうですよね。

中村：node-fetchとかって、昔使えなかったじゃないですか。ローカルで実行するときはfetchで書いてるとできないから、じゃあnode-fetchにするの？ みたいな、そういう感じだったと思うんですけど。

宇野：そっか、そこら辺をCloudflare WorkersのWranglerとかMiniflareとかが、いい感じにしてくれるようになったから、ローカルでも開発しやすくなった部分はあるかもしれない。

中村：標準技術で書くぞみたいなことができてきたのは、いろんなランタイムが出てきたからというか。さっきも、BunやDenoの話が出ましたよね。

宇野：そうですね。

中村：サービスによって、みんなNode.jsで動いてくれるわけじゃないし。それぞれJavaScriptは実行できるんだけど、なんか、ちょっと、すごい方言があるみたいな。なので、JavaScript標準の技術で書くようになってきたっていうのはあるかもしれないですね。

宇野：JavaScriptの意味するところが、なんか幅広くなりましたよね。

そういう意味では、WinterCGって2022年でしたっけ？

渡辺：Cloudflareのブログでは、2022年の5月に設立を発表していますね。

矢倉：WinterCGは、クラウドランタイムで使えるAPIを標準化するところですね。APIによっては、Node.jsでは使えるけど、DenoやBunでは使えないみたいなのがあります。そういうAPIの違いが開発におけるめんどくささに繋がってるので、じゃあ、それを標準化しましょうと。で、標準にするにしても、今は、Webの標準があるものはWebに寄せていこうとか、そう言う方向で進めているみたいですね。

宇野：Nodeではfetchが使えないけど、Cloudflare Workersでは使えるっていうのも、Web標準に準拠してるかどうかの違いですしね。ECMAScriptっていう標準には準拠してるけど、fetchはWeb標準のほうになっちゃう。だからそういうのも含めて標準化していきましょうということに先立って、Nodeにもfetchが実装されたりという流れだと思うんですけど。

中村：標準化されると、各ホスティングサービスの移行、たとえば「VercelからNetlifyに移すぞ」とかそういうホスティングサービスの乗り換えもやりやすくなるはずなので、うまくいくといいなという気はしますね。

高津戸：いい世界だ。

中村：現状は、何かしら書き換えたりとかしないといけない状態ですけど。

宇野：プラットフォーム依存の部分っていうのが、どうしてもネックになりますよね。

中村：うん。ホスティングサービスはまだ、新しいものなので、競争しながら、いろいろみんな機能をつけてってる感じがありますよね。独自性というか。

WinterCGの流れが進むと、いろんなところにデプロイできるぞってなって、開発者はうれしいですよね。

エッジでのファンクション実行の進化

中村：CodeGridの開発ではAstroを使っていますよね。これまで事前に書き出していたHTMLをクライアントで表示していましたけど、2023年のリニューアルでは、URLにアクセスしたときにサーバーサイドでHTMLを構築して返すようにした。つまり、SSGだったものを、SSRを使って出力するように変えたわけですけど、どうですか？ 大変でした？

宇野：あー、そんなに大変じゃなかったですね。実際に書いていたコードは、最終的に何を表示したいのかっていうところだけだったので。それを、「SSGなら事前にHTMLファイルの出力」「SSRならアクセス時にHTML文字列を構築してレスポンス」するっていうのは、全部Astroがやってくれていたことなので。

中村：うんうん。

宇野：まあ、エラーハンドリングの追加くらいですかね。SSGだとエラーはビルド時に落ちるので、別にブラウザでアクセスした時とかは関係ないですね。SSRにするってなると、それがランタイムでブラウザにアクセスした時にエラーが起きるっていう順番に変わるので、そこのエラーハンドリングはちゃんとやらなくちゃね、となったくらいです。

ほかにも細かいところはいろいろありましたけど、それは個別事例かな。

中村：なるほど。そうですね。たとえばWebサイトのページ数が増えすぎちゃってビルドの時間が長くなっちゃったからっていうときに、そのエッジでSSRに変えることによってビルドの時間を短くするとか、そういう手法も取りやすくなるのかなと思ってますね。

宇野：そうですね。

中村：SSRすることによって、速度面はどうですか。CodeGridは遅くはなってはいないですよね。

宇野：あの白い画面のまんま、くるくるしてるっていうのは減ったと思います。

CodeGridは購読者じゃないと記事が読めないから、これまではクライアントからAPI経由で「この人は記事が読める人かどうか」という判断をしていたんですよね。SSRにしたことで、その判断の部分を全部サーバーに寄せることができたので、最初のコンテンツが、ユーザーの目に触れる速度は速くなったと思います。

ただ、そうじゃない部分の、たとえばただユーザーのアイコンを表示したいだけのページとかも全部SSRしないとそれができないようになっちゃったので、こういう部分は、スタティックなHTMLを配信してた時と比べたら、理論的にはおそらく遅くはなってる。目に見えて遅くはなってないですけど。

中村：そうですね。処理が挟まってるから。

Cloudflare Workersは前からだったと思いますが、そのほかにも2023年からCDNのエッジの部分でファンクションを実行できるっていうものが、いろいろ出てきてるなと思っていて。最近だと、AWSもLambda@Edgeありますし、NetlifyもEdge Functionsと、エッジで動くようになってるんですよね。VercelももちろんEdge Functionsがありますし。

エッジで実行できるから、そこの分のロスというか、速度面でもそんなに遅くならずにSSRができるようになってきてるのかなというふうにはちょっと思ってますね。

ただ、そういう「エッジで実行する」ということに取り組んでいるクラウドベンダーと、そうじゃないところとあって。AWSなんかは取り組んでるほうだと思いますけど、GCP（Google Cloud Platform）とかAzure（Microsoft Azure）とかって全然そういう話を見ていないないかな。

渡辺：ないですよね。

宇野：GCPだと、Firebaseがあるからエッジは必要ないということですかね。Firebaseの2つのDBaas（Database as a Service）のうち、Realtime DatabaseはWebSocket経由でアクセスするので、Cloud Functions使わないから、エッジである必要もないのかな？ いや、もうひとつのCloud Firestoreは結局、Cloud Functions経由でアクセスすることになるから、エッジがいらない理由にはならないか……。

中村：そうですね。だからCloud Functions for Firebaseも、確かLambda的な感じだったと思うんですよね。

宇野：そうですね。あれはまだエッジがない。

中村：そうですね。多分リージョン決めてみたいな感じのものになるのかなと認識してるんですけど。

来年2024年のトレンドとしては、そういうCDNで実行する環境がもっと増えていくのかなと僕は予想してるんですけど、どうなんでしょうね。

宇野：うーん、ま、結局データが遠いんですよね。だから、エッジプラットフォーム上にデータを保管できるKVとかD1ですよね。

中村：そうですね。ちょっとまだ弱い気はするけど、まあそういう仕組みがいろいろある感じですよね。

宇野：あと、世界中に配信するならいいですけど、日本国内だけってなると、うーんみたいなところもあります。東京リージョンを使えばいいのでは？ みたいな。

中村：確かにそれはありますね。うん。でもまあ、世界どっからでも速いほうがいいじゃんみたいな。海外に出張するかもしれないし、っていうことです（笑）。

（次回へ続く）