Trabajando con Astro

Tags: #frontend#astro#my-life

SGT911 - 2/15/2025

Astro Banner

Pese a que posiblemente esta sea un blog un poco precoz, me gustaria empezar a documentar como voy avanzando desde el punto de vista de un desarrollador BackEnd como se desarrolla y se mantiene una pagina web como lo es Astro y probablemente esta sera un post que estare actualizando a medida que voy trabajando en mi pequeño sitio web y voy descubriendo…peculiaridades de lo que es trabajar como Developer FrontEnd, Diseñador y Escritor de mi sitio mas haya de configurar la pipeline para que CloudFlare despliegue el sitio web.

¿Por que Astro?

Gracias a un par de experiencias en un par de empresas tuve acercamientos al tema del FrontEnd, gracias a mi amigo Santi he conocido varios frameworks tales como Next.JS, Svelte y Astro; Ese acercamiento ademas de darme cuenta y reivindicar que no me gusta el desarrollo FrontEnd, me dio a entender que los frameworks y las tecnologias FrontEnd tienen ciertas especialidades y pos tecnologias especificas como el SSG (Static Site Generation) o el SSR (Server Side Rendering) lo cual permite optimizar el desempeño en la red y en el consumo de recursos dependiendo lo que se quiera lograr. Esto me lleva a la toma de la desicion mi objetivo es tener un sitio web liviano donde principalmente lo tengo para tener un poco de auto-propaganda, ademas, de contar mis vivencias a travez de este blog y mi experiencia a travez de la seccion /my-work a lo cual temas como el SSR y este tipo de sistemas no me atrajo tanto a la hora de desarrollar mi sitio web a lo cual frameworks como Next.JS o Nuxt (pese a que me guste bastanto Vue.JS), temas como lo es Svelte en conjunto con Svelte Kit se usa mas que todo para aplicaciones muy dinamicas a lo cual todas esas caracteristicas no las voy acabar utilizando a lo cual seria usar un framework muy vitaminado (como dice mi jefe) que a la final voy sub-utilizar, a lo cual me acabe decantando por Astro gracias a razones como:

Principalmente por estas razones me decante a usar Astro como framework para mi sitio web, hasta el momento la experiencia trabjando en este y usando sus caracteristicas como las collections o el image optimization ha sido bastante facil de implementar ademas de optimo. Al punto de que he procurado seguir todas las recomendaciones que hay en la documentacion de Astro al punto que el sitio no tiene nigun archivo que venga de CDN fuera de los archivos inyectados por el propio CloudFlare.

SSG vs SSR

Como ya comente me acabe decantando por el SSG por sobre el SSR principalmente teniendo en cuenta que este sitio web va a mostrar principalmente contenido estatico y que sera invariante no importa desde donde se vea, mas haya del CSS y Tailwind que ya me esta dando suficientes dolores de cabeza, preferi el SSG ya que me permite tener ya todo mi contenido previamente renderizado y ya listo para servir en este caso en la CDN de CloudFlare. Este camino me ha llevado a conocer un par de caracteristicas interesantes del propio Astro como lo es el exportable de getStaticPaths, el Astro.rewrite, entre otras herramientas las cuales me permiten que todo el contenido de la pagina ya este preparado sin necesidad de un servidor o una lambda function la cual este consumiendo recursos mas haya del ancho de banda.

Teniendo en cuenta que el contenido mas dinamico como el blog y el apartado de my-work esta gestionado bajo MarkDown esto me permite aprovecharme de la caracteristica de las collections dandome posibilidad a tener previamente cargado todo el codigo y todo el contenido ademas de despues cargarlo en las distintas paginas configurando previamente las URL donde estas iran consignadas.

Astro y el _redirects de cloudflare

Un detalle interesante durante el desarrollo del blog fue configurar un metodo de crear un link pointer donde me permita desde la pagina inicial rederigir a los posts del blog sin necesidad de componer la URL tal cual con todos los parametros (un poco por pereza la verdad), lo cual hice inicialmente por medio de un Astro.redirect pero un pequeño detalle que no tome en cuenta es que el redirect no funciona en SSG si no crea un segmento con un:

<meta http-equiv="refresh" content="2;url=https://sgt911.dev/blog/2025-02-15-trabajando-con-astro/">

El cual por supuesto no es lo ideal para una pagina a lo cual buscando dentro de la documentacion de cloudflare encontre la posibilidad que la propia CDN pueda generar esas redirecciones tema el cual me interesa; pequeño pero no menor detalle estas redirecciones deben ser dinamicas por que a medida que se compilan mas y mas paginas los permalinks cambian ademas que se generan por el propio contenido que se agrega al blog.

En el primer intento fue generar algo sencillo como _redirects.ts el cual se presupondria se compile en un archivo _redirects donde se encuentre ahi el contenido dinamico generado por el archivo TypeScript, interesante descubrimiento que Astro por seguridad no serializa ningun archivo el cual inicie con un _ dentro del nombre de archivo. Entre ires y venires el invento chino que hice para que funcione los redirects fue el siguiente:

// src/pages/[redirects].ts
import type { GetStaticPaths } from "astro";
import { getCollection } from "astro:content";
import slugify from 'slugify';

export const getStaticPaths = (async () => {

  return [
    {
        params: {redirects: '_redirects'},
    }
  ];
}) satisfies GetStaticPaths;

interface IRedirect {
    from: string;
    to: string;
    status: number;
}

async function generateRedirects() {
  const redirects: IRedirect[] = [];

  const blogs = await getCollection('blog');

    redirects.push(...blogs.map(blog => {
        const urlData = {
            year: blog.data.date.getFullYear().toString(),
            month: (blog.data.date.getMonth() + 1).toString().padStart(2, '0'),
            day: blog.data.date.getDate().toString().padStart(2, '0'),
            slug: slugify(blog.data.title, { lower: true, strict: true, trim: true })
        }

        return {
            from: `/blog/id-${blog.data.id}`,
            to: `/blog/${urlData.year}-${urlData.month}-${urlData.day}-${urlData.slug}`,
            status: 302,
        };
    }));


  const redirectsContent = redirects
    .map(redirect => `${redirect.from}\t${redirect.to}\t${redirect.status}`)
    .join('\n');
  return redirectsContent;
}


export async function GET() {
  return new Response(await generateRedirects(), {
      headers: {
          'Content-Type': 'text/plain',
      }
  })
}

Tailwind, ¿Mejor o peor que CSS?

Siendo totalmente sincero soy la peor persona a la cual podrian llamar para desarrollar algo en CSS y menos aun en Tailwind (ni te cuento si es con temas custom), pero bueno me deje convencer que te permitia mantener una linearidad en tu pagina web ademas de que seria mas facil de mantener que un CSS directamente y pese a que este no sea una pagina necesariamente grande o que contenga muchos componentes pero igual ya tuve un tiempo trabajando con este. Ahora bien Tailwind ha sido un boost en velocidad principalmente a la hora de maquetar toda la estructura de la pagina pero igualmente esto no te quita que si no posees un sentido del diseño medianamente formado puedes destrozar todo en cuestion de un par de lineas.

Como notaran este es la seccion mas corta por que por supuesto no estoy acustumbrado a trabajar con diseño y esto solo revindica lo malo que soy a la hora de hacer diseños desde 0. Respondiendo a la pregunta que puse en el titulo de la seccion no diria que es ni mejor o peor solamente es una herramienta mas que te permite orquestar interfaces mucho mas rapidamente pero esto no quita el hecho que puedas obviar temas de diseño que es importante para que la interfaz tenga una cierta armonia.

Mobile Design no es para todos

Esta seccion la quiero usar un poco para desahogarme de mis desventuras mejorando la UI de mi sitio para hacerlo mas compatible con otros vieports fuera del 1920x1080 en el cual empece a pelearme un poco con los media quieries y los distintos viewports ademas que como el diseño original de la pagina viene de un diseño en PenPot (Figma Open Source) ya se entendera que parte del diseño tuvo medidas hardcodeadas lo cual se presto para que fuera mas inflexible de lo que ya de por si era la distribucion principalmente de la landing-page lo cual genero que al intentar visualizarla fuera menos que ilegible, ya despues de cerca de un par de horas peleandome con los distintos viewports de la pagina logre un resultado que me llego a converser.

Lo que no sabia es que mi felicidad duraria poco primero al preguntarle a mi amigo Faber confiado por mi excelente trabajo como psuedo-diseñador, a la hora de abrir la pagina vaya sorpresa la mia se vea sobrepuesto varios de los componentes del mismo, al preguntarle sobre la resolucion de su portatil era efectivamente de 1920x1080 pero tenia el escalado del sistema operativo al 125% lo cual dañaba toda la interfaz de la pagina, pero bueno es algo manejable. Cuando fue a probar en mi telefono todo lo que habia trabajado para que se viera presentable en telefono aparentemente no sirvio de nada por que mi sorpresa al ver la pagina era lo mismo que cuando la vimos en la computadora de faber, la cual fue ver la gran mayoria si no todos los elementos superpuestos.

A lo cual quiero dejar consignado en este blog y futuros que no soy un buen diseñador ni mucho menos.

Con MDX la vida es mas facil

Cuando inicie con el contenido para la pagina todos estos estaban en MarkDown plano la unica configuracion que tenia extra era el syntax highlight que lo configure al codigo el tema monokai para que este vaya mas acorde al estilo de la pagina. Ahora bien a medida que el contenido a travez de blog si hacia mas y mas largo y tenia mas formas de presentacion del mismo, era notorio que el formato en el que mostraba el contenido no es al que me gustaria ver si fuera lector de este mismo; por esto mismo empece a aplicar una series de reglas CSS al blog para que fuera mas amigable visualmente y fuera mas sencillo seguir la estructura del contenido en si.

Ahora bien esto no acababa de convencerme ya que esto no me permitia poder alterar ciertos componentes a los cuales me gustaria agregarle cierta logica como en los links poder diferenciar los que envian a paginas externas de los que hacen parte interna del mismo sitio, o tambien poder agregar ciertos componentes como lo son los iconos de Devicon mismos los cuales uso en el apartado de mi trabajo ya que estos tambien son gestionados por medio de archivos MarkDown tambien a lo cual buscando una manera de poder suplir estos requisitos me encontre con la integracion de Astro y MDX .

Para no hacer muy extensa esta seccion basicamente despues de pelear aproximadamente por 40 minutos con el sistema de collections de Astro para que serialize los MDX pude empezar a denotar temas interesantes como:

Integracion de JSX en MarkDown

Esto me permite poder introducir componentes ajenos al entorno markadown facilmente para poder que mi pagina markdown pueda tener mas interactibilidad o agregar elementos que el MarkDown solo no me permite:

// Permitiendo importar facilmente elementos propios de astro y otros frameworks integrados con Astro
import DevIcon from '../components/mdx/DevIcon.astro';

// usarlo posteriormente como parte del contenido original del documento **MarkDown**
<DevIcon name="python-plain" />

Inyeccion de componentes personalizados a MarkDown

Lo cual permite inyectar componentes existentes como las a o los headings y que estos sean interpretados por un componentes personalizado, de forma sencilla y dinamica como parametro del contenido a la hora de renderizar en el HTML.

---
import Link from '../../components/mdx/Link.astro';

const { Content } = await render(entry);
---

<Content components={{a: Link}} />