Distributed Persistent Rendering (DPR)

Wie Jamstack prägt Netlify diesen Begriff.

Wenn Ihre Reaktion lautet: großartig, etwas Neues, das ich kennen und lernen muss, dann wissen Sie, dass Distributed Persistent Rendering (DPR) zwar einige neue Dinge mit sich bringt, es sich aber tatsächlich um einen Schritt in Richtung Vereinfachung handelt und Ideen nutzt, die so alt sind wie das Web selbst, genau wie Jamstack.

Es ist wahrscheinlich hilfreich, es direkt von Matt Biilmann, CEO von Netlify, zu hören

In diesem kurzen Video argumentiert er, dass React sehr einfach begann und viele klare Probleme mit der JavaScript-Architektur löste, und dass es im Laufe der Zeit, wenn es versucht, mehr Anwendungsfälle zu lösen, viel komplizierter wird und die Attraktivität verliert, die seine Einfachheit einst hatte.

Auch Jamstack steht vor diesem Problem. Die ursprüngliche Einfachheit war äußerst ansprechend, aber da es wächst, um mehr Anwendungsfälle zu berücksichtigen, werden die Dinge kompliziert.

Eine dieser Komplikationen sind Websites mit vielen Tausenden von Seiten. Solche Websites können sehr lange Build-Zeiten haben. Es ist schön zu sehen, wie Frameworks dem entgegenwirken (Google "Inkrementelle Builds {Ihr bevorzugtes Framework}"), aber verdammt, wenn Sie einen Link in einer Website-Fußzeile ändern, bauen Sie die gesamte Website aufgrund dieser einen Änderung neu auf.

Anstatt also während eines Builds viele Tausende von Seiten zu bauen, sagen wir einfach, Sie hätten es… nicht getan. Zumindest bis diese Seite einmal angefordert wird. Das istDPR.

Hier macht Zach Leatherman das. Er findet eine Stelle auf seiner Website, die bei jedem Build etwa 400 Seiten generiert, und weist Eleventy an, diese Seite während des normalen Build-Prozesses nicht zu erstellen, sondern in die Cloud zu verlagern (buchstäblich wird eine Lambda-Funktion ausgeführt und die Seite bei Bedarf gebaut).

Das Auslagern dieser 400 Seiten spart sieben Sekunden beim Build. Nehmen wir an, Ihre Website ist dramatischer, mit 16.000 Seiten. Eine grobe Schätzung besagt, dass Sie dort vier Minuten sparen. Es geht nicht nur um Zeit, obwohl das ein wichtiger Punkt ist. Ich denke an all die Elektrizität und Langzeitspeicherung, die Sie durch diese Bauweise sparen.

Hier ist der Netlify-Blogbeitrag

So wie die Prägung des Begriffs "Jamstack" nicht bedeutete, eine völlig neue Architektur von Grund auf neu zu erfinden, bedeutet die Benennung dieses Konzepts "Distributed Persistent Rendering" nicht, dass wir eine brandneue Lösung entwickeln.

Der Begriff "DPR" ist für uns neu, aber in vielerlei Hinsicht lassen wir uns von Lösungen inspirieren, die in der Vergangenheit funktioniert haben. Wir überarbeiten sie einfach, um sie an die modernen Jamstack-Best Practices anzupassen.

Ich mag es, dass es nicht etwas völlig Neues ist. Ich bin sicher, Netlfy's Implementierung davon ist kein Witz, aber für uns ist es sehr einfach, darüber nachzudenken

• Einige Seiten werden wie gewohnt vorkompiliert
• Einige Seiten werden nicht kompiliert (verzögert)
• Wenn die nicht kompilierten Seiten zum ersten Mal angefordert werden, werden sie dann kompiliert und zwischengespeichert, sodass sie nicht erneut kompiliert werden müssen.

Das war's im Grunde.

Es erinnert mich daran, wie alte WordPress-Caching-Plugins funktionierten. Wenn eine Seite zum ersten Mal angefordert wurde, wurden die PHP- und MySQL-Abfragen und alles andere ausgeführt, dann wurde das Ergebnis als .html-Datei auf der Festplatte gespeichert, um nachfolgende Anfragen zu bedienen. Nichts Neues, aber immer noch effizient.

Der Trick für eine DPR-Architektur auf Netlify ist die Verwendung ihrer (Beta) On-Demand Builders, also hier ist der Blogbeitrag, der alles erklärt und Sie zu den Dokumenten etc. führt.