Sitios web estáticos primero con Cloudflare Workers

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.

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

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

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,

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

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,

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

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.