Agylo

TL;DR

agylo fue mi proyecto final de grado en Desarrollo de Aplicaciones Web (CIPFP Ausiàs March). Es una aplicación de gestión de tareas y proyectos con tableros kanban, pensada para que varios usuarios puedan colaborar, asignar tareas, compartir archivos y ver la actividad reciente del equipo.

Lo importante del proyecto no fue “hacer un Trello”. Fue aprender a construir una aplicación full stack real con tipado end-to-end, autenticación, base de datos relacional y despliegue continuo, todo desde cero.

El contexto: proyecto de final de grado

Cuando tuve que elegir proyecto final, quería algo que me obligara a tocar todas las capas de una aplicación web moderna: frontend reactivo, backend con API tipada, base de datos, autenticación y despliegue.

No me interesaba hacer un CRUD básico con el que aprobar y olvidar. Quería un proyecto que me sirviera de referencia técnica real después de graduarme.

Un gestor de proyectos con kanban cumplía eso: tiene estado complejo en frontend, relaciones no triviales en base de datos, colaboración multiusuario y necesidad de una UX fluida.

Demo de la pizarra kanban

Por qué T3 Stack

Después de evaluar opciones, me decanté por T3 Stack (Next.js + tRPC + Prisma + TailwindCSS + NextAuth.js). Las razones fueron prácticas:

• Tipado end-to-end con tRPC: el contrato entre frontend y backend se valida en tiempo de compilación. Eso elimina una clase entera de bugs que en REST convencional solo descubres en runtime.
• Prisma como ORM: schema declarativo, migraciones claras y autocompletado real de queries.
• NextAuth.js: autenticación con proveedores externos (GitHub, Google) sin reinventar la rueda.
• Next.js: SSR/SSG donde conviene, API routes integradas y despliegue directo en Vercel.

La apuesta era que la productividad del stack compensaría la curva de aprendizaje. Y así fue.

Qué hace la aplicación

Funcionalidades principales

• Crear proyectos y tableros kanban.
• Crear, asignar y mover tareas entre columnas (drag & drop).
• Colaboración: invitar miembros, ver actividad reciente del equipo.
• Compartir archivos dentro de los proyectos.
• Autenticación con proveedores OAuth (GitHub, Google).
• Interfaz responsive con TailwindCSS.

Vista global con todas las tareas asignadas al usuario

Lo que no hace (y por qué)

• No hay notificaciones en tiempo real (WebSockets). La complejidad operativa no justificaba el alcance del TFG.
• No hay roles (admin/editor/viewer). Solo miembro o no miembro.
• No hay búsqueda avanzada ni filtros complejos sobre tareas.
• No hay tests automatizados. Es la deuda técnica más evidente y la que más me ha molestado en retrospectiva.

Arquitectura y decisiones técnicas

tRPC como capa de comunicación

La decisión más diferenciadora del proyecto. En vez de definir endpoints REST y luego tipar manualmente las respuestas en el cliente, tRPC genera el contrato automáticamente desde el servidor.

Eso significa que si cambio el tipo de retorno de un procedimiento en el backend, el frontend rompe en compilación, no en producción. Para un proyecto de una persona, eso fue un multiplicador de velocidad enorme.

Prisma + PlanetScale

PlanetScale me daba MySQL serverless con branching de esquema (similar a ramas de git para la base de datos). Eso me permitía iterar rápido en el modelo de datos sin miedo a romper la base de producción.

El schema de Prisma cubría las relaciones principales: usuarios, proyectos, tableros, columnas, tareas y membresías.

Drag & drop en el kanban

Implementar drag & drop que se sintiera natural no fue trivial. Tuve que gestionar:

• Reordenación dentro de la misma columna.
• Movimiento entre columnas con actualización de posiciones.
• Persistencia optimista: actualizar la UI antes de confirmar con el servidor para que la experiencia no se sintiera lenta.

Las carreras entre el estado local y la respuesta del servidor fueron el punto más frágil de toda la aplicación.

Despliegue en Vercel

El despliegue fue directo: push a main, Vercel construye y despliega. Sin infra que mantener, sin Docker, sin CI/CD manual.

Para un TFG, esa simplicidad fue una ventaja enorme. Me dejó enfocarme en el producto y no en la operación.

Dónde costó más

Estado del kanban

Mantener sincronizado el orden de las tareas entre lo que ve el usuario y lo que persiste en base de datos fue el reto más complicado. Las operaciones de reordenación generan múltiples updates que deben ser atómicas, y si el servidor falla a mitad, la UI queda inconsistente.

Modelo de datos relacional

Diseñar las relaciones entre proyectos, tableros, columnas, tareas y usuarios de forma que las queries fueran eficientes pero el schema no se volviera rígido fue un ejercicio constante de trade-offs.

Dashboard principal

Construir el dashboard principal con toda la información del proyecto fue otro punto que costó bastante. Agregar en una sola vista los datos relevantes (tareas asignadas, actividad reciente, miembros, estadísticas del proyecto) implicaba múltiples queries coordinadas y un layout que no se sintiera saturado. Conseguir que la carga fuera rápida y la información estuviera bien jerarquizada requirió varias iteraciones.

Vista del dashboard principal

Curva del T3 Stack

Aprender Next.js, tRPC, Prisma y NextAuth.js al mismo tiempo fue intenso. Cada pieza por separado era asumible, pero integrarlas todas con tipado coherente requirió entender cómo fluyen los tipos desde el schema de Prisma hasta el componente React.

Límites del proyecto

Lo que me llevo del proyecto

1. El tipado end-to-end cambia las reglas del juego. Trabajar con tRPC me demostró que la mayoría de bugs de integración frontend/backend son evitables si el contrato se valida en compilación.
2. Un proyecto final ambicioso enseña más que tres sencillos. Tocar autenticación, estado complejo, base de datos relacional y despliegue en un solo proyecto me forzó a entender cómo se conectan las piezas.
3. El drag & drop es más difícil de lo que parece. La parte visual es la más sencilla. La persistencia de estado y la reconciliación optimista son el reto real.
4. La deuda técnica se nota rápido. No haber escrito tests desde el principio me hizo perder tiempo depurando regresiones que podría haber detectado automáticamente.

Cierre personal

agylo fue el proyecto que me hizo pasar de “sé un poco de React” a “entiendo cómo funciona una aplicación web moderna de verdad”. Tocar todas las capas, pelearme con el estado, diseñar un modelo de datos y desplegar algo funcional me dio una base técnica que sigo usando hoy.

Si tuviera que rehacerlo, cambiaría dos cosas: tests desde el día uno y WebSockets para colaboración en tiempo real. Pero como primer proyecto full stack serio, cumplió su objetivo con creces.