Empujando los límites hasta el borde

Hola a todos. Mi nombre es Facundo, y hoy hablaremos sobre Edge. Primero que nada, quería presentarme. Como dije, mi nombre es Facundo, Facundo Giuliani. Soy de Buenos Aires, Argentina. Soy un Ingeniero de Relaciones con Desarrolladores en Storyblok. También soy uno de los organizadores de React Buenos Aires, la mayor comunidad de React en Argentina. Organizamos encuentros locales cada mes en la ciudad. También soy uno de los organizadores de Dev Summit Argentina, otra comunidad de desarrolladores aquí en el país. Así que si estás por aquí, avísame.

Antes de comenzar con el concepto real de Edge, quería introducirlo. Evaluando o revisando cómo solían ser las cosas en el pasado. No solo en el pasado, sino también hoy en día, cuando solicitamos una página o estamos navegando por una página desde nuestro navegador, digamos en nuestro teléfono móvil o nuestra computadora, lo que hacemos es enviar la solicitud a un servidor web. En el caso de la forma original en que solían ser las cosas, el servidor web procesaría mi solicitud y generaría un documento HTML que entregará a mi navegador para que pueda ver la página que quiero visitar. El problema es que esta solicitud se procesa para cada usuario que solicita la página y que quiere visitar la página, lo cual puede estar bien, pero también puede traer algunos problemas. Los problemas son que si tenemos varias personas solicitando la misma página estaremos sobrecargando el servidor que está generando el contenido y los documentos HTML. Y no solo eso, también dependemos de dónde esté ubicado ese servidor web. Entonces los usuarios enviarán la solicitud, la solicitud viajará a la ubicación específica donde se encuentra ese servidor, y luego tendremos que esperar a que el documento HTML regrese a su navegador, digamos. Entonces, si tengo un servidor web ubicado en Australia, porque ahí es donde está alojado mi sitio web, y estoy visitando desde Argentina, mi solicitud tendrá que viajar desde Buenos Aires hasta Australia. Y eso, quiero decir, dependiendo de la distancia que recorre la solicitud, afectará el tiempo de carga de mi página. Entonces, teniendo en cuenta estos problemas, se desarrolló un nuevo concepto con los años, que es la Red de Distribución de Contenido o CDN, y estas CDN son un grupo de servidores distribuidos geográficamente que aceleran la entrega de contenido porque estamos acercando el contenido a los usuarios. Básicamente, una CDN es una red de servidores que se llaman nodos, estos nodos van a replicar el contenido en cada una de las ubicaciones de los diferentes servidores y la solicitud de los usuarios viajará al nodo más cercano para obtener el contenido en lugar de tener que ir a una ubicación particular o a un servidor web particular. Entonces, en el mismo ejemplo que mencioné antes, si tengo un nodo de CDN en Brasil, digamos, mi solicitud en lugar de tener que ir a Australia y traer de vuelta la página HTML que estoy solicitando, viajaría a Brasil y obtendría el mismo contenido. Los beneficios que aportan las CDN son que estamos reduciendo el consumo de ancho de banda porque no estamos enviando todas las solicitudes al mismo servidor web. Por otro lado, tendríamos un mejor rendimiento por esta razón y por la razón de lo que dije, la solicitud no tiene que ir a una ubicación particular en el mundo. Y por otro lado, también tendremos más seguridad porque los usuarios no estarán solicitando el contenido al servidor web específico que está generando el contenido, sino que van a solicitar al nodo más cercano que está alojando el contenido específico que queremos entregar. Y cuando digo contenido específico, es porque las CDN o los nodos del servidor de las CDN están mejorados para entregar contenido estático. Pueden entregar activos estáticos como archivos HTML, archivos CSS o archivos JavaScript. Y eso atrajo la atención a un nuevo concepto llamado generación de sitios estáticos. Básicamente, se trata de crear un sitio web que se genera y se construye durante el proceso que ejecutamos para generar la versión estática de las diferentes páginas de nuestro sitio web.

Lo que hacemos es básicamente ejecutar este proceso de construcción y generará todas las páginas de mi sitio web en una forma estática con activos estáticos como archivos HTML, archivos CSS, y archivos JavaScript. Y podemos usar eso para alojar nuestro sitio web y usarlo y obtener la ventaja de las CDNs.

Pero probablemente estás viendo aquí el problema y el problema es que las CDNs están planeadas para entregar contenido estático. Entonces, ¿qué sucede cuando tengo contenido dinámico que necesita ser generado para un usuario particular con condiciones particulares y para una solicitud particular que está llegando? Digamos que necesito procesar una solicitud particular y enviar contenido basado en esa solicitud. Si ese es el caso, todavía tenemos lo que llamamos un servidor de origen en nuestra CDN. Este servidor de origen es como el servidor web que mencionamos antes que procesará cada solicitud y entregará el contenido o entregará el resultado del procesamiento. Pero el hecho es que nuevamente, esta CDN, esta red, solo tiene un servidor de origen, por lo que si estoy solicitando contenido estático, está bien. Puedo obtenerlo del nodo más cercano de la red, pero si necesito contenido dinámico, tengo que enviar la solicitud a un servidor de origen particular, y estamos teniendo el mismo problema que teníamos antes.

Entonces, con este concepto en mente, y después de que los servidores web evolucionaron y tuvieron nuevas características y nuevas posibilidades, se desarrolló un nuevo concepto que es el concepto de DH. DH es básicamente una red distribuida, como la que tenemos para las CDNs. Pero en este caso tenemos una architecture donde estamos procesando los datos del cliente tan cerca de la fuente de esos data como sea posible. Entonces, DH está básicamente evolucionando las CDNs para tener servidores de origen, o algo así como servidores de origen, digamos, donde tenemos los nodos de la CDN. Entonces, además de entregar contenido estático desde nuestros nodos de CDN, también vamos a poder procesar data y basado en el procesamiento dinámico o la lógica del lado del servidor que procesará los data que vienen de los clientes, podremos entregar contenido dinámico a ellos más rápido porque lo estamos haciendo más cerca de la fuente de los data, que son los usuarios. Entonces, como puedes ver, tenemos algunos de los principales beneficios que también tenemos para las CDNs que son mejor performance, más security, pero también vamos a tener información en tiempo real y fácil scalability porque podemos agregar más servidores de borde, como se les llama, a nuestra red y nosotros podremos procesar solicitudes de más usuarios de diferentes ubicaciones. Entonces, estas redes de borde, algunos de los principales casos de uso que podemos resolver con la computación de borde, digamos o una red de borde son la personalización. Podemos evaluar la solicitud de los usuarios. Y basado en ciertos parámetros que estamos definiendo, podemos devolver cierto contenido o un contenido diferente. También podemos aplicar geolocalización basada en la ubicación del usuario que está visitando nuestro sitio web. Podemos devolver cierto contenido o mostrar una parte particular de nuestra página web. También podemos implementar estrategias de pruebas A-B testing si estamos evaluando para lanzar una nueva campaña en nuestro sitio web. Usando este procesamiento dinámico de la solicitud podemos mostrar una versión particular del contenido o la otra. Y finalmente, también podemos gestionar la security. Podemos aplicar authentication o autorización dinámicamente y podemos evaluar qué usuarios están visitando nuestro sitio web. Y basado en eso, mostrar contenido particular, mostrar validation, algunas cosas así. Entonces, como estamos discutiendo el concepto de Edge, que también está vinculado al proveedor web o al servidor web que vamos a usar o al proveedor de alojamiento que vamos a usar para alojar nuestro sitio web. También tenemos que tener en cuenta el marco que vamos a usar para crear el código y la aplicación en sí que se alojará en el Edge. Como estamos en React Berlin mencionaré cómo un par de marcos basados en React están manejando el concepto de Edge y las características que nos ofrecen para manejar eso. Uno de los marcos es Next.js. Next.js ofrece lo que llaman Edge functions, que son básicamente scripts serverless. Quiero decir scripts de los que no tienes que preocuparte por el mantenimiento del servidor web que se ejecutan del lado del servidor, quiero decir que ejecutan la renderización del lado del servidor que

Así que esa fue una breve introducción al Edge. Espero que hayas aprendido algo nuevo. Muchas gracias y disfruta el resto de la masterclass. Hasta pronto.