No sabes cómo hacer SSR

¡Hola a todos! Hoy les hablaré sobre SSR y mi viaje personal en SSR. Vamos a sumergirnos en ello. Primero, las presentaciones en orden. Mi nombre es Emanuele Stoppo, soy italiano, como podrán entender por mi acento, y vivo en Irlanda. Soy un colaborador principal del proyecto Biome y pertenezco al equipo de plataforma del proyecto Aster. También soy un ávido jugador de consola.

Para cuando este video se publique, probablemente estaré jugando Final Fantasy 7. Ahora, comenzaremos nuestro viaje hablando sobre este marco de codificación, que es básicamente mi primera experiencia con SSR. Y terminaremos nuestro viaje con Astro. Ahí es donde las cosas se pondrán interesantes. Ya verán por qué.

Primero que nada, ¿qué es el renderizado en el lado del servidor? La cosa es que ha cambiado a lo largo de los años. Cuando comencé, el renderizado en el lado del servidor era la forma en que se creaban los sitios web. Así es como se hacían. Pero luego llegó Node.js, nuevos patrones, nuevas posibilidades, nuevas herramientas, y así sucesivamente. Las cosas cambiaron, nuevos patrones, y demás. Básicamente, es cuando un servidor te proporciona HTML y tú se lo das a tu cliente. Así que renderizas una página en tu servidor y eso es todo. Muy básico, ¿verdad? Ahora entendemos qué es SSR.

Comencemos con mi primera experiencia. Fue en 2010, justo después de salir de la universidad. PHP fue mi primera experiencia. Era un desarrollador de PHP. Tuve la oportunidad de trabajar con Codingigniter, que es un marco basado en MVC, que significa Modelo-Vista-Controlador. Solo para darles una idea de qué es este patrón. Básicamente, tienes tu propia clase, que es el controlador que tiene toda la lógica de negocio de tu página. Luego tienes el modelo. El modelo es generalmente esa entidad que se encarga de todo lo relacionado con tus datos.

Entonces, las operaciones CRUD. Validaciones y demás. Se conecta con la base de datos y se comunica con la base de datos. Y luego tienes la vista. Entonces, la vista generalmente, la llamas dentro de tu controlador. También puedes tener múltiples vistas o reutilizar todas las vistas. Y la vista, generalmente es un lenguaje de plantillas. Este es un ejemplo de un lenguaje de plantillas. Si usas, por ejemplo, Vue y Svelte, ya sabes qué es un lenguaje de plantillas. Y así es como solía hacerlo en aquel entonces. No ha cambiado mucho. Como con Vue y Svelte, tienen una sintaxis diferente. Pero, quiero decir, el concepto. Es el mismo. Interpolamos el lenguaje de plantillas con las variables. Generamos HTML y se lo damos al navegador. Eso es lo que hice al principio. Así es como empecé.

Y luego llegó jQuery. jQuery fue una revolución en ese momento. Es cómo aprendí JavaScript. Y aquí tienes un ejemplo de cómo lo usé con SSR. Así que tenía mi jQuery. Y había otro marco de MVC que se llama Grails. Grails se basa en este lenguaje llamado Groovy. Se compila en JVM. Como dije, sigue siendo un MVC. Y lo que hice fue básicamente que teníamos algunos requisitos donde queríamos tener algunas animaciones sin salir de la página del usuario. Entonces, lo que solías hacer en ese momento era crear un nuevo punto final con un modelo de controlador vista. Específicamente, para estas necesidades, generabas solo el HTML que deseabas tener.

Y luego con jQuery, simplemente haces un get. Obtienes tu HTML y luego haces animaciones y así sucesivamente. Entonces, con jQuery, podías reemplazar un HTML por otro utilizando animaciones. Y así es como era la representación del lado del cliente en aquel entonces. Fue realmente... Sí, quiero decir, al final, podías hacer todas tus estrategias y cosas así. Pero así fue como pude jugar con este tipo de cosas. Fue realmente, realmente interesante. Y también estaba a cargo de los controladores y las vistas. Así que simplemente podía ir allí en el marco, crear un nuevo controlador, hacer parámetros, y fue realmente divertido en ese momento.

Luego tenemos Central Touch. No voy a molestarte con Central Touch. Esencialmente, es un marco móvil todo en uno para construir aplicaciones web. Tienes tus tiendas, tienes tus componentes, vistas, modelos y todo. Pero no despertó mucho interés. Fue unos años antes de que llegara React. Fue realmente aburrido. No es que... Quiero decir, aprendí muchas cosas, pero básicamente estabas encerrado en el marco. Y ahora es donde empezamos a obtener cosas interesantes. Sí. Luego llegó React y tenía características realmente agradables. Y algunas de estas características eran realmente refrescantes. Y quería usarlas. ¿Verdad? Así que, sí. Pero, no. Siempre hay un pero. Así que tenía este proyecto. Quería usar mucho React. Y mi gerente dijo, vamos a usarlo.

Pero aún así, estamos en un mundo empresarial, por lo que las cosas no son perfectas. En este proyecto, había algunas restricciones. Por lo tanto, el sitio web estaba impulsado por un marco de Microsoft.NET. Específicamente, un CMS llamado Umbraco. Y parecía ser como un WordPress. Tienes tu oficina de respaldo. Puedes personalizarlo. Pero también, el sitio web es proporcionado. El sitio web real es renderizado por WordPress. Lo mismo ocurre con Umbraco. Entonces... Pero yo quería usar React. Entonces... ¿Cómo lo hice? Bueno... Sí, escribí mi propio marco de SSL. Y, sí. Como tú... Sí, es un meme. Pero, quiero decir, eso es cierto. Pero lo que pasa es que en ese momento no había frameworks para hacer eso. Ni siquiera en .NET. Quiero decir, estaba escribiendo en terreno desconocido en ese momento. Así que tuve que idear algo. Bueno, lo que pasa es que escribir tu propio marco de SSL no es tan difícil. En realidad, es más fácil de lo que piensas. Solo hay, como, tres principios que debes seguir. Entonces, debes tener un Go Blast state manager. En ese momento, Redux era el lugar al que ir. Necesitas tener un tiempo de ejecución. Entonces, en ese momento, Node.js era la opción a seguir.

No podías extenderlo por todas partes. Simplemente lo ejecutas y te da lo que necesitas usando un script. Y luego, simplemente accedes a la página.

Entonces, una vez que tengas estas tres cosas, puedes tener tu propio marco de SSL. Veamos brevemente lo que hice en ese momento. Tenía un marco .NET. Había un motor de plantillas, como vimos antes. Por lo general, accedes a una página y tienes tu propio estado global de Redux. Ese es un objeto global. Y, básicamente, para cada página, inyectas el estado global inicial de tu página. ¿De acuerdo?

Luego, debes tener este runtime. Afortunadamente, en ese momento, existía esta biblioteca que te permitía pasar un marco de React. Y era capaz de darte el HTML real. Era, como, en tiempo de ejecución dentro del motor de plantillas. Era realmente rápido. No había ninguna sobrecarga, incluso porque, por lo general, las páginas que contienen componentes de React eran realmente pequeñas. Entonces, no necesitábamos renderizar toda la página. ¿De acuerdo? Teníamos páginas donde teníamos, como, un componente de React aquí o un componente de React allá. Entonces, era una mezcla de HTML estático y componentes de React. Una vez que tienes este HTML, lo tienes en tu motor de plantillas. Y al final, volvemos a nuestra página. Necesitamos obtener realmente el ID donde se renderizó el componente de React e iterarlo. Como puedes ver, no es tan difícil. Estos son los fundamentos para crear tu propio marco de SSL. Y luego solo necesitas conectar estos fundamentos utilizando las bibliotecas que tienes. Y el trabajo está hecho. No es ciencia espacial. De hecho, estaba realmente orgulloso de ese trabajo. Y fui a verificarlo. Este webpack todavía utiliza la misma lógica.

Entonces, quiero decir, esa fue una elección realmente buena. Claro, las cosas han cambiado. Pero aún funciona. De acuerdo.

Ahora vamos con un enfoque más moderno. Y ahí es donde entra en juego Next.js. Sí, también trabajé con Next.js. Es un marco de trabajo realmente genial. Y con GetStaticProps, la vida fue mucho, mucho más fácil. Como, GetStaticProps eliminó una gran parte de la red que expliqué, porque eso es lo que Next.js hacía en ese momento. Entonces, crea tu propio estado global y demás. Pero Next.js también tiene más, como enrutamiento progresivo del lado del cliente y otras cosas. Es un marco de trabajo realmente bueno. De hecho, lo es. Pero, ya sabes, la empresa es diferente, sí. Entonces, en ese momento, teníamos restricciones realmente extrañas.

Entonces, nuestro backend no tenía ningún servidor en absoluto. Pero solo podíamos usar lambdas. Como, el backend estaba utilizando lambdas. Y para ellos, era genial. Pero para nosotros, eso fue bastante desafiante. La versión inicial del sitio web fue SPAS. Entonces, teníamos una página HTML. Estudiamos JavaScript. Y así, no. No. CreateRectApp. Entonces, fue un fork de CreateRectApp. Pero el SEO del sitio web fue penalizado negativamente.

Entonces, tuvimos que hacer algo. En ese momento, Next.js introdujo una nueva opción llamada salida serverless, o algo así. Y permitiría exportar cada página como un artefacto serverless. No una lambda, un artefacto serverless. Y fue genial para nosotros. Fue genial.

Entonces, ¿qué hicieron? Bueno. Adivina qué. Construí mi propia capa de implementación. Es como si hubiera construido mi propio metaframework. Exactamente eso. Y fue realmente, realmente divertido.

Ahora, veamos qué hice. Muy bien. Entonces, Next.js, como dije antes, crea este artefacto para cada página. Muy bien. Luego, mi metaframework se conecta esencialmente a la construcción serverless de Next.js. Entonces, programáticamente, ejecutamos la construcción. Esta construcción me proporciona toda la información necesaria para crear una lambda para cada página. Al final de la construcción, teníamos todas estas lambdas que podíamos implementar en los diferentes entornos, ejecutarlas en cada solicitud y obtener solo la página que solicitamos, y tener navegación del lado del cliente desde allí. Y así es como Next.js solía funcionar en ese momento.

Entonces, esta lambda, en realidad, no es solo una lambda. Así que fui más allá. De acuerdo. En realidad, hay una lambda real construida dinámicamente. Luego teníamos la capa compacta. Una capa compacta que toma el evento pasado desde la lambda y crea una solicitud de respuesta. Y estas solicitudes de respuesta se pasaban a la página de artefacto. Porque el artefacto no era, como dije antes, compatible con AWS lambda. Solo toma, como, una solicitud entrante similar a Node.js. Entonces, necesitábamos una capa compacta para traducir esta información.

Entonces, necesitábamos una capa compacta para traducir esta información. Y luego teníamos las fuentes de Terraform. Entonces, el marco beta creaba dinámicamente todos los archivos de Terraform que luego se llamaban al final de la construcción.

Entonces, eventualmente, ¿qué hice? Todo lo que hice de código abierto. Tomé toda la lógica que construí para la empresa. Solo agregué una CLI al frente con algunas opciones. Y, sí, quiero decir, pensé que había hecho algo genial. Quiero decir, seguro, es un caso muy específico lo que tengo. Pero tal vez alguien más esté enfrentando el mismo problema. Así que lo hice de código abierto. Pero ahora está archivado porque Next.js eliminó la opción serverless. Entonces, quiero decir, ya no podemos usarlo. Y eventualmente, llegamos a Astro. Entonces, trabajo en Astro y en realidad construí algunas cosas interesantes que te voy a mostrar. Pero antes de eso, voy a revelar algunos secretos sobre Astro. Entonces, conoces sobre SSG, generación de sitios estáticos o sitios web estáticos. ¿Pero sabes que en realidad SSG en Astro es SSR con un paso adicional? Sí, porque cuando lo construimos, en realidad ejecutamos SSR.

Creamos todas estas páginas, como archivos de artefactos correctos. Los importamos, los ejecutamos y luego fueron como una respuesta solicitada cuando obtenemos su respuesta, el HTML, y lo renderizamos. Y los ponemos en un archivo HTML. Así que es SSR en todas partes, ¿sabes? Pero entonces, ¿qué es SSR en Astro? Bueno, en realidad es SSR con un paso de construcción diferente. Entonces, solo tenemos una configuración diferente y emitimos estos artefactos de una manera diferente, de manera genérica. Entonces, los adaptadores realmente pueden consumirlos y construirlos, en realidad, como prefieran. Entonces, tenemos una forma genérica de exportar y también una interfaz para exportar las páginas de las rutas, llamémoslas así.

Y luego los adaptadores, como Node.js, Deno, Vercel, Cloudflare, Netlify, y así sucesivamente, que tienen diferentes requisitos, pueden tomar estos artefactos, manipularlos si es necesario, y crear sus propias configuraciones basadas en sus necesidades. Es como lo que hice antes, como con el metaframework. Esencialmente, eso es lo que hace Astro. Pero hay más. Recientemente, creé un par de características específicas, realmente buenas, en Astro, utilizando SSR y varias otras herramientas.

Una de ellas es la función por ruta. Entonces, ¿qué significa esto? Por defecto, así es como se ve SSR en Astro. Tenemos un solo archivo que maneja todas tus rutas. Entonces, cuando golpeamos y cuando el servidor, en realidad el cliente, solicita una ruta, lo que hacemos es importar dinámicamente el artefacto que pertenece a esa página y devolver su respuesta. En cambio, con la función por ruta, tenemos múltiples puntos de entrada. Entonces, es realmente un caso específico. Nadie necesita algo así. Pero si tienes páginas realmente pesadas con mucho código, mucho JavaScript, a veces este caso de uso puede ayudarte, porque esencialmente es como dividir el código en la plataforma serverless. De acuerdo. Otra cosa increíble es el Middleware de Edge. Hace unos meses, lancé y desarrollé, y lanzamos el Middleware de Astro, y unos meses después, agregamos el Middleware de Edge que se puede usar en plataformas como AWS, Vercel, y así sucesivamente. Así es como funciona el Middleware de Astro. Tienes tu solicitud, pasa a través del Middleware. Tenemos estos Locals de Astro que básicamente son información data que puedes pasar a tu componente de Astro. Puede ser cualquier cosa, es un objeto, y también puedes pasar funciones. Y los usas para renderizar tu componente, o tal vez no. Y finalmente, obtienes una respuesta. En Edge, esto es un poco diferente, pero logramos usar el mismo Middleware y hacer que funcione. Entonces, todo comienza desde la solicitud. Generamos esta función de Edge. Por lo general, el Middleware de Edge es una función de Edge, que está muy cerca del usuario, por eso se llama Edge. Y esta función de Edge llama al Middleware de Astro real. Pero luego, necesitamos renderizar el componente de Astro. Entonces, ¿cómo lo hacemos? Esto depende de la plataforma. En Vercel, en realidad tienes una función Next, pero también en Netify, por ejemplo, puedes llamar a Next. O en realidad, en Vercel, puedes hacer una llamada fetch al origen. Entonces, el origen es el archivo real que renderiza tu página, tu componente, cualquier cosa que devuelva algo de HTML. Y como dije antes, en Vercel, dentro de la función de Edge, creamos una función Next. ¿Qué hace esta función? En realidad, hace una llamada fetch al origen, y cuando hacemos la llamada fetch, pasamos estos locals. Entonces, estos locals, como dije antes, en este caso, se serializan y se pasan a través de encabezados al componente de Astro, y luego eventualmente se pueden usar. Y todo se hace usando Rollup y Vite. Hay un error tipográfico. Disculpa por eso. Muchas gracias. Espero que hayas disfrutado mi viaje. Y adiós. Adiós.