Sitios web estáticos primero con Cloudflare Workers

Rate this content
Bookmark

Los sitios web estáticos te brindan todo tipo de grandes beneficios. No tienes que preocuparte por la seguridad o la escalabilidad. Son simples de almacenar en caché, baratos de alojar y fáciles de mantener. ¡Pero a veces extraño todas las cosas divertidas que puedes hacer con solo un poco de estado! Combinando la plataforma Cloudflare Pages con Durable Objects y la API HTMLRewriter, ¡puedes tener tu pastel y comértelo también! Replicaremos una experiencia completa de WordPress con comentarios, publicaciones principales, botones de 'me gusta' y un contador de páginas. Todo en la plataforma gratuita de alojamiento de sitios estáticos de Cloudflare.


Puedes consultar las diapositivas de la charla de Jonathan aquí.

30 min
17 Feb, 2022

Video Summary and Transcription

La charla abarca el panorama histórico del desarrollo web, el surgimiento de los generadores de sitios estáticos, la revolución sin servidor, la informática en el borde y el uso de los servicios de Cloudflare para mejorar los sitios web estáticos. Explora los desafíos del desarrollo web temprano, el cambio a sitios estáticos y el renderizado del lado del cliente, y las ventajas del renderizado del lado del servidor y del cliente. También se discuten los servicios de Cloudflare como Cloudflare Workers, KV, objetos duraderos y HTML rewriter para construir soluciones de alojamiento rápidas y mínimas. La charla destaca el uso de DurableObjects para análisis e integración, contenido dinámico en sitios estáticos, JAMstack y las ventajas de usar Cloudflare Workers para implementación automática, soporte de múltiples lenguajes y combinación de páginas estáticas con funciones JavaScript. Introduce el concepto de informática en el borde y la diferencia entre Cloudflare Pages y Workers. También se menciona el manejo de errores y el uso de HTML rewriter, Cloudflare KVstore y DurableObjects para administrar el estado y almacenar datos dinámicos.

Available in English

1. Introducción y Temas Cubiertos

Short description:

En esta parte, John Cooperman se presenta como un defensor del desarrollador en Cloudflare y discute los temas que se tratarán en la charla, incluyendo el panorama histórico del desarrollo web, el surgimiento de los generadores de sitios estáticos, la revolución sin servidor, la informática en el borde y el uso de los servicios de Cloudflare para mejorar los sitios web estáticos.

Hola, mi nombre es John Cooperman. Estoy aquí hoy para hablar sobre los sitios web de enfoque estático. Así que primero, un poco sobre mí. Mi nombre es John Cooperman y soy un defensor del desarrollador en Cloudflare. Principalmente trabajo en la organización de tecnologías emergentes. Trabajo en nuestra plataforma sin servidor workers, así como en nuestro almacenamiento, algunos de nuestros estados, nuestra utilidad de línea de comandos, cosas como esas. Y si quieres encontrarme en línea, soy jcoop, J-K-U-P en todas las plataformas sociales como Twitter y GitHub, entre otras. Entonces, lo que vamos a cubrir hoy, comenzando con una mirada histórica a principios de los años 2000 en el desarrollo web, un poco del panorama de cómo eran las cosas en ese entonces. Hablando sobre el surgimiento de los generadores de sitios estáticos, como Jekyll y Gatsby y todas estas excelentes herramientas. Y luego también hablando un poco de la revolución sin servidor. Cuando las plataformas sin servidor comenzaron a aparecer y cómo cambiaron las cosas tanto para las pequeñas como para las grandes empresas. Luego entraremos un poco en qué es la informática en el borde y por qué es tan importante. Y al final, vamos a usar juntos los servicios de Cloudflare para decorar los sitios web estáticos con cualquier contenido dinámico que desees. De ahí el nombre de estos sitios web de enfoque estático que también son un poco dinámicos.

2. Early Days of Web Development

Short description:

En los primeros días del desarrollo web, los desarrolladores tenían que ejecutar sus propios servidores de aplicaciones y administrar sus propios servidores. Esto implicaba elegir hardware, software y dependencias, así como escalar y equilibrar la carga. Si bien los sitios web dinámicos como Rails y WordPress ofrecen mucha funcionalidad, requieren actualizaciones regulares y mantenimiento para mantenerse actualizados.

Así que cuando aprendí por primera vez el desarrollo web, esto era como un paisaje. Había mucho Ruby on Rails, PHP, la gente usando WordPress. Y luego, casi todos ellos también enviaban una copia de jQuery, así como tal vez una biblioteca como Backbone.js para la interactividad. Pero lo más importante es que todos estaban ejecutando sus propios servidores de aplicaciones. No habíamos llegado a ninguna de estas soluciones de alojamiento inteligente. No había nada como AWS. Simplemente elegíamos un lenguaje, elegíamos un marco y lo hacíamos nosotros mismos.

Y una de las cosas que esto significaba era que cuando necesitabas poner en marcha tu propia aplicación, necesitabas obtener tu propio servidor. Ya sea una máquina completa o un VPS, tenías que asignar recursos para que tu aplicación se ejecutara. Así que este era un proceso bastante arcaico en aquel entonces, donde tenías que llamar o contactar a un proveedor de alojamiento web. Tenías que ir con ellos y elegir el hardware, como cuánta memoria necesitas, cuánta CPU quieres tener. Tenías que elegir el software, como qué sistema operativo debería ejecutarse en el servidor, qué versión de ese sistema operativo. Luego tenías que instalar tus dependencias si necesitabas node, PHP o Ruby. Y luego, si era una aplicación popular, significaba que tenías que escalarla tú mismo. Tenías que obtener múltiples servidores. Tenías que encontrar una forma de equilibrar la carga entre ellos. Si tu base de datos estaba sobrecargada, tenías que dividirla en múltiples servidores de base de datos, tenías que averiguar cómo hacer el almacenamiento en caché tú mismo. Básicamente, si tenías una aplicación popular, también tenías que convertirte en una persona de operaciones.

Lo que realmente me gustaba de esta época era que todas estas cosas, estos sitios web dinámicos, ya sea Rails o WordPress, son realmente dinámicos y divertidos. Tienen estos enormes ecosistemas de complementos, todas estas herramientas. Puedes hacer muchas cosas geniales con solo hacer clic en un botón o ejecutar un script de instalación simple. Así que cuando pienso en los sitios de WordPress, pienso en muchas cosas divertidas, como enumerar tus publicaciones más populares. Puedes agregar un formulario de contacto. Puedes agregar un botón de `Me gusta`. Puedes tener comentarios, una buena discusión debajo de tu publicación de blog. Cosas así son muy, muy fáciles con estos sitios dinámicos. Pero también hay una pequeña desventaja, que es que estos sitios dinámicos tienen mucho poder. A menudo interactúan directamente con tu base de datos o acceden al sistema de archivos en tu servidor. Y por lo tanto, actualizar y mantenerse actualizado se vuelve realmente crucial. Ya sea mantenerse actualizado con WordPress o tus temas o complementos de WordPress, o incluso el sistema operativo en tu

3. Challenges of Early Web Development

Short description:

En los primeros días del desarrollo web, hubo desafíos con la seguridad, el rendimiento y la escalabilidad. Los desarrolladores tenían que mantener sus sistemas actualizados para evitar vulnerabilidades y intentos de piratería. Las llamadas directas a la base de datos requerían optimización y almacenamiento en caché para un mejor rendimiento. La escalabilidad era una tarea costosa y compleja, que implicaba equilibrar la carga y administrar las bases de datos.

En el propio servidor, siempre hay mucho trabajo por hacer. Y si te pierdes una actualización, eres muy vulnerable y es muy probable que te pirateen de alguna manera. Así que revisar esta era de aplicaciones web muy dinámicas donde construías todo tú mismo era factible, pero había algunos problemas. Principalmente teníamos un problema de seguridad, mantener las cosas actualizadas o los piratas informáticos intentando acceder a tu sistema de archivos o tu base de datos. El rendimiento era un poco problemático. Sabes, cuando cada usuario hace una llamada a la base de datos directamente, debes asegurarte de que optimizas tus llamadas a la base de datos y que haces un almacenamiento en caché intensivo. La escalabilidad era muy difícil en aquel entonces, donde tenías que ser tu propio tipo de persona para equilibrar la carga, trazar bases de datos y eso rápidamente se volvía muy costoso. Estos son algunos de los problemas que

4. Static Site Generation and Hosting

Short description:

GitHub introdujo Jekyll, un generador de sitios estáticos, y GitHub Pages, una plataforma para alojar sitios estáticos. Los sitios estáticos tienen ventajas como ser gratuitos para alojar, fáciles de almacenar en caché y no requerir actualizaciones. Sin embargo, pueden resultar aburridos en comparación con los sitios dinámicos. Empresas como Disqus y plataformas de redes sociales introdujeron formas de agregar interactividad a los sitios estáticos.

Siempre me enfrentaba cuando estaba construyendo aplicaciones en el pasado. Así que recuerdo claramente que en como en 2009, GitHub lanzó este par de ofertas. Y lo primero que lanzaron fue Jekyll, que es el generador de sitios estáticos. Para aquellos que no están familiarizados con los generadores de sitios estáticos, la idea es que tienes todo este contenido dinámico localmente. Tienes temas y fragmentos, como un encabezado y un pie de página, y todas tus publicaciones de blog o diferentes páginas. Y luego en tu computadora local, ejecutas un comando y eso generará todos los archivos HTML apropiados, solo archivos HTML planos, y eso es todo lo que subes. Entonces no estás subiendo tu base de datos. No estás subiendo ningún lenguaje de programación. Solo estás subiendo HTML plano. Y también lanzaron GitHub Pages, que es una plataforma para alojar estos sitios estáticos. Entonces podías tomar tu blog de WordPress, podías exportar las páginas o las publicaciones, más bien. Y luego podías ponerlas dentro de Jekyll, ejecutar Jekyll generate y luego subirlas a GitHub Pages. Y de repente, en lugar de todo el contenido dinámico, simplemente se estaba aplanando y lo estabas subiendo.

Los sitios estáticos tienen muchas ventajas. Casi siempre son gratuitos para alojar. Esto sigue siendo cierto, ya sea que uses GitHub Pages, Netlify o Cloudflare Pages, es muy fácil encontrar un alojamiento gratuito para sitios estáticos. A menudo, cuando encuentras un alojamiento, ya están automáticamente ubicados en una CDN. Y creo que esto se debe a que son muy fáciles de almacenar en caché. No hay datos dinámicos, no hay decisiones que tomar, simplemente puedes colocar esos archivos HTML en una gran cantidad de servidores. No requieren ninguna actualización. Esto no es completamente cierto, por supuesto. Si estás usando GitHub Pages, GitHub aún tiene que actualizar sus servidores web, pero está abstraído de ti, esa es la parte importante. Nunca tendrás que actualizar ningún software. Son extremadamente rápidos. Los navegadores y los servidores son excelentes para servir HTML, por lo que brindan una experiencia extremadamente rápida. Pero la desventaja es que se volvieron un poco aburridos. Perdimos gran parte de esa dinamicidad divertida que hacía que los sitios fueran realmente interesantes de interactuar. Y así, en esta época, cuando la gente comenzó a pasar a sitios estáticos, las empresas intentaron mejorar la experiencia de los sitios estáticos. Un ejemplo es Disqus, que es un sistema de comentarios donde puedes simplemente incrustar un poco de JavaScript del lado del cliente en tu sitio estático, y se conectará a sus servidores y cargará los comentarios, para que las personas puedan seguir interactuando como solían hacerlo. Otro ejemplo es que las empresas de redes sociales como Twitter y Facebook, crearon tweets que se pueden incrustar. Facebook creó comentarios que puedes

5. Shift to Static Sites and Client-Side Rendering

Short description:

Se crearon botones interactivos, como los botones de 'me gusta'. Varias empresas lanzaron botones de intercambio social geniales. En Google Analytics, podías incrustar, una vez más, un pequeño fragmento de JavaScript en tu sitio estático. Así que el mundo pasó de crear todo por sí mismo a tener un sitio estático muy seguro y rápido, y luego suscribirse o pagar por estos servicios premium, y así en sus servidores alojarían algunos de estos datos más dinámicos. Mientras esto sucede en el espacio del comercio electrónico, los bloggers o los artículos de noticias, una tendencia similar está ocurriendo en el desarrollo de aplicaciones.

reemplazar tu sistema de comentarios en tu sitio estático. Se crearon botones interactivos, como los botones de 'me gusta'. Varias empresas lanzaron botones de intercambio social geniales. En Google Analytics, podías incrustar, una vez más, un pequeño fragmento de JavaScript en tu sitio estático. Así que el mundo pasó de crear todo por sí mismo a tener un sitio estático muy seguro y rápido, y luego suscribirse o pagar por estos servicios premium, y así en sus servidores alojarían algunos de estos datos más dinámicos.

Mientras esto sucede en el espacio del comercio electrónico, los bloggers o los artículos de noticias, una tendencia similar está ocurriendo en el desarrollo de aplicaciones. Y así, nuevamente, el desarrollo de aplicaciones comienza en este lugar donde todo se construye en, ya sabes, PHP o Java o Ruby, y todo se renderiza en el lado del servidor en aquellos días. Aún no teníamos bibliotecas de renderizado en el lado del cliente reales. Entonces, HTML se genera completamente en el lado del servidor, se utiliza alguna biblioteca de plantillas, como tal vez Mustache o algo así. Y nuevamente, al igual que con los sitios estáticos y el comercio electrónico, se envía tal vez un poco de jQuery para poder hacer algo de interactividad después de que se cargue la página.

Y lo que es realmente interesante aquí es que te encuentras con algunas ventajas, pero también con algunas desventajas. Y así, las empresas descubren que es realmente costoso tener una aplicación muy popular donde estás generando todo este HTML por ti mismo. Y así, aparecen las primeras bibliotecas de plantillas en el lado del cliente. Y las empresas intentan mover todo esto. Aquí tienes a Twitter como ejemplo. Trabajé allí en el pasado. Del servidor al cliente. Piensan: 'Oh, esto es genial. Ahorramos mucho dinero. Los clientes pueden manejar el renderizado. Es perfecto'. Lanzan esto y luego descubren que también hay muchas desventajas en el renderizado en el lado del cliente. Especialmente, que es muy difícil para conexiones de red lentas o dispositivos de baja gama poder renderizar el sitio. Así que vuelven a mover todo de vuelta al servidor. Piensan: 'Ok, esto es mucho mejor. Tenemos acceso más cercano a nuestras bases de datos. Podemos manejar las cargas iniciales de las páginas de manera más rápida para dispositivos lentos'. Y luego, aparecen mejores bibliotecas en el lado del cliente como ReactJS. Y así, todos vuelven completamente al cliente nuevamente. Esto lo veo siempre como un péndulo que oscila de un extremo a otro, de un extremo a otro,

6. Server-side vs Client-side Rendering

Short description:

Existen compensaciones entre el renderizado en el lado del servidor y el renderizado en el lado del cliente. El renderizado en el servidor es mejor para SEO y tiene una carga inicial de página más rápida, pero requiere más recursos. El renderizado en el lado del cliente es más económico y tiene cargas de página posteriores más rápidas, pero puede no funcionar bien en redes lentas o dispositivos antiguos. El panorama ha cambiado con el surgimiento de proveedores de nube y la revolución sin servidor, lo que hace que los servicios sean baratos, fáciles de escalar y rápidos. Cloudflare opera en el borde, aprovechando estos cambios.

y de ida y vuelta. Entonces, ¿qué está sucediendo realmente aquí? Parece un poco absurdo, pero realmente no lo es. Así que hay dos cosas que han sucedido a lo largo de los años. En primer lugar, existen compensaciones muy reales entre el renderizado en el lado del servidor y el renderizado en el lado del cliente, y a veces el péndulo se corrige en exceso. Y en segundo lugar, el panorama subyacente realmente ha cambiado a lo largo de los años. El renderizado en el lado del servidor hoy no es lo que era hace 10 años. Entonces, para aquellos que no han leído mucho sobre esto, las ventajas y desventajas básicas entre el renderizado en el servidor y el renderizado en el cliente.

El renderizado en el servidor es mejor para el SEO, porque los robots de los motores de búsqueda pueden rastrear las páginas. No tienen JavaScript, por lo que no pueden usar JavaScript para renderizar contenido. La carga inicial de la página siempre será mucho más rápida, porque ya está lista en el servidor. Entonces, todo lo que tienes que hacer es enviar un poco de HTML. Pero definitivamente estás pagando por muchos servidores, muchas bases de datos, sabes, estás haciendo mucho trabajo en el servidor. El renderizado en el lado del cliente, por otro lado, aunque la carga inicial de la página puede ser más lenta, las cargas de página posteriores son mucho más rápidas. Aquí es donde ves el cambio en el panorama con el inicio de las aplicaciones web progresivas que se vuelven muy populares, donde tal vez está bien si tarda un segundo adicional en cargar la aplicación, porque se supone que pasarás mucho tiempo allí. Entonces, una vez que llegas a twitter.com, todo lo que haces, ya sabes, interactúas, envías mensajes, revisas cosas nuevas, es mucho más rápido, porque no estás haciendo una actualización completa de la página. Es mucho más económico, ahorras mucho dinero, pero nuevamente, la desventaja es que es muy difícil para las personas en redes lentas o dispositivos antiguos poder manejar el renderizado de toda esta aplicación. Por otro lado, aunque las compensaciones son muy reales, el panorama ha cambiado. Y así, en el pasado, encontrar un alojamiento web era casi como una tienda local, podías llamar, encontrar un lugar, tal vez un lugar local, pero en estos días hemos visto el surgimiento de estos grandes proveedores de nube. Entonces, tienes a Google, Amazon, Microsoft, CloudFlare, que ofrecen estos servicios de almacenamiento en la nube con un tiempo de actividad extremadamente alto y precios extremadamente competitivos. Al mismo tiempo, hemos pasado por esta revolución sin servidor. Entonces, antes tenías que saber mucho sobre lo que estabas comprando o alquilando, hoy en día hemos abstraído las decisiones sobre el hardware. No tienes que preocuparte por eso. El sistema operativo, no tienes que preocuparte por eso a menos que sea necesario. La escalabilidad se ha vuelto muy fácil. Solo pagas por la cantidad de solicitudes que utilizas. Entonces, si te vuelves muy popular, solo pagas un poco más. Si tienes un mes lento, solo pagas un poco menos. Y con algunas de estas nuevas soluciones, ni siquiera tienes que preocuparte por la ubicación. Tu código se implementa de inmediato en toda la red de borde. Entonces, a medida que ocurre este ir y venir, los servicios se volvieron muy baratos, muy fáciles de escalar y muy rápidos, lo cual es un gran incentivo y realmente cambia la perspectiva al elegir entre el renderizado en el servidor y en el cliente. Entonces, cuando pensamos en este cambio de panorama en términos de Cloudflare, creo que lo importante es tener en cuenta mientras construimos lo que estamos a punto de construir es que

7. Cloudflare Services and Worker Sites

Short description:

Tu código se implementa en cientos de centros de datos, al igual que tu almacenamiento. Las solicitudes son muy económicas. Cloudflare ofrece Cloudflare Workers, una plataforma sin servidor que se ejecuta en el borde. También ofrecen un almacén de valores clave llamado KV, objetos duraderos para objetos JavaScript persistentes y HTML Rewriter para analizar y realizar cambios dinámicos en HTML. Al construir un blog rápido con características de WordPress, puedes elegir entre una aplicación dinámica completa o un alojamiento de sitio estático con funciones sin servidor. El flujo de trabajo implica utilizar una plantilla de sitio estático, instalar la CLI de Cloudflare, inicializar un proyecto de sitio de trabajador y publicarlo. Los sitios de trabajador toman archivos HTML y los almacenan en Cloudflare KV, generando un trabajador de JavaScript para servir los archivos desde KV. Esto proporciona una solución de alojamiento rápida y mínima.

Todo se realiza en el borde. Entonces, tu código se implementa en cientos de centros de datos, al igual que tu almacenamiento. Las solicitudes son muy económicas. Nuestro plan gratuito te ofrece millones de solicitudes al mes. Admite WebSocket. Por lo tanto, puedes elegir, según la aplicación que estés construyendo, entre una respuesta HTTP y una conexión WebSocket. Podemos realizar renderizado HDL en el borde, pero podemos realizar análisis HDL en el borde, lo cual veremos en nuestro ejemplo, y tenemos dos ofertas distintas para tener algún estado de la aplicación o algún almacenamiento que puede ser muy rápido para ti también. Antes de comenzar a construir, quiero explicar algunos de los términos de servicio de Cloudflare para aquellos que no están familiarizados, porque voy a utilizar sus nombres de productos oficiales a partir de ahora. Cuando me refiero a Cloudflare Workers, me refiero a nuestra plataforma sin servidor, donde implementas tu código, que llamamos un trabajador. Se ejecuta en el borde, lo que significa que se ejecuta en todos nuestros centros de datos, y tiene el formato de recibir una solicitud y devolver una respuesta. Tenemos un producto llamado KV. Ese es nuestro almacén de valores clave que también se ejecuta en el borde. Es muy rápido para leer, ya que tus datos, el valor y la clave, estarán en todos los centros de datos, pero es eventualmente consistente, lo que significa que si lo actualizas, si lo haces correctamente, tardará un poco en propagarse a todos los servidores del borde. También tenemos objetos duraderos, que es otra oferta de almacenamiento. Estos son objetos JavaScript persistentes, por lo que persisten en el disco y son una única instancia, por lo que las lecturas son un poco más lentas, pero abren un abanico de posibilidades para trabajar con muchos datos dinámicos. Y por último, tenemos un producto llamado HTML Rewriter, que es un analizador HTML que se ejecuta en el borde, por lo que no solo puedes renderizar HTML, como convertir Markdown a HTML, que siempre has podido hacer, sino que también puedes analizar el HTML y realizar cambios dinámicos. Cualquier cambio que realizarías con React, como if-else, puedes hacerlo con nuestro HTML Rewriter. Así que algo para reflexionar antes de comenzar. Si te pidieran construir un blog y necesitaras que fuera realmente rápido, con un buen rendimiento, pero también quisieras tener algunas de las características agradables de WordPress, como una sección de publicaciones populares, un contador de Me gusta en cada publicación o la capacidad de agregar comentarios, ¿qué conjunto de herramientas elegirías? ¿Optarías instantáneamente por una aplicación dinámica completa, como una instancia de WordPress o algún tipo de CMS? ¿O intentarías armar algo, tal vez con un alojamiento de sitio estático, más algunas funciones sin servidor y tratar de unirlo todo? Nuestro flujo de trabajo que vamos a utilizar hoy es tomar cualquier plantilla de sitio estático, como Jekyll, Hugo, Eleventy, Gatsby, cualquier cosa que produzca un montón de archivos HTML. Incluso puedes escribir los archivos HTML tú mismo, realmente no importa. Instala la CLI de Cloudflare, que se llama Wrangler, y luego vamos a inicializar un proyecto de sitio de trabajador y publicarlo. Entonces, ¿qué es un sitio de trabajador? Cuando piensas en alojar estos sitios estáticos, como GitHub Pages, Netlify, Cloudflare Pages, la idea básica es que tomas tu proyecto de GitHub o tu proyecto de Bitbucket y lo apuntas a uno de estos servicios, y de alguna manera, detrás de escena, el servicio ejecuta una compilación, recopila todos tus sitios estáticos y comienza un servidor web, y ahora cuando vas a esa URL, te dirige. Sabes, solo detrás de escena, está haciendo todo lo que esperarías, ¿verdad? Y así, hay muchas formas de lograr esto, pero una forma de hacerlo, si quisieras construir tu propia experiencia, sería utilizando sitios de trabajador. Y lo que hará es tomar esa carpeta llena de archivos HTML y colocar cada archivo HTML en Cloudflare KV, nuestro almacén de valores clave. Entonces, si tienes un about.html, creará una nueva entrada en KV, el título será about.html y el valor será el HTML real dentro de ese archivo. Y hará eso para todos tus archivos, por lo que terminarás con un montón de almacenes KV. El nombre de cada uno es el nombre del archivo y el valor es el propio HTML, y luego también generará un trabajador de JavaScript simple, que simplemente escuchará todo el tráfico entrante, extraerá esa ruta, ese nombre de archivo y lo buscará en KV y lo servirá. Entonces, puedes ver que después de que tomé ese proyecto base de 11T, ejecuté sitios de trabajador y luego lo implementé, y puedes ver que tengo, este es mi panel de control de KV. Y en mi panel de control de KV, puedo ver todos los nombres de mis archivos como las claves, y los valores son el HTML real o CSS.

8. Using DurableObjects for Analytics and Integration

Short description:

Esta sección trata sobre cómo usar JavaScript para recuperar activos del almacenamiento KV y devolverlos como respuesta. Introduce el almacenamiento de DurableObject, que permite la creación de objetos JavaScript persistentes. El texto explica cómo usar DurableObjects para realizar un seguimiento de las analíticas, como el número de veces que se ha accedido a una ruta. También menciona la clasificación de las analíticas y el uso de DurableObjects para los likes. La sección concluye discutiendo dos opciones para integrarlo todo: agregar una etiqueta de script del lado del cliente al sitio estático o realizar todas las operaciones dentro del archivo worker.js.

HTML o XML. Y luego, acompañando eso, obtengo este trabajador muy mínimo. Entonces, esto es solo un poco de JavaScript. Toma la solicitud del evento y obtiene el activo del almacenamiento KV, agrega algunos encabezados y luego lo devuelve como respuesta. Básicamente, si tomas tu sitio de Hugo, tu sitio de Jekyll, tu sitio de 11T, ejecutas el comando wrangler en él y haces clic en publicar, obtienes exactamente lo que esperarías, el despliegue a un enlace de Cloudflare, pero detrás de escena, es importante saber que funciona entre este almacenamiento KV y este trabajador. Bien. Ahora podemos empezar a divertirnos aquí. Vamos a usar el almacenamiento de DurableObject. Estos son objetos JavaScript persistentes y vamos a empezar a crear algunas cosas propias como una publicación destacada, un contador de likes o algo así. En cuanto a la sintaxis, son una clase JavaScript, son un constructor. Puedes ver en el constructor que básicamente decimos que este almacenamiento de estado, esto es una API de DurableObject, obtén el almacenamiento de analíticas y mantenlo en memoria. Y si no hay almacenamiento de analíticas, inicialízalo como un objeto vacío. Y luego, lo que vamos a hacer en segundo plano, lo vamos a hacer en cada solicitud y vamos a decir, ok, obtén la ruta que el usuario está intentando acceder. Y si esa ruta ya ha sido accedida antes, incrementa el número de veces que se ha accedido en uno, de lo contrario, crea una nueva entrada con esa ruta y establece el valor en uno. Y así, lo que obtendremos aquí es simplemente un gran objeto analítico sobre cada una de nuestras rutas y cuántas veces se han accedido. Entonces, en la siguiente diapositiva, podemos ver en los comentarios cómo se verá básicamente. Solo se verá como este gran objeto donde tiene mi primera publicación se accedió 33 veces, mi segunda publicación se accedió 200 veces, etc. Y luego, podemos hacer una simple clasificación. Entonces, lo ordenamos por valor y si queremos, podemos cortar los primeros cinco y boom, tenemos este objeto duradero que básicamente muestra tus cinco publicaciones principales. Podemos hacer algo muy similar con los likes. Son mucho más simples. Puedes tener un solo objeto duradero para cada ruta, para cada página que tengas, y luego los likes simplemente se instanciarían como un número simple. Entonces, podrías decir que esto no tiene likes. Cuando las personas hacen clic en él, simplemente incrementas el número. Así que tenemos este trabajador que sirve nuestras solicitudes. Tenemos todas las páginas mismas viviendo en KV. ¿Cómo lo juntamos todo? Entonces, la opción uno es que podríamos hacerlo de manera muy normal. Podríamos agregar una simple etiqueta de script del lado del cliente a nuestro sitio estático. Entonces, el sitio estático se cargaría y luego el script se ejecutaría y ese script podría obtener elementos del DOM, acceder al objeto duradero para obtener el número de likes o las cinco publicaciones principales y luego usar cualquier lenguaje de plantillas del lado del cliente para reemplazar ese contenido. Entonces, verías que el sitio se carga muy rápidamente con algunos spinners y estas solicitudes asíncronas se inician y eventualmente llenan el sitio. Pero lo genial de hacer todo en el borde es que realmente puedes hacer cosas dinámicas en el mismo tiempo que solía llevar e incluso sigue llevando hacer cosas estáticas. Y así, una cosa que podríamos hacer es en este pequeño worker.js que se genera, podríamos

9. Dynamic Content and Static Sites

Short description:

Podemos obtener el archivo HTML del almacenamiento KB, interactuar con objetos duraderos, obtener la publicación principal y los likes, y usar el analizador HTML en el servidor para llenar ciertos divs con datos. El worker obtiene la publicación del blog, los objetos duraderos y reescribe el HTML por solicitud. A pesar del contenido dinámico, los tiempos de respuesta siguen siendo rápidos. La conclusión es que los sitios estáticos se han vuelto más capaces, más fáciles de construir y la informática en el borde permite contenido dinámico a la misma velocidad que el contenido estático. Adoptar un enfoque primero estático proporciona resistencia y asequibilidad sin sacrificar funcionalidad.

En realidad, podemos hacer todo eso mismo allí. Entonces, podríamos obtener el archivo HTML del almacenamiento KB, también podríamos interactuar con nuestros objetos duraderos, podríamos obtener la publicación principal, podríamos obtener los likes, y luego podemos usar el analizador HTML aún en el servidor en esta solicitud para analizar ciertos divs como las publicaciones principales y llenarlos con esos datos de la publicación principal. Entonces, podemos hacer todo eso mientras la solicitud está esperando para procesarse y aún hacerlo muy rápidamente. Aquí hay un pequeño diagrama arquitectónico. Tenemos a todos nuestros usuarios. Ellos llegan a la nube. El worker obtiene la publicación del blog de KB, obtiene los objetos duraderos de los likes y las analíticas, y luego reescribe el HTML sobre la marcha por solicitud antes de enviarlo. Realmente me gusta este tweet de uno de los fundadores de la aplicación Remix, diciendo que sé que suena tonto, pero estoy obteniendo un tiempo de respuesta de 130 milisegundos incluso haciendo todas estas mutaciones en el servidor. Entonces, el servidor está haciendo fetches, mutaciones, y todo eso. Aún así, 130 milisegundos. Aquí vamos. Hicimos nuestro sitio con publicaciones populares. También tiene likes. También tiene comentarios. Todo eso contenido dinámico. Y puedes ver aquí desde mis Chrome DevTools que seguimos obteniendo respuestas de 50 a 80 milisegundos a pesar de todo este contenido dinámico. Las conclusiones aquí son que los sitios estáticos tienen capacidades que las aplicaciones web nunca han sido más posibles. Nunca ha sido más fácil de hacer. La informática en el borde significa que puedes hacer contenido dinámico casi tan rápido como hacías contenido estático. Y al adoptar un enfoque primero estático, tu sitio será resistente y económico, pero no tendrás que sacrificar funcionalidad. Muchas gracias. Hola, John. Bienvenido. Muchas gracias por esta excelente charla. Sí, gracias por tenerme. Sí. Los resultados están aquí. Y el 68% dice API. Pero...

10. JAMstack y Cloudflare Workers

Short description:

Sí, esa es la respuesta correcta. Es un poco gracioso. Estaba hablando con mis compañeros de trabajo. Todos estos años trabajando en ello, no sabía que JAM era un acrónimo. Pero sí, estamos contentos. El 68%, el 69% de las personas conocen la respuesta correcta. Sí. API. Fue muy agradable ver esta visión general de nuestra evolución web desde los años 2000 hasta 2022. Así que sí, es genial ver toda la transición entre CSR estático, SSR y el cambio entre ellos. Entonces, bueno, tengo algunas preguntas para ti. Entonces, bueno, una pregunta que veo es, ¿por qué deberíamos usar Cloudflare Workers? Sí, creo que si estás buscando una oferta sin servidor, todas son geniales, también me gustan todos los competidores.

Sí, esa es la respuesta correcta. Es un poco gracioso. Estaba hablando con mis compañeros de trabajo. Todos estos años trabajando en ello, no sabía que JAM era un acrónimo. Y entonces, uno de mis compañeros de trabajo me dijo que debería preguntar qué significa la A. Y yo estaba como, no sabía que ninguno de ellos significaba algo. Pero parece que el 68% de las personas saben mucho mejor que yo. Pero sí, es JavaScript, APIs y Markdown, Jam, Jamstack. En realidad es muy fácil confundir entre API y aplicación. Sí. Cuando dices Jamstack. Supuse que eso era un poco... Esa era mi respuesta engañosa. Mi respuesta trampa era aplicación. Vale. Pero algunas personas también mencionaron Architect y Apache. Así que sí, me pregunto. Sí. Quiero decir, podría ver que cualquiera de ellos funcionara. Pero sí, fue interesante para mí. Es interesante. Pero sí, estamos contentos. El 68%, el 69% de las personas conocen la respuesta correcta. Sí. API.

Entonces, fue muy agradable ver esta visión general de nuestra evolución web, yo diría, desde cómo era en los años 2000 hasta donde estamos en 2022 ahora. Así que sí, es genial ver toda la transición entre CSR estático, SSR y el cambio entre ellos. Entonces, bueno, tengo algunas preguntas para ti, seguro. Entonces, bueno, una pregunta que veo es, ¿por qué deberíamos usar Cloudflare Workers? Sí, creo que si estás buscando una oferta sin servidor,

QnA

Ventajas de Cloudflare Workers

Short description:

Los workers de Cloudflare ofrecen la ventaja de implementación automática en múltiples ubicaciones, garantizando resultados rápidos y eliminando los arranques en frío. Admiten varios lenguajes y ofrecen funciones como detección de bots, prevención de DDoS y optimización de imágenes. Cloudflare también permite combinar páginas estáticas con funciones de JavaScript, lo que permite funcionalidad dinámica en sitios estáticos.

todos son geniales, también me gustan todos los competidores. Pero creo que al estar en el borde de forma predeterminada, no tienes que preocuparte por la ubicación y no tienes que pagar extra por múltiples ubicaciones. Cuando usas los workers de Cloudflare, se implementan automáticamente en todas nuestras ubicaciones, por lo que tus usuarios siempre obtienen resultados muy rápidos. Y con eso viene una velocidad increíble, no tenemos arranques en frío, como muchos de los VM, tu código siempre se ejecuta en v8. Y luego tenemos soporte completo para Rust, TypeScript, JavaScript, así que sí, diría que son realmente rápidos, se ejecutan en todas partes, son realmente económicos y admiten muchos lenguajes.

Genial, sí. Creo que ya mencionaste muchos beneficios de usar los workers de Cloudflare. Entonces, Tushina tenía una pregunta, como, ¿cuál es la ventaja de los workers de Cloudflare sobre las páginas de GitHub? Oh, sí. Entonces, tenemos como Cloudflare pages como nuestra oferta de sitios estáticos o el uso de workers con sitios de workers. No quiero entrar en detalles, porque me encantan las páginas de GitHub, creo que son todas excelentes opciones para alojar tu sitio estático. Lo que veo como la gran ventaja, supongo que hay dos, dos aspectos que veo al usar nuestra solución. Uno es que una vez que estás en nuestra esfera, puedes habilitar rápidamente nuestros otros productos. Puedes agregar rápidamente nuestro detector de bots, prevención de DDoS, ya estás en nuestra CDN, optimización de imágenes JavaScript, como tenemos más de 50 productos. Entonces, una vez que estás en nuestro sitio, es muy fácil activar o desactivar esos productos. Y lo otro es que estamos agregando soporte para combinar, sabes, con las páginas de GitHub, solo tienes tus páginas estáticas, tu HTML, tu JavaScript, tu CSS. Con Cloudflare, también puedes cargar funciones de JavaScript. Por lo que podrías agregar fácilmente un encabezado global o comunicarte con una base de datos antes de devolver, ya sabes, tan pronto como quieras hacer algo dinámico en tu sitio estático, ahí es donde realmente destacamos. De acuerdo, sí. Quiero decir, así que espero que, sí, Krishna, hayas obtenido tu respuesta. Y tal vez te gustaría probar

Introducción a la Computación en el Borde

Short description:

La computación en el borde es un concepto donde los centros de datos están distribuidos por todo el mundo, lo que permite tiempos de respuesta más rápidos. En lugar de que los visitantes accedan a los datos desde una ubicación única, la computación en el borde garantiza que el código se ejecute en el centro de datos más cercano al usuario. Esto resulta en tiempos de respuesta rápidos, independientemente de la ubicación del usuario.

Páginas y workers de Cloudflare para ver cómo funciona para ti. Por favor, avísame si te encuentras con algo. Sí. Entonces, quería preguntar, ¿podrías explicar, tal vez desde una perspectiva de principiante, qué es la computación en el borde? Sí, me hacen esta pregunta con frecuencia. Básicamente, si piensas en el estilo antiguo de alojar tu aplicación, siempre tenías que elegir una ubicación, ¿verdad? Así que comprarías o alquilarías un servidor y elegirías de un menú desplegable, Nueva York o Los Ángeles o cualquier otra ubicación, lo que significa que, digamos que eliges Nueva York, entonces si tienes visitantes en Japón, todos ellos tendrían que venir desde Japón hasta Nueva York para obtener tus data. Y así, la idea de la computación en el borde es que tenemos muchos y muchos centros de datos, cientos de ellos en todo el mundo. Cada vez que creas un nuevo worker, cualquier función que crees se carga en todos ellos. Y luego, cuando un usuario visita tu sitio web, se ejecutará el código que esté más cerca de ellos. Y eso es lo que nos da estos tiempos de respuesta realmente, realmente rápidos, incluso si se trata de data dinámicos, es muy probable que estés accediendo a un centro de datos en tu región, casi siempre, no importa de dónde seas. Sí, es un poco confuso, porque es como si dos computadoras fueran el borde, tres bordes, cinco bordes, y eso es muy ambiguo. Pero en nuestro caso,

Diferencia entre Cloudflare pages y workers

Short description:

Cloudflare workers es una plataforma sin servidor donde puedes escribir funciones para manejar solicitudes y realizar diversas tareas. Por otro lado, Cloudflare pages es una plataforma de alojamiento de sitios estáticos que te permite alojar sitios estáticos e incluye un directorio de funciones para elementos dinámicos. Los workers son las funciones y se pueden utilizar en conjunto con las páginas si es necesario.

estamos hablando de cientos de centros de datos. Entonces, bueno, tenemos otra pregunta. Y quieren saber cuál es la diferencia entre las páginas de Cloudflare y los workers de Cloudflare? Sí. Entonces, workers es nuestra plataforma serverless. Escribes funciones que reciben una solicitud y devuelven una respuesta. Pueden hacer cualquier cosa, pueden comunicarse con bases de datos, pueden generar HTML, lo que sea que deseen. Las páginas de Cloudflare se construyen sobre eso y es nuestra plataforma de alojamiento de sitios estáticos. Similar a Netlify o GitHub Pages. Y luego, con las páginas de Cloudflare, puedes tener un directorio de funciones donde colocas cualquier cosa dinámica que desees. Entonces, las páginas son el alojamiento de sitios estáticos, los workers son las funciones reales y luego puedes tener workers con tu proyecto de páginas.

Error Handling and HTML Rewriter

Short description:

¿Es posible mantener otras declaraciones entre bloques try, catch y finally? Permíteme tomar esa pregunta en privado. John explica HTML rewriter, una API que puede analizar HTML y proporcionar selectores. Se ejecuta en todos los centros de datos, lo que permite analizar y actualizar HTML en el borde. Cloudflare KVstore y DurableObjects se utilizan para gestionar el estado, siendo KV rápido para lecturas y eventualmente coherente para escrituras, mientras que Durable Objects ofrece escrituras instantáneas pero lecturas más lentas. KV es adecuado para almacenar datos dinámicos como publicaciones de blog, mientras que Durable Objects son ideales para aplicaciones que requieren escrituras rápidas, como videojuegos o salas de chat.

si los necesitas. De acuerdo. Veo otra pregunta que es como, ¿es posible mantener otras declaraciones entre bloques try, catch y finally, creo que se refiere a algún código? No estoy seguro de eso. Permíteme tomar esa pregunta en privado, no entiendo exactamente cuál es la pregunta. Sí. Creo que está relacionado con algún manejo de errores. Entonces, bueno, John, hablaste sobre el HTML rewriter, en realidad, estaba muy interesado en eso específicamente, ¿podrías expandir un poco sobre eso? Sí, es una de mis cosas favoritas que tenemos. En esencia, es solo una API que puede analizar HTML y darte selectores como estás acostumbrado. Puedes seleccionar una clase, un ID o una etiqueta, y luego puedes tener escuchadores de eventos cada vez que encuentres un div, llamar a esta función básicamente es lo que hace. Y luego, en esa función, puedes reemplazar el div con un span o algo así, o reemplazar el contenido. Pero lo interesante es que se ejecuta en todos nuestros centros dedata , por lo que puedes hacerlo en el borde. Entonces, si estoy en Florida, golpearé un centro dedata en Florida, ese centro dedata es capaz de analizar y actualizar el HTML. Entonces sí, es como un analizador de HTML completamente compatible que se ejecuta en el borde. Eso es bastante interesante en realidad. Me gusta mucho.

De acuerdo. Así que rápidamente, otra pregunta, ¿cuál es la diferencia entre Cloudflare, KVstore y DurableObjects, y cuándo deberíamos usar cada uno? Sí, eso es genial. Son muy similares. Ambos se utilizan para gestionar el estado. KV está en el borde, por lo que está en muchos de nuestros centros dedata, lo que significa que las lecturas son muy rápidas porque está justo ahí en tu centro dedata. Pero cuando escribes en él, es eventualmente coherente, lo que significa que si pongo algo ahí y digo, Hola mundo, y luego lo cambio a decir, Adiós mundo, llevará un tiempo actualizar los 300 centros dedata con el nuevo mensaje. Así que lectura muy rápida, más lenta para actualizar después de escribir. Durable Objects no está en el borde. Es solo una instancia única. Por lo tanto, las lecturas son un poco más lentas, pero las escrituras son instantáneas. Entonces, si quisieras construir un video juego, Google Docs, sala de chat, cualquier cosa que requiera escrituras muy, muy rápidas, usarías Durable Objects. Si quisieras almacenar algún data como publicaciones de blog o algo así, KV es una forma mucho mejor de hacerlo. Entonces, KV, si puedes, si necesitas algo realmente dinámico, Durable Objects es perfecto para eso.

Gracias. Sí. Ahora está mucho más claro para mí. Gracias una vez más, John, por estar con nosotros hoy y compartir todo tu conocimiento con nosotros. Así que para la audiencia, ahora pueden continuar a la charla especial y unirse a John en la sala de discusión, salas de discusión de Cloudflare workers, y encontrarse allí y hacer preguntas. Si tienen alguna allí y muchas gracias, John, una vez más. Gracias. Gracias por tenerme. Adiós.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
React Advanced Conference 2021React Advanced Conference 2021
36 min
Living on the Edge
React 18 introduces new APIs for rendering applications asynchronously on the server, enabling a simpler model for architecting and shipping user interfaces. When deployed on edge networking platforms like Cloudflare Workers, we can get dramatic performance and user experience improvements in our applications. In this talk, Sunil will demo and walk through this new model of writing React applications, with some insight into the implications for data fetching, styling, and overall direction of the React ecosystem.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.