Cómo elegimos las herramientas del stack de chiseli
Una mirada a las decisiones de tecnología que tomamos para mantener chiseli rápido, barato y fácil de operar.
Cuando empezamos chiseli nos hicimos la misma pregunta que cualquier fundador técnico: ¿en qué lo construimos? Acá está la respuesta corta y, al final, la larga.
La respuesta corta
- Cloudflare Workers para la API y los servicios en el edge.
- Astro para los sitios de marketing y documentación.
- D1 (SQLite en el edge) como base de datos principal.
- R2 para archivos y backups.
- Workers AI cuando necesitamos embeddings o clasificación ligera.
Por qué edge primero
Latencia. Un acortador de links que tarda 200 ms en redirigir no sirve. Una página de analytics que tarda 2 s en cargar no se usa. Correr todo en el edge significa que un usuario en Tokio y otro en Bogotá obtienen respuestas en menos de 50 ms.
Además, edge significa pagar por request real, no por “instancia reservada 24/7”. Para productos en etapa temprana eso es la diferencia entre poder experimentar y tener que pedir inversión cada vez que se prende una feature.
Por qué Astro
Necesitábamos sitios de marketing rápidos, con buen SEO, soporte para markdown y la opción de meter componentes interactivos sólo donde hicieran falta. Astro cumple las cuatro sin obligarnos a usar JavaScript en cada página.
Este mismo blog, por ejemplo, se renderiza estático en build time y se sirve desde el CDN. Cero JS en el cliente, salvo lo que elijas meter.
Lo que NO usamos (y por qué)
- Kubernetes. No lo necesitamos. Workers escala solo.
- Un monolito en Node. Cada producto es un Worker independiente, comparte schemas vía una lib común.
- Cookies y tracking de terceros. Por diseño. Cero cookies = cero banner.
Lo que viene
En el próximo post vamos a contar la arquitectura de Repath en detalle: cómo manejamos los redirects en el edge sin que se dispare la latencia cuando un link se vuelve viral.