Representación persistente distribuida (DPR)

Al igual que Jamstack, Netlify está acuñando este término.

Si su reacción es: genial, algo nuevo que necesito saber y aprender , sepa que, si bien el renderizado persistente distribuido (DPR) implica algunas cosas nuevas, en realidad es un impulso hacia la simplificación y aprovecha ideas tan antiguas como la web. al igual que Jamstack.

Probablemente sea útil escucharlo directamente de Matt Biilmann, director ejecutivo de Netlify:

En ese breve video, señala que React comenzó de manera muy simple y resolvió muchos problemas claros con la arquitectura JavaScript y, a medida que pasa el tiempo y trata de resolver más casos de uso, se vuelve mucho más complicado y corre el riesgo de perder. el atractivo que alguna vez tuvo en su simplicidad.

Jamstack también enfrenta este problema. Su simplicidad original era extremadamente atractiva, pero a medida que crece para adaptarse a más casos de uso, las cosas se complican.

Una de esas complicaciones son los sitios con muchos miles de páginas. Sitios como ese pueden tener tiempos de construcción realmente lentos. Es bueno ver que los marcos abordan eso (Google “Compilaciones incrementales {Su marco favorito}”), pero diablos, si cambia un enlace en el pie de página de un sitio, está reconstruyendo todo el sitio en función de ese cambio.

Entonces, en lugar de crear muchos miles de páginas durante una compilación, digamos que simplemente… no lo hizo. Hasta que esa página se solicite una vez, al menos. Eso esRPD.

Aquí está Zach Leatherman haciendo eso. Encuentra un lugar en su sitio que genera unas 400 páginas en cada compilación y le dice a Eleventy que en lugar de compilarlo durante el proceso de compilación normal, lo posponga a la nube (literalmente, se ejecutará una lambda y creará la página cuando sea necesario).

Aplazar esas 400 páginas ahorra siete segundos en la compilación. Digamos que su sitio es más espectacular, como 16.000 páginas. Las matemáticas del bloc de notas dicen que estás ahorrando cuatro minutos allí. Tampoco es sólo el tiempo, aunque eso es algo importante. Pienso en toda la electricidad y el almacenamiento a largo plazo que se ahorra al construir de esta manera.

Aquí está la publicación del blog de Netlify :

Así como acuñar el término “Jamstack” no significó inventar una arquitectura completamente nueva desde cero, nombrar este concepto de “Representación persistente distribuida” no significa que estemos creando una solución completamente nueva.

El término “DPR” es nuevo para nosotros, pero en muchos sentidos nos inspiramos en soluciones que han funcionado en el pasado. Simplemente los estamos reelaborando para que se ajusten a las mejores prácticas modernas de Jamstack.

Me gusta que no sea algo completamente nuevo. Estoy seguro de que la implementación de Netlify no es una broma, pero para nosotros es muy fácil pensar en ello:

• Algunas páginas están prediseñadas como de costumbre.
• Algunas páginas no están construidas (aplazadas)
• Cuando las páginas no creadas se solicitan por primera vez, se crean y se almacenan en caché para que no sea necesario volver a crearlas.

Eso es todo, de verdad.

Me recuerda cómo funcionaban los antiguos complementos de almacenamiento en caché de WordPress. Cuando se solicitaba una página por primera vez, ejecutaba las consultas PHP y MySQL y todo eso, luego guardaba el resultado como un .htmlarchivo en el disco para atender solicitudes posteriores. No es nuevo, pero sigue siendo eficiente.

El truco para una arquitectura DPR en Netlify es usar sus On-Demand Builders (beta), así que aquí está la publicación del blog que explica todo y lo llevará a los documentos y demás.