Criterios de selección tecnológica
Para los equipos de desarrollo es todo un reto adaptarse a las exigencias de un contexto tecnológico que evoluciona cada día. Para ello tienen que existir perfiles que se dediquen a la investigación, selección y adopción de nuevas tecnologías para el stack del equipo. No menos desafiante que la selección es la detección y el descarte de herramientas legacy, que seguirán formando parte de proyectos existentes pero no serán adoptadas en el futuro.
Estas son algunos de los criterios que valoramos desde Workoholics para llevar adelante este tipo de decisiones:
- Características y requerimientos del proyecto: El primer factor a considerar para plantear la solución técnica de un proyecto es tener en cuenta si los requisitos del proyecto son condicionantes, limitantes o incompatibles con las diferentes opciones existentes.
- Tecnología heredada: Es posible que nos encontremos con proyectos que hereden tecnologías previas que condicionan totalmente la decisión. También es probable que existan integraciones con herramientas de terceros que requieran el uso de una tecnología concreta.
- Contexto tecnológico: Es muy importante mirar a nuestro alrededor y tener en cuenta el contexto tecnológico de cada momento. En este sentido encontraremos muchas opciones sobre las que hacer una valoración teniendo en cuenta aspectos como madurez, aceptación y comunidad de desarrollo.
- Know how del equipo de desarrollo: La adopción de una tecnología tiene un impacto directo en el equipo. El tiempo de adopción depende del conocimiento y de la curva de aprendizaje de la herramienta, por lo que será determinante a la hora de seleccionar o desechar una posibilidad.
- Características y capacidades técnicas del cliente: El cliente también tiene cierto impacto en la selección, de hecho es probable que en un proyecto sea requisito obligatorio el uso de una tecnología concreta.La interacción del cliente en un proyecto puede darse en distintos niveles: desde la colaboración directa en el desarrollo y el código fuente, hasta la gestión exclusiva de contenido mediante un CMS. Considerar estos escenarios resulta clave para una selección óptima de las tecnologías.
- Escalabilidad y versatilidad: Las herramientas que remen a favor de la escalabilidad de un proyecto son claves. Un proyecto digital tiene que ser un ente vivo que pueda ser modificado y escale de manera ágil, para ello tendremos en cuenta que la tecnología sea lo suficientemente flexible de cara a la sostenibilidad del proyecto en el tiempo.
En toda nuestra trayectoria hemos seleccionado y desechado muchas tecnologías y hemos apostado por un stack tecnológico que se adapte lo mejor posible a nuestros tiempos. Uno de los frameworks que mejor se ha adaptado al equipo y que ha resultado caso de éxito en proyectos de diferente tipología es Astro, tecnología sobre la que hablaremos a continuación.
Evolución de Astro
La relación de Astro y Workoholics comienza en el año 2022, año en el que se publica su primera versión. Pese a tener un corto recorrido decidimos adoptar la tecnología en detrimento de Gatsby, framework que utilizamos entonces para el desarrollo de sitios web estáticos. El objetivo inicial de Astro era el desarrollo de sites estáticos orientados al contenido, en nuestro caso empezamos a utilizarlo para ese propósito, pero la realidad ha sido bien diferente ya que en sus diferentes versiones ha ido evolucionando poniendo el foco en la versatilidad y escalabilidad, adaptándose correctamente a diferentes escenarios, casuísticas y complejidades.
Actualmente, la versión estable de Astro es la 5, versión que refleja su madurez como framework. Ha ganado robustez y ampliado sus funcionalidades, ofreciendo soluciones a una amplia variedad de retos en los entornos web.
Orientado al contenido
Es una herramienta orientada al contenido, capaz de integrarse con diferentes orígenes de datos en un mismo proyecto. Con Astro puedes combinar contenido escrito en Markdown para páginas estáticas, consumir datos desde una API REST, leer información estructurada en JSON, o incluso conectar un CMS como Strapi o WordPress. Esta flexibilidad permite construir experiencias dinámicas sin perder el enfoque en el rendimiento y la simplicidad.
Además, no solo se integra con esos orígenes de datos, sino que los gestiona de forma homogénea, sin importar su formato, lo que simplifica tanto la integración como el desarrollo.
Estrategias de renderizado
Con Astro es posible implementar diferentes estrategias de renderizado, SSR (server side rendering), SSG (static site generation), rendering híbrido. A efectos prácticos no hay cambios significativos en lo que al entorno de ejecución de desarrollo (si habrá que tenerlo en cuenta de cara a las características de la infraestructura para el alojamiento). En cuanto al desarrollo en sí habrá que tener en cuenta ciertos aspectos y prestar gran atención a diferenciar correctamente la implementación del código del lado del servidor, tiempo de ejecución o del lado del cliente.
- SSG - Static Site Generation: El contenido y el código se procesan y compilan en tiempo de compilación (build time). El compilador, Vite en este caso, es el encargado de generar todos los recursos estáticos necesarios para que la web funcione (HTML, CSS y JavaScript). Además se encarga de optimizar y generar diferentes versiones de las imágenes para optimizar lo máximo posible el rendimiento. En este caso bastaría con un alojamiento basado en Nginx para servir la web.
- SSR - Server Side Rendering: Para utilizar esta estrategia existen diferentes adaptadores en el core: NodeJS, Vercel, Netlify y Cloudflare. En nuestro caso utilizamos el adaptador de NodeJS y para utilizarlo únicamente hay que instalar la dependencia correspondiente e incluirlo en el archivo de configuración.
El formato de salida también es configurable entre standalone o middleware. La opción standalone compila el código listo para ser servido a través de un archivo como entrypoint, en cuanto a la opción middleware únicamente se compila el código siendo el desarrollador el encargado de servirlo utilizando herramientas complementarias como Express o Koa.
El objetivo de esta estrategia es servir sites dinámicos siendo el lenguaje del lado del servidor el encargado de realizar las diferentes peticiones a los orígenes de datos y el encargado de hidratar los componentes del site de forma dinámica. - Estrategia de renderizado híbrido: Otro acercamiento muy interesante en cuanto a la estrategia de renderizado es el híbrido. Para utilizar esta estrategia partiremos de la configuración mencionada para SSR. La diferencia es que podremos seleccionar estratégicamente las secciones estáticas de la web para que se sirvan de forma estática y con una línea de código será suficiente para que los contenidos y el código se procese, se compile y se consuma de forma estática.
Agnóstico del frontend framework
Esta es una de las características más interesantes de la tecnología, ya que dota de una grán flexibilidad al equipo desarrollo. Normalmente acostumbramos a ceñirnos a un frontend framework o hacer integraciones complejas con librerías orientadas al desarrollo frontend. En este caso Astro es agnóstico del frontend framework, lo que quiere decir que podemos utilizar frameworks diferentes como React, Vue, Svelte o Web Components sin mayor esfuerzo añadiendo un par de líneas de código en el archivo de configuración. Incluso podríamos utilizar 2 frontend frameworks dentro del mismo proyecto si fuera necesario, aunque no sea lo habitual, algo útil en escenarios donde se necesite integrar un módulo desarrollado previamente en otra tecnología compatible.
Astro Islands
Astro se construye en base a una arquitectura web basada en componentes que normalmente desarrollaremos utilizando alguno de los frontend frameworks mencionados anteriormente, aunque también es posible desarrollarlos utilizando su propio sistema. La compilación y el hidratado de esos componentes ocurre en el servidor o en tiempo de compilación. ¿Pero qué ocurre con los componentes que tienen que ser interactivos?
“Astro island” es un componente que requiere de interacción dentro del proyecto y por lo tanto de una gestión de estados y eventos. Cada isla es independiente y se aísla de otras islas que puedan existir en la misma página. Una de sus ventajas es el rendimiento, ya que la mayor parte de un site sería HTML y JavaScript estático que procesaría el servidor y solo se ejecutarán componentes específicos del lado del cliente. Otro de los beneficios del uso de islas es que Astro cuenta con un sistema de directivas que permiten configurar el comportamiento en cuanto a su hidratación, carga e interacción. Estas son las más utilizadas:
- client:load: El componente se carga e hidrata tanto del lado del servidor como del lado del cliente. Esta directiva es útil para elementos de la UI que deban ser inmediatamente visibles e interactivos lo antes posible. En cuanto a la hidratación, se efectúa inmediatamente al cargar la página.
- client:idle: Carga e hidrata el componente una vez que la página haya terminado con su carga inicial y se haya activado el evento requestIdleCallback. Esta directiva es útil con elementos de la interfazI de menor prioridad que no necesitan ser interactivos inmediatamente.
- client:visible: Carga e hidrata el componente una vez que haya intersectado con el viewport del usuario, utiliza un IntersectionObserver internamente para realizar un seguimiento de la visibilidad. Ideal para componentes de baja prioridad que se encuentran en la parte inferior de la página y no son visibles de inicio. Otro uso podría darse en elementos que requieran de muchos recursos y preferimos que se carguen con prioridad baja.
- client:only: El componente se carga y se hidrata únicamente del lado del cliente.
Otras características
- Vite 6 integrado: Astro 5 integra la nueva versión de Vite (v6), incluyendo una renovada API de entornos que permitirá a desarrolladores e integradores adaptar entornos más parecidos al de producción.
- Sistema de optimización de imágenes: El core cuenta con un sistema y componentes orientados a la optimización de imágenes a diferentes resoluciones y formatos.
- Colecciones de contenido dinámico "live": Introducción de loaders que se ejecutan en tiempo de ejecución (en lugar de build time), permitiendo obtener datos siempre actualizados por petición. Ideal para contenido cambiante o personalizado, aún en estado experimental.
- Middleware: Capa intermedia entre la petición del usuario y la respuesta de la aplicación. Te permite interceptar cada request entrante para ejecutar lógica personalizada antes de que se entregue la página o el recurso.
- Internacionalización i18n: Astro incorpora soporte nativo para internacionalización (i18n), lo que permite gestionar múltiples idiomas dentro de un mismo proyecto de forma sencilla y ordenada.
Lasai, primer proyecto con Astro
Nuestro primer proyecto con Astro fué el desarrollo de la web corporativa de Lasai. Lasai, es una empresa que se dedica al diseño, fabricación y comercialización de barcos eléctrico-solares. Su objetivo principal es posicionar la marca como referente internacional, transmitiendo valores de sostenibilidad, diseño, innovación y calidad.
Para tomar la decisión sobre la solución tecnológica se evaluaron diferentes alternativas. Los factores decisivos para optar por Astro fueron: la naturaleza estática del contenido, la baja frecuencia de actualización y la necesidad de soportar internacionalización. En ese entonces, Astro se encontraba en sus primeras versiones, pero tras realizar varias pruebas de concepto, confirmamos que era la mejor opción.
Como framework de presentación utilizamos React, y como origen de datos, al tratarse de contenido estático, implementamos un sistema basado en archivos Markdown, organizados en diferentes directorios para gestionar de manera eficiente la internacionalización.
En cuanto a la estrategia de renderizado, en este caso no hubo ninguna duda, utilizamos SSG (Static Site Generation), por lo que los contenidos y el código se procesa en cada compilación del proyecto para posteriormente desplegarse y ser servido de forma estática.
Como ocurre en muchos proyectos, surgen nuevas necesidades y surge la necesidad de escalarlo en una nueva fase. En este caso, pasado un tiempo se planteó la necesidad de crear un configurador de embarcaciones. Para ello, necesitaban gestionar el contenido por ellos mismos a través de un gestor de contenidos.
Para implementar los nuevos requisitos, incluimos a la infraestructura un CMS basado en Strapi para gestionar el contenido del configurador. En este caso, la frecuencia en la actualización de contenidos seguía siendo baja, por lo que mantuvimos SSG como estrategia de renderizado, el site se compila a petición del CMS cada vez que se quiera desplegar una actualización de contenido.
Getxo Kultura, WordPress headless ultra-rápido
En 2022 llevamos a cabo el desarrollo de la web de la sección de Cultura del Ayuntamiento de Getxo, un portal diseñado para centralizar y difundir la agenda cultural del municipio. El sitio ofrece información actualizada sobre eventos, espacios y servicios culturales, convirtiéndose en un punto de referencia para la ciudadanía. Además, uno de los objetivos principales del nuevo portal fue impulsar la conversión en la venta de entradas.
El equipo responsable de la gestión de contenidos contaba con experiencia previa en WordPress, lo que lo convertía en una opción idónea para implementar el backend en modo headless.
Para el frontend, optamos por una combinación de Astro + React, logrando así una página altamente optimizada que, además de ofrecer un excelente rendimiento, potencia la interactividad y la experiencia de usuario.
En cuanto a la estrategia de renderizado, la frecuencia de actualización del portal nos llevó a optar por SSR (Server-Side Rendering), garantizando así que los contenidos se muestran de forma dinámica y actualizada.
Sin embargo, debido a la lentitud de la API de WordPress, implementamos un middleware encargado de generar archivos estáticos organizados en un sistema de directorios en cada actualización. De esta manera, conseguimos aprovechar las ventajas del SSR sin depender de peticiones constantes a la API, lo que se tradujo en una mejora sustancial del rendimiento y en una experiencia de navegación mucho más fluida para los usuarios.
Athletic Club: Astro para el frontend en un proyecto colaborativo
En el desarrollo de la web corporativa del Athletic Club nos encargamos de la implementación del frontend, trabajando estrechamente con el equipo de desarrollo del propio club, responsable de construir un backend a medida para el proyecto.
Los aspectos que se tuvieron en cuenta para la selección tecnológica y la estrategia de renderizado fueron los siguientes:
- La web del Athletic es una plataforma con una gran cantidad de información, noticias de actualidad, partidos en directo, clasificaciones, calendarios, estadísticas históricas desde el año de su fundación…
- Otra consideración a tener en cuenta es la frecuencia en cuanto la actualización de los contenidos. En este caso, el equipo de comunicación del Athletic publica una media de 5 noticias al día y mantiene actualizada la información de la temporada de cada uno de sus equipos ya sean principales o de cantera.
- Es requisito del proyecto que cada cambio de contenidos que se efectúe se refleje inmediatamente en la web.
En este caso, volvimos a escoger Astro + React como solución técnica, debida a la altísima frecuencia de actualización y la necesidad de que los datos se viesen reflejados al instante, se propuso una estrategia de renderizado SSR (Server Side Rendering).
CAF, ejemplo claro de renderizado híbrido
CAF es un proyecto que hemos abordado de forma íntegra que ha tenido como objetivo la renovación de su web corporativa. Hemos desarrollado el backend y frontend, hemos implementado el sistema de integración continua.
En cuanto a la frecuencia en la actualización del contenido tenemos una casuística diferente a las anteriores ya que hay secciones con mucho dinamismo como el área de accionistas e inversores, o las soluciones que ofrece CAF y otras más estáticas como la de conócenos o el contacto.
Para el desarrollo del backend, se utilizó Strapi con modelo de datos basado en colecciones y componentes, dando flexibilidad en la gestión de contenidos.
Para el frontend basamos la solución en Astro + React bajo un enfoque híbrido en la estrategía de renderizado, ya que había secciones que tienen una frecuencia de actualización muy baja (SSG) y otras que necesitan que los contenidos se actualicen dinámicamente (SSR).