Netlify の On-demand Builders と DPR について調べる
aiji42推測で解釈してしまった所も多いので、より詳しい人がいれば訂正いただきたいです！
aiji422021/04/14
Netlify が Jamstack に対して新しいビルド方式 Distributed Persistent Rendering (DPR) を提唱。
aiji42Proposal
Logically, DPR creates the same result as a Jamstack build - it renders assets and populates them into a CDN or hosting infrastructure. Rather than the rendering of every asset taking place at build time, the rendering of some assets can be deferred from build time and instead take place on demand when each is first requested. These assets then join those previously rendered during the build process or by other on demand requests, in the CDN, logically contained within the same atomic deploy.
論理的には、DPRはJamstackビルドと同じ結果を作成します。アセットをレンダリングし、CDNまたはホスティングインフラストラクチャに入力します。すべてのアセットのレンダリングがビルド時に行われるのではなく、一部のアセットのレンダリングはビルド時に延期され、代わりに、それぞれが最初に要求されたときにオンデマンドで行われます。これらのアセットは、ビルドプロセス中に、または他のオンデマンドリクエストによって、CDNで以前にレンダリングされたアセットに結合され、同じアトミックデプロイ内に論理的に含まれます。
「ビルド」をデプロイ時に行われるページと、デプロイ後にバックグラウンドで行われるものとに分かれるということ？つまり、最終的には全ページビルドされるが、デプロイ時にすべてのビルドを待つ必要がないと？
ISRでも、デプロイ時のビルドターゲットは決められるが、fallback と組み合わせたときの ビルドはアクセスが起きたタイミングに行われる。それが、アクセストリガではなくなるので、全ページCDNからのスタティックな配信になるということ？
ISR との違い
Incremental Builds build only certain parts of your site when there are changes. DPR would instead rebuild the whole site, with the exception of the content you want to be rendered on demand.
Incremental static regeneration (which is based on stale while revalidate), similar to DPR, generates only the pages defined, and then renders the new page when a user navigates to that page. That being said, SWR relies on users seeing stale content first. Whether it is a fallback page or a previous version of the page, it is not a consistent experience for each user. The first user to a new page will see stale content, and the second user (and beyond) will see the newest content.
インクリメンタルビルドは、変更があった場合にサイトの特定の部分のみをビルドします。DPRは、オンデマンドでレンダリングするコンテンツを除いて、代わりにサイト全体を再構築します。
DPRと同様に、インクリメンタル静的再生（再検証中の失効に基づく）は、定義されたページのみを生成し、ユーザーがそのページに移動すると新しいページをレンダリングします。そうは言っても、SWRは、ユーザーが最初に古いコンテンツを見ることに依存しています。フォールバックページであろうと以前のバージョンのページであろうと、各ユーザーにとって一貫したエクスペリエンスではありません。新しいページへの最初のユーザーには古いコンテンツが表示され、2番目のユーザー（およびそれ以降）には最新のコンテンツが表示されます。
aiji42確かに、ISRの問題点は(ビルドターゲットを限定しているときに限り)、ターゲットから外れたURLへのアクセスのビルドキャッシュがリセットされてしまうということ。
数万単位のURLを持っているサービスは、全ページのビルドをデプロイ時に行うというのは不可能なので(Vercelだと45分でタイムアウト)、デプロイ後にアクセスが循環するまで一時的にレスポンスが悪くなってしまう。そうなると、なるべくデプロイの回数を減らしてまとめてデプロイしようとなりがちなので、クリーンな体験ではなくなる。
それがなくなるのは結構嬉しい
aiji42Netlify がこの DPR を Jamstack のディスカッションに出しているのは、Netlify 独占のビルド機能にしたいわけではなく、言語・フレームワーク問わず、Jamstack におけるデファクトスタンダードにしたいという思想があるようだ。
ディスカッションが収束し切る前に、Jamstackの用語集に DRP を登録してほしいというリクエストが出ている
aiji42この DPR の具体的な実現例として、On-demand Builders が公開された。(ベータ)
const { builder } = require("@netlify/functions")
この builder でラップされたサーバーファンクションが、先のイメージ画像の DPR function として登録されるっぽい。
aiji42Next.js で On-demand Builders を使用するには、@netlify/plugin-nextjs@experimental-odb をプラグインとして利用するとできるらしい。
今週末にでも試してみたい。