Empujando los Límites hacia el Edge

Hola a todos. Mi nombre es Facundo, y hoy hablaremos sobre Edge. Primero que nada, quiero presentarme. Como dije, mi nombre es Facundo, Facundo Giuliani. Soy de Argentina. Soy Gerente de Relaciones con Desarrolladores. Soy el gerente del equipo de Relaciones con Desarrolladores en Storyblok. También soy uno de los organizadores de React Buenos Aires. React Buenos Aires es la mayor community de React en Argentina, y organizamos encuentros mensuales, y también soy uno de los organizadores de Dev Summit Argentina, otra community de desarrolladores en el país.

Así que para hoy quería empezar un poco con algo de ambiente de los 90. Quería discutir cómo se creaban los sitios web cuando se veían como este, el sitio web de Space Jam. Si ustedes van a Internet, pueden ver que todavía está en funcionamiento y se ve así. Pero en esa época, en los 90, los sitios web funcionaban y todavía funcionan de esta manera. Tienes un navegador web en tu dispositivo móvil o tu computadora. Envías una solicitud a un servidor web, ese servidor web ejecuta la solicitud, genera el contenido, y luego envía el contenido después de procesar tu solicitud y generar todos los data y el contenido que necesitas para ver la página que estás solicitando. De hecho, este servidor web es una computadora real que vive en algún lugar del mundo. Así que esta es una imagen del pasado, de los años 90, pero solía ser así. Quiero decir, una computadora que si apagas, esa computadora, tu sitio web ya no está en funcionamiento, así que tienes que tener cuidado con los cables y cosas así. Pero, sí, quiero decir, esa es la forma básica de funcionamiento de un servidor web y los sitios web. Esta forma de trabajar tiene un problema, aunque, y el problema es que tenemos nuestro servidor web en una ubicación única donde la gente está enviando su solicitud y esperando que ese servidor web procese su solicitud y envíe los data. Lo que significa es que si tenemos a varias personas, digamos miles de personas solicitando el contenido o enviando al mismo tiempo, podríamos estar sobrecargando este servidor web. Y no solo eso, otra cosa que tenemos que considerar es que estas solicitudes que estamos enviando desde cualquier parte del mundo, tienen que viajar a esta ubicación única donde está ubicado el servidor web. Y entonces todo ese tiempo que tarda en llegar desde tu ubicación hasta el servidor web, afectará el performance y el tiempo de carga de tu página web. Así que esos son algunos problemas que tiene una lógica básica de renderizado en el lado del servidor. Las múltiples personas accediendo al mismo servidor web, y también las diferentes partes del mundo donde esa gente está solicitando la página. Así que para resolver este escenario, o para ver una solución para este caso particular, después de los años se definió un nuevo concepto, el concepto de red de entrega de contenido, este es un grupo de servidores distribuidos geográficamente que te ayuda a acelerar la entrega de contenido web, acercando ese contenido a donde están los usuarios. Básicamente, lo que tenemos con estas CDNs, como se les llama, es que tenemos diferentes servidores, como los servidores web que mencionábamos antes. Tenemos diferentes servidores web en diferentes partes del mundo y estos servidores web están mejorados para entregar contenido estático a los usuarios. Básicamente, lo que tendremos en estos diferentes nodos, como se les llama en esta red, son activos estáticos como imágenes, videos, pero también archivos HTML, archivos CSS y archivos JavaScript. Así que van a ser alojados y almacenados en caché en estos diferentes nodos de nuestra red.

Y cuando un usuario quiere solicitar uno de estos recursos, la solicitud que están enviando viajará al nodo más cercano de la red. Así que digamos que vivo en Argentina y tengo uno de los nodos de esta red en Brasil. En lugar de enviar mi solicitud y tener que ir a un servidor web ubicado en el Reino Unido, digamos, mi solicitud viajará al nodo de Brasil de la red y luego obtendré todos los recursos de ese nodo. Esto ayuda a reducir el consumo de ancho de banda porque no estaremos accediendo a todos los usuarios o a todos los visitantes al mismo servidor web, y tendremos un mejor performance debido a esto y porque la solicitud tiene que viajar menos, digamos, yendo al nodo más cercano de la red. Quiero decir, dependiendo de tu ubicación, dependiendo de dónde la red tenga estos nodos, y habrá más security porque en lugar de acceder al origen de los data o el contenido, tu solicitud viajará a diferentes nodos sin tener que saber cuál es el servidor web real que aloja tu sitio web.

Porque una cosa que mencioné y tienes que considerar es que estas CDNs, trabajan con activos estáticos. Eso significa que si necesitamos generar contenido o activos dinámicos, o necesitamos generar estos activos de forma dinámica, de alguna manera basados en una lógica que depende del usuario, todavía necesitaremos el servidor de origen para hacer eso. Así que como mencioné, estas CDNs trabajan con contenido estático. Por eso se desarrolló un nuevo término con los ERs, la generación de sitios estáticos. Puedes estar familiarizado con frameworks como Gatsby o NGJS donde puedes generar activos estáticos en tiempo de construcción, archivos JavaScript, archivos CSS y archivos HTML. La idea de esto es que puedes crear un sitio web que puede ser alojado en estas CDNs, por lo que no dependes de un servidor de origen. Y teniendo la misma idea en mente, se desarrolló el concepto de la JAMstack, donde la idea era centrar la mayor parte de la lógica de tus sitios web en los activos estáticos y gestionar los datos dinámicos con diferentes enfoques como APIs, funciones serverless, o pequeños fragmentos de código que se ejecutan en el lado del servidor, pero no todo tu sitio web vive en el servidor web o tiene que esperar a que cada solicitud sea procesada para devolver o entregar este contenido. Pero como puedes ver, hay otro problema ahora. Y el problema es que solo podemos gestionar contenido estático con las CDNs. Así que como mencioné antes, si necesitamos algunos datos dinámicos, o necesitamos generar un cierto activo, que no está viviendo o no está en caché en los nodos de la CDN, tendremos que enviar la solicitud al servidor de origen. Y ahí es donde los problemas de performance empiezan a aparecer de nuevo. Estamos perdiendo la security y la performance que tenemos con una CDN. Así que teniendo este problema en mente y otras ideas y enfoques y siempre tratando de mejorar la situación, por supuesto, la industria de TI llegó con un nuevo concepto, el concepto del edge. El edge es básicamente una architecture de red distribuida donde los data del cliente se procesan lo más cerca posible de la fuente de origen. Así que eso significa que si vamos a usar algunos data que vienen de nuestros usuarios o algún contexto de nuestros usuarios, podemos obtener ese contexto lo más cerca posible de ellos la lógica del lado del servidor más cerca de ellos, en lugar de tener que enviar la solicitud y toda esa información a un servidor de origen y esperar el procesamiento. Así que en este caso, lo que tendremos es básicamente usando la misma distribución que teníamos para una CDN, tendremos diferentes servidores de origen en las diferentes ubicaciones. Así que si necesito procesar data que vienen de los usuarios y tengo un usuario de Argentina que quiere solicitar un cierto recurso o enviar una solicitud, esa solicitud será procesada en el nodo más cercano de mi red edge, que en este caso podría ser de nuevo, Brasil, digamos, en lugar de tener que enviar esa solicitud a un único servidor de origen que está viviendo en una ubicación particular del mundo. Así que en este caso, tendremos nuestro servidor de origen replicado en diferentes partes del mundo, procesando todas las solicitudes que vienen de los diferentes usuarios. Una cosa que tienes que tener en cuenta es que cuando hablamos del edge, no es lo mismo el edge que una función serverless, porque aunque que tendremos algunos de los beneficios que tenemos con las funciones serverless, como que no necesitaremos DevOps porque los servidores van a ser gestionados por el proveedor y solo vamos a pagar por lo que usamos. Quiero decir, en lugar de tener que pagar por un servidor web dedicado, tendremos nuestro tiempo de procesamiento definiendo cuánto vamos a pagar por eso. Así que eso significa que no tendremos subutilización de los servidores web porque el único procesamiento que tendremos es cuando las solicitudes están llegando y están siendo procesadas y ejecutadas. Quiero decir, todos estos son aspectos que podemos identificar y considerar en las funciones serverless. La cosa es que el Edge no es solo esto porque una función serverless puede ser desplegada en un servidor web centralizado. Y si ese es el caso, vamos a tener el mismo problema que teníamos antes con el servidor de origen. Quiero decir,

Entonces, como puedes ver con el Edge, tendremos algunos de los beneficios que ya teníamos con las CDNs, que son mejor performance y más security, pero también tendremos información en tiempo real o fácil scalability porque en este caso, no solo tendremos los activos estáticos. También tendremos la posibilidad de ejecutar lógica del lado del servidor y procesar las solicitudes que vienen de los diferentes usuarios. Entonces, te puedes estar preguntando, ¿cuáles son algunos de los casos de uso para los que podemos aplicar el Edge o usar el Edge? Bueno, como puedes ver, podemos usar funciones de Edge, bueno, o eso dependerá del proveedor, pero podemos usar esta lógica de Edge o computación de Edge para personalización, por ejemplo, basada en el diferente usuario o tipo de usuarios que están visitando nuestro sitio web, podemos entregar contenido personalizado para ellos, podemos usar geolocalización para mostrar contenido particular en nuestro sitio web basado en la ubicación del usuario que está visitando este sitio web, también podemos aplicar lógicas para pruebas AV, probar diferentes versiones de nuestro contenido o nuestras páginas basadas en ciertos aspectos de los visitantes, y también podemos implementar lógica de security, podemos verificar que los usuarios que están visitando nuestro sitio web o que están accediendo a un contenido particular que estamos ofreciendo son quienes dicen ser usando authentication o autorización que podemos implementar en esta lógica que va a vivir en la red Edge. Entonces, como esto es una conferencia de React, hablaremos sobre el Edge pero basado en algunos frameworks basados en React. Quiero decir, eres un desarrollador de React, cómo puedes usar o obtener la ventaja del Edge cuando estás creando tus proyectos usando React o un framework basado en React, genial. Entonces, hablando de eso, comenzaremos con Next.js. Next.js ofrece la función Edge functions que son básicamente scripts sin servidor que se están ejecutando o siendo ejecutados, quiero decir, están ejecutando renderizado del lado del servidor y se distribuyen en diferentes regiones. Como mencionamos antes, tenemos esta lógica que es muy similar a las funciones serverless pero distribuidas en diferentes regiones del mundo. Las funciones de Edge que son ofrecidas por Bercel en este caso o NGIS, se ejecutan en la runtime de Edge. Eso significa que tendrás algunas APIs web estándar que puedes usar en el código que estás creando y que se va a ejecutar del lado del servidor, pero no es una runtime completa de Node.js por lo que no tendrás acceso a todas las características y todas las capacidades que tienes en un servidor web Node. Eso es algo que tienes que tener en cuenta. Pero por otro lado, esta runtime de Edge que se construyó sobre el motor V8 fue creada para ser más eficiente cuando se ejecuta en el Edge y esa es la razón por la que estamos usando la runtime de Edge para las funciones de Edge. Un ejemplo de una función de Edge que puedes ver es, por ejemplo, capturar la solicitud que viene de un usuario y basado en qué página nos están visitando podemos devolver un cierto mensaje. Como puedes ver, podemos establecer una runtime particular dependiendo de la configuración que establezcamos o la runtime que seleccionemos. Vercel va a identificar si podemos usar este fragmento de código como una función de Edge o si necesita ser una función serverless que está ubicada en una ubicación particular basada en los diferentes servidores que ofrecen y la infraestructura que Vercel nos ofrece. Otro ejemplo es, por ejemplo, capturar las solicitudes que vienen de los usuarios y basado en el ID de usuario que tiene la persona que está visitando nuestra página web podemos recuperar data relacionada con ese usuario y usar eso para cualquier procesamiento que queramos hacer en nuestro sitio web. Estos son ejemplos de funciones de Edge que puedes crear usando Next.js y Vercel. Vercel y Next.js también ofrecen el middleware que es una capa intermedia que ejecuta lógica personalizada antes de que se procese una solicitud. Entonces, con el middleware puedes definir también una función de Edge que se ejecuta cada vez que llega una solicitud al servidor y antes de que se procese esa solicitud. Entonces, en este caso, este es un ejemplo de una función de autorización, quiero decir que es básicamente verificando que el usuario que está visitando nuestro sitio web o que está llamando a este endpoint tiene la security adecuada para ver el contenido. Básicamente lo que hacemos con el middleware es ejecutar todas las solicitudes que vienen de los diferentes usuarios. Lo mismo aquí, estamos usando un indicador de función para mostrar cierto contenido o un contenido diferente, podemos implementar una campaña de pruebas AV testing con el middleware porque vamos a capturar todas las solicitudes que llegan al servidor web y basado en eso estamos ejecutando la lógica del lado del servidor y enviando el contenido adecuado o las páginas web adecuadas a nuestros visitantes. Otro framework basado en React es Remix. Remix, si estás familiarizado con el framework, puedes crear una función de renderizado principal que, quiero decir, usarías llamado React, básicamente estás creando react components y puedes usar eso para renderizar el contenido de tu página, pero también Remix ofrece la posibilidad de ejecutar lógica del lado del servidor. Como puedes ver en la segunda línea de este ejemplo, estamos obteniendo data de un cargador y este cargador es básicamente una función que se está ejecutando en el lado del servidor para solicitar data de una cierta fuente. Remix ofrece la posibilidad de crear funciones de acción y funciones de cargador que se ejecutan en el lado del servidor, por lo que podemos recuperar data, podemos leer data, crear data ejecutar diferentes tipos de acciones y estas funciones de acción y cargador se van a ejecutar en el edge. Entonces, Remix tiene lo que ellos llaman la próxima generación de edge que es básicamente definiendo diferentes niveles de dinamismo en las diferentes rutas de nuestro sitio web y con una base por ruta quiero decir, puedes decir que una ruta de tu sitio web va a correr en el edge usando el tiempo de ejecución del nodo puedes definir que una ruta diferente va a correr en el tiempo de ejecución del edge o genoma dependiendo de el proveedor que estás usando, en realidad puedes definir esa configuración, quiero decir, puedes ejecutar un código de Remix en los servidores web de Brasil y definiendo el runtime que quieres usar para la lógica del lado del servidor que estás ejecutando, este es un ejemplo de usar Brasil como proveedor con un proyecto de Remix, hay diferentes proveedores que ofrecen la posibilidad de trabajar en el edge, otro proveedor es Netlify, Netlify ofrece la posibilidad de crear y gestionar funciones de Edge, estas funciones de Edge funcionan de manera muy similar a las que ofrece Brasil y Next.js, pero se ejecutan en la runtime de Dino, quiero decir, eso es una runtime de código abierto que ofrece diferentes funcionalidades, otro proveedor es Cloudflare, Cloudflare ofrece los trabajadores que son básicamente lo que Brasil y Netlify usaron como origen o como idea para crear sus propias funciones de Edge, y por otro lado también tenemos Fly.io que es un nuevo proveedor en donde tenemos la posibilidad de ejecutar una aplicación de pila completa en el edge también con las bases de datos entonces, en lugar de entregar o distribuir funciones de Edge o pequeños fragmentos de lógica del lado del servidor podemos desplegar una aplicación de pila completa con su propia base de datos para ejecutar eso en el edge como puedes ver, hay diferencias entre los diferentes proveedores y básicamente eso es lo que va a definir las capacidades para tu sitio web y tu proyecto en qué tipo de código o lógica puedes ejecutar en el lado del servidor porque lo que vas a crear con el código de tu proyecto tendrá que trabajar con las definiciones y capacidades del proveedor que estás usando para tu sitio web, entonces, como puedes ver, el edge está aquí y es el futuro, puedes usar el edge en tu proyecto, puedes definir una lógica que se ejecuta en el edge en tu proyecto, pero también creo que este es el punto de partida para nuevas cosas que se van a desarrollar en el futuro con este mismo enfoque de tener lógica descentralizada del lado del servidor que se ejecuta en diferentes partes del mundo y geográficamente distribuida para ser más eficiente, más eficaz y más segura, entonces te animo a probar las funciones de Edge y diferentes enfoques para usar la red edge y ver qué puedes crear y qué puedes ofrecer a tus visitantes y usuarios Muchas gracias, disfruta de la conferencia y nos vemos pronto