Empujando los Límites Hasta el Edge

Hola a todos. Mi nombre es Facundo y hoy hablaremos sobre el Edge. En primer lugar, quiero hacer una breve introducción. Mi nombre es Facundo Giuliani. Soy de Buenos Aires, Argentina. Soy ingeniero de relaciones con desarrolladores en Storyblock. También soy uno de los organizadores de React Buenos Aires, que es la comunidad de React más grande de Argentina, y también organicé NodeConf Argentina, una gran conferencia que esperamos realizar este año. Así que antes de comenzar o antes de entrar en el concepto real de Edge, quería hacer un resumen de cómo navegamos por la web. Entonces, cuando tenemos un dispositivo, digamos un teléfono móvil o una computadora, solicitamos una página web a un servidor web y el servidor web devuelve el contenido que estamos solicitando. Este contenido puede generarse de diferentes formas según el método de renderizado que estemos utilizando, pero básicamente el servidor web generará esta página HTML y nos la entregará. Ese sería el enfoque original de la web para distribuir el contenido.

Pero este enfoque tiene un problema. El problema es que si estamos utilizando un solo servidor web, ese servidor web está ubicado en una ubicación particular en el mundo, y tenemos a todos los usuarios y visitantes enviando la solicitud a ese mismo servidor web al mismo tiempo en esa ubicación particular, lo que trae ciertos problemas. Un problema es que si estamos lejos de ese servidor web, esa solicitud llevará más tiempo en llegar al servidor y luego regresar con la página HTML o el contenido, y no solo eso, podemos sobrecargar ese servidor web si tenemos muchas personas visitando el sitio web al mismo tiempo. Entonces, para superar ese problema, apareció un nuevo concepto o una nueva idea con los años, que es la red de distribución de contenido. Una red de distribución de contenido es un grupo de servidores distribuidos geográficamente. La idea de este grupo es acelerar la entrega de contenido web acercando ese contenido a los usuarios. Entonces, básicamente, lo que tenemos en este caso es este servidor web central que mencionamos antes, pero tenemos el contenido replicado en diferentes nodos, como se llaman, que son servidores en diferentes ubicaciones en el mundo. Y luego esta red, los usuarios pueden acceder al contenido a través del edge que está más cerca de ellos. Entonces tendremos personas de diferentes países visitando el nodo más cercano de la red. Así recibirán el contenido de esos nodos en lugar de tener que enviar su solicitud al servidor único. Hay un servidor de origen que se llama en esta CDN, que es el servidor que va a generar realmente el contenido de forma dinámica, pero ese es el servidor fuente, y luego tenemos los nodos replicados dentro de la CDN. Genial. Eso es bueno. Ese enfoque se utilizaba para la generación de sitios estáticos, que es un método donde generamos contenido en tiempo de compilación y lo tenemos disponible como páginas estáticas para los usuarios que visitan nuestro sitio web. ¿Por qué? Porque las CDNs están diseñadas para entregar contenido estático. Entonces aquí podemos ver el problema. ¿Cuál es el problema? El problema es que el contenido que las CDNs pueden entregar es estático. Entonces, si queremos generar contenido sobre la marcha por el servidor, no podemos usar una CDN, porque solo podemos distribuir páginas HTML, imágenes, videos, todo tipo de activos estáticos o contenido estático. Podemos usar el renderizado del lado del cliente con React, por ejemplo, pero estaríamos generando el contenido en el

del lado del cliente. Y eso es algo que si queremos que el servidor genere ese contenido para tener un mejor rendimiento, no podemos hacerlo. Entonces, para superar esos dos escenarios o hacer una mezcla de esos dos escenarios, tenemos el edge, que es un nuevo concepto y la idea del edge es tener una arquitectura de red distribuida que procesa los datos lo más cerca posible de la fuente o los usuarios para minimizar el ancho de banda que mencionamos antes. Entonces, la idea es replicar el renderizado del lado del servidor en este enfoque original que tenemos, pero más cerca de los usuarios utilizando el mismo enfoque que usamos para las CDNs y también la misma distribución de los edges y los diferentes servidores en todo el mundo. Entonces, en este caso, esta es una imagen de ejemplo de uno de los ejemplos de estas redes de edge. Esto es de AWS, pero tendremos CDNs con estos servidores que alojan el contenido estático, pero en las mismas redes, en las mismas redes regionales, también tendremos servidores de edge computing que ejecutarán lógica del lado del servidor más cerca de los usuarios. Entonces, en este caso, podemos usar el edge para diferentes escenarios como la personalización en el caso de que queramos enviar contenido personalizado a los diferentes usuarios. Podemos usar la geolocalización para identificar desde dónde visitan nuestro sitio web los usuarios y crear contenido dinámico basado en eso. Podemos implementar enfoques de pruebas AV en el caso de que queramos probar diferentes enfoques en nuestros proyectos, podemos hacerlo basado en este contenido dinámico que podemos generar con el edge computing. Y luego podemos agregar autenticación o seguridad al contenido de nuestros sitios web. Entonces podemos manejar contenido estático pero también contenido dinámico utilizando la misma red de edge que generamos. Mencionaré algunos de los frameworks que permiten trabajar con edge computing y como estamos en una conferencia de React, mencionaré los frameworks de React. El primer ejemplo que quería mencionar es NexGIS. NexGIS ofrece funciones de edge que básicamente son scripts y funciones que pueden ejecutar código de renderizado del lado del servidor, por lo que son pequeños fragmentos de código que pueden ejecutar estas funciones en el edge con renderizado del lado del servidor, pero utilizando el mismo enfoque que usamos para las CDNs. Para ejecutar estas funciones, necesitarás que tu proveedor de alojamiento te lo permita. Los principales proveedores de alojamiento ofrecen diferentes enfoques, pero ofrecen edge computing como Bercel, Netlify, AWS, etc. También podemos usar lo que se llama el middleware. El middleware es una capa o nivel intermedio que puede ejecutar lógica personalizada antes de que se procese una solicitud. En el caso de que estés utilizando Next.js para la generación de sitios estáticos y contenido estático, puedes capturar todas las diferentes solicitudes antes de entregar el contenido estático a los usuarios, y luego puedes ejecutar lógica personalizada del lado del servidor antes de devolver el contenido. Entonces puedes agregar contenido personalizado o agregar contenido dinámico a lo que estás devolviendo al usuario basado en eso.

Y otro framework, otro framework de React que podemos mencionar es Remix. El enfoque de Remix es básicamente centrarse en el renderizado del lado del servidor, y utilizan lo que llaman el edge de generación de Next.js. Entonces, la idea con Remix es que puedes elegir entre un runtime de Node.js o un runtime orientado al edge según la ruta que vayas a gestionar en tu sitio web, puedes ejecutar lógica del lado del servidor utilizando un runtime de Node.js o un función de edge, o un worker, o, bueno, nuevamente, los diferentes nombres que los diferentes proveedores de alojamiento te ofrecen para esta lógica de edge computing. Entonces, la idea es que puedas ejecutar lógica del lado del servidor lo más cerca posible de los usuarios finales que visitan tu sitio web.

Así que muchas gracias. Mantengámonos en contacto y podemos seguir hablando sobre el edge u cualquier otro tema. Puedes contactarme en Twitter y disfruta de la conferencia.