Resumen

Configurar un proyecto moderno que separe frontend y backend dentro de un mismo repositorio es una estrategia cada vez más utilizada en producción. Aquí se explica paso a paso cómo estructurar un monorepo, conectarlo a Cloudflare Workers y desplegar dos aplicaciones independientes desde un único repositorio de GitHub, todo acelerado con asistencia de código por IA.

¿Cómo se estructura un monorepo para frontend y backend?

El proyecto se llama Waitlist y su objetivo es recopilar correos electrónicos de personas interesadas en el lanzamiento de un curso. La arquitectura parte de un monorepo, es decir, un único repositorio que contiene dos carpetas principales: una para el frontend y otra para el backend [0:28].

La razón de separar ambas aplicaciones, aunque podrían vivir juntas, es que cada una funciona como una instancia de ejecución independiente con su propia configuración. Esto permite:

  • Escalar cada parte por separado.
  • Aplicar configuraciones de build y deploy distintas.
  • Mantener claridad en la organización del código.

Para acelerar la creación del proyecto se utilizó un prompt preconfigurado ejecutado en Claude Code [0:18]. El asistente generó la estructura completa: el package.json raíz, la carpeta de backend con un primer servicio waitlist.ts que recibe un email y registra la fecha, y la carpeta de frontend construida con React y Vite [1:28].

¿Qué archivos wrangler se generaron?

Cada aplicación tiene su propio archivo wrangler, que es el archivo de configuración que Cloudflare Workers utiliza para identificar y desplegar cada worker. Los nombres asignados fueron waitlist-frontend y waitlist-api [2:06]. Estos nombres deben coincidir con los que se configuren en el dashboard de Cloudflare.

¿Qué incluye el backend generado?

El servicio inicial del API incluye un endpoint de waitlist con validaciones básicas y un middleware de CORS [1:50]. También se dejó un comentario to-do para reemplazar el almacenamiento temporal por una base de datos como D1, el servicio de base de datos SQL de Cloudflare [1:38].

¿Cómo conectar un mismo repositorio a dos workers en Cloudflare?

Este es el punto clave del despliegue. Desde el dashboard de Cloudflare, se crean dos aplicaciones apuntando al mismo repositorio de GitHub [2:50]. El truco está en la configuración del path dentro de las opciones avanzadas.

  • Para el frontend, el path se establece como frontend.
  • Para el backend, el path se establece como backend.

Cloudflare autodetecta los frameworks utilizados y sugiere configuraciones, pero es fundamental verificar que el nombre de cada aplicación coincida con el definido en los archivos wrangler [3:20].

Si algo no funciona correctamente después de la creación, siempre se puede editar desde la sección de Build en el dashboard. Allí es posible cambiar la rama principal, habilitar preview builds para pull requests que aún no están en main, y modificar los comandos de compilación [3:42].

Una diferencia importante: el backend no requiere comando de compilación (build command), mientras que el frontend sí necesita ejecutar vite build definido en su package.json [4:18].

¿Cómo configurar variables de entorno en Cloudflare Workers?

Al desplegar por primera vez, el frontend no sabe hacia dónde enviar las peticiones porque falta la variable de entorno que indica la URL del API [4:50]. Cloudflare distingue dos tipos de variables:

  • Variables de runtime: se usan en el servidor, por ejemplo, claves de APIs externas como OpenAI, Amazon o Azure. Se configuran en el primer apartado del dashboard [5:08].
  • Variables de tiempo de compilación: comunes en proyectos de frontend. Se agregan en un apartado separado y son las que frameworks como Vite necesitan durante el build [5:28].

En este caso se agregó VITE_API_URL con la URL del worker del backend [5:38]. Después de añadir la variable, es necesario recompilar la aplicación, ya sea enviando un nuevo commit o utilizando el botón Retry Build en la sección de Deployments [5:52].

Tras la recompilación, el formulario de registro envía correctamente el correo al endpoint del API, y en las herramientas de desarrollo se puede verificar el host waitlist-api junto con el payload enviado y el response recibido [6:10].

Con esta configuración inicial completa, el siguiente paso será trabajar con secretos, routing, bindings y la integración con Hono sobre el ecosistema de Cloudflare. Si estás construyendo tu propio proyecto, adapta el prompt y los paths a tus necesidades y comparte tu experiencia en los comentarios.