You Don’t Know How to SSR

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

Así que, para cuando este video salga, probablemente estaré jugando Final Fantasy 7. Ahora, vamos a comenzar nuestro viaje hablando sobre este marco de codificación, que es esencialmente mi primera experiencia con SSR. Y vamos a llegar y terminar nuestro viaje con Astro. Y ahí es donde las cosas se pondrán interesantes. Y veremos por qué.

Ahora, en primer lugar, ¿qué es la renderización del lado del servidor? La cosa es que ha cambiado a lo largo de los años. Cuando realmente comencé, la renderización del lado del servidor era cómo se hacían los sitios web. Es cómo los haces. Pero luego llegó Node.js, nuevos patrones, nuevas posibilidades, nuevas herramientas, bla, bla, bla. Y las cosas se volvieron diferentes, nuevos patrones, y así sucesivamente. Esencialmente, es cuando un servidor te da HTML y tú se lo das a tu cliente. Así que, renderizas una página en tu servidor y eso es todo. Así que, eso es realmente, realmente básico. Así que, ahora entendemos qué es SSR.

Comencemos con mi primera experiencia. Era 2010. Salí de la universidad. Fue un año después. Y PHP fue mi primera experiencia. Yo era un desarrollador de PHP. Y llegué a trabajar con Codingigniter, que es un marco basado en MVC, que significa Modelo-Vista-Controlador. Solo para darles un resumen de qué es este patrón. Esencialmente, 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 usualmente esa entidad que se encarga de todo lo relacionado con tus datos.

Entonces, las operaciones CRUD. Validaciones y demás. Así que, se conecta con la base de datos y se comunica con la base de datos. Y luego tienes la vista. Así que, la vista suele ser, la llamas dentro de tu controlador. También puedes tener múltiples vistas o reutilizar todas las vistas. Y la vista, suele ser un lenguaje de plantillas. Así que, 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. Así que, no ha cambiado mucho. Al igual que 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. Ese es mi primero. Así es como comencé.

Y luego llegó jQuery. Así que, jQuery fue una revolución en ese momento. Es como aprendí JavaScript. Y aquí hay un ejemplo de cómo lo usé con SSR. Así que, tenía mi jQuery. Y había otro marco 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 esencialmente que teníamos algunos requisitos donde queríamos tener algunas animaciones sin salir de la página del usuario. Así que, lo que usualmente haces en ese momento era crear un nuevo endpoint con un modelo de controlador de vista. Específicamente, para estas necesidades, generas solo el HTML que deseas tener.

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

Luego tenemos Central Touch. No voy a molestarte con Central Touch. Es esencialmente un marco móvil todo en uno para construir esencialmente aplicaciones web. Tienes tus tiendas, tienes tus componentes, vistas, modelos y todo. Pero no generó mucho interés. Fue como unos años antes de que React llegara. Era realmente aburrido. No es que... Quiero decir, aprendí muchas cosas, pero esencialmente estabas enjaulado en el marco. Y ahora es donde empezamos a obtener cosas interesantes. Sí. React llegó, 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 React mucho. Y mi gerente dijo, vamos a usarlo.

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

No podías aplicarlo en todas partes. Simplemente lo ejecutas, y te da lo que necesitas usando un script. Y luego, ya sea que golpees la página.

Así que, una vez que tienes estas tres cosas, puedes tener tu marco SSL. Así que, veamos brevemente lo que hice en ese momento. Así que, tenía un marco .NET. Así que, había un motor de plantillas, como vimos antes. Así que, usualmente vas a una página, y tienes tu propio estado global de Redux. Eso es un objeto global. Y, esencialmente, para cada página, inyectas el estado global inicial de tu página. ¿De acuerdo?

Luego, debes tener este tiempo de ejecución. Así que, afortunadamente, en ese momento, había esta biblioteca que te permitía pasar un marco 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 sobrecarga alguna, incluso porque, como, las páginas, usualmente, que contenían componentes React eran, como, realmente pequeñas. Así que, no necesitábamos renderizar, como, toda la página. ¿De acuerdo? Así que, teníamos páginas donde teníamos, como, un componente React aquí o un componente React allá. Así que, era una mezcla de HTML estático y componentes React. Así que, una vez que tienes este HTML, lo tienes en tu motor de plantillas. Y al final, volvemos a nuestra página. Necesitamos realmente obtener el ID de donde se renderizó el componente React e iterarlo. Así que, como puedes ver, no es tan difícil. Así que, estos son los fundamentos de esencialmente crear tu propio marco SSL. Y luego solo necesitas conectar estos fundamentos usando las bibliotecas que tienes. Y el trabajo está hecho. Como, no es ciencia de cohetes. Y estaba realmente orgulloso de ese trabajo. Y fui a comprobarlo. Este webpack todavía usa la misma lógica.

Así que, quiero decir, esa fue una muy buena elección. Claro, las cosas han cambiado. Pero todavía funciona. Está bien.

Ahora vamos con un enfoque más moderno. Y ahí es donde entra en juego Next.js. Así que, sí. También tuve la oportunidad de trabajar con Next.js. Es un framework realmente genial. Y con GetStaticProps, la vida fue mucho, mucho más fácil. Como, GetStaticProps eliminó un montón de la red que expliqué, porque eso es lo que Next.js hacía en ese momento. Así que, 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 framework realmente bueno. De hecho, lo es. Pero, ya sabes, la empresa es diferente, sí. Así que, en ese momento, teníamos restricciones realmente extrañas.

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

Así que, teníamos que hacer algo. En ese momento, Next.js introdujo una nueva opción llamada output 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 despliegue. Así que, es como si construyera mi meta framework. Exactamente así. 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 meta framework esencialmente se engancha a la construcción serverless de Next.js. Así que, programáticamente, ejecutamos la construcción. Esta construcción me da toda la información necesaria para crear realmente una lambda para cada página. Así que, al final de la construcción, teníamos todas estas lambdas que podíamos desplegar en los diferentes entornos, ejecutarlas en cada solicitud, y obtener solo la página que pedimos, y tener navegación del lado del cliente desde allí. Y así es como solía funcionar Next.js en ese momento.

Así que, esta lambda, en realidad, no es solo una lambda. Así que, era más. Bien. Así que, en realidad, la verdadera lambda se construye dinámicamente. Luego teníamos la capa compacta. Así que, 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 del artefacto. Porque el artefacto no era, como dije antes, compatible con AWS lambda. Simplemente toma, como, una solicitud entrante similar a Node.js. Así que, necesitábamos una capa compacta para traducir esta información.

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

Entonces, eventualmente, ¿qué hice? Hice todo de código abierto. Así que, tomé toda la lógica que construí para la empresa. Simplemente añadí un CLI al frente con algunas opciones. Y, sí, quiero decir, pensé que hice algo genial. Quiero decir, claro, es un caso realmente de nicho 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á realmente archivado porque Next.js eliminó la opción serverless.

Así que, quiero decir, ya no podemos usarlo. Y finalmente, llegamos a Astro. Así que, trabajo en Astro y en realidad construyo algunas cosas interesantes que voy a mostrarte. Pero antes de ir a eso, voy a desvelar algunos secretos sobre Astro. Así que, sabes 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 realmente lo construimos, en realidad ejecutamos SSR. Creamos todas estas páginas, como artefactos correctos, archivos. Los importamos, los ejecutamos, y luego eran como solicitud-respuesta cuando obtenemos su respuesta, el HTML, y lo renderizamos. Y los ponemos en un archivo HTML. Así que, es SSR por todas partes, ¿sabes? Pero entonces, ¿qué es SSR en Astro? Bueno, en realidad es SSR con un paso de construcción diferente. Así que, simplemente tenemos una configuración diferente y emitimos estos artefactos con algo diferente, como de una manera genérica. Así que, los adaptadores pueden realmente consumirlos y construirlos, en realidad, como prefieran.

Así que, tenemos una forma genérica de exportar y también una interfaz para exportar las páginas de las rutas, llamémoslas. 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. Así que, es como lo que hice antes, como con el meta framework. Esencialmente, eso es lo que hace Astro. Pero hay más. Como, recientemente, llegué a crear un par de características de nicho, realmente agradables, en Astro, usando SSR y un montón de otras herramientas.

Una es la función por ruta. Entonces, ¿qué significa? Así que, por defecto, así es como se ve SSR en Astro. Así que, tenemos un solo archivo que maneja todas tus rutas. Entonces, cuando accedemos 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. Así que, en realidad es un caso de nicho. Nadie necesita algo así. Pero si tienes páginas realmente pesadas con mucho código, mucho JavaScript, a veces este caso de uso podría ayudarte, porque esencialmente es como la división de código en la plataforma serverless.