CicloUrbano funciona y está probada, pero vive en localhost, con una base de datos que es un fichero JSON y un servidor de desarrollo que jamás debería asomarse a internet. Esta lección cubre el último tramo: convertir el proyecto en un paquete de ficheros estáticos, entender qué se puede y qué no se puede esconder en una aplicación que se ejecuta en el navegador de otra persona, resolver el problema de enrutamiento que hace que /reservas devuelva un 404 en cuanto sale de localhost, desplegarlo, y saber qué vigilar después. Y como es la última lección del curso, cierra también el camino recorrido y señala por dónde seguir.

1. La construcción para producción
2. Revisar el tamaño antes de publicar
3. Variables de entorno: qué es realmente público
4. El 404 al recargar: enrutamiento en cliente sobre un servidor estático
5. Despliegue paso a paso en una plataforma estática
6. La alternativa del contenedor: Docker y Nginx
7. La API en producción: qué falta de verdad
8. Después del despliegue: monitorización y métricas reales
9. Lista de comprobación de lanzamiento
10. Siguientes pasos con este proyecto
11. Cómo seguir aprendiendo

Hasta ahora todo ha ocurrido con npm run dev, donde Vite sirve los módulos sin empaquetar y recarga en caliente. Eso es cómodo para desarrollar y no es lo que se publica. La construcción es otra cosa:

Qué ha hecho, paso a paso:

Ese hash es la pieza que más se malinterpreta. Sirve para poder decirle al servidor «guarda estos ficheros en caché para siempre» sin condenar al usuario a una versión antigua: si el contenido cambia, el nombre cambia, y el navegador lo pide como si fuera un fichero nuevo. La consecuencia práctica es una regla de caché de dos velocidades:

Antes de publicar, se verifica la construcción tal cual, no el servidor de desarrollo:

Es el momento de comprobar tres cosas que solo se ven aquí: que no hay errores en la consola sin los avisos de desarrollo, que los fragmentos perezosos se descargan al navegar (mira la pestaña de red) y que el Suspense de cada ruta muestra su esqueleto y no un salto en blanco.

El informe de arriba ya da la cifra que importa: 87,65 kB comprimidos para el paquete principal. La revisión útil no es «¿es mucho?» en abstracto, sino comparar con el presupuesto que se fijó y localizar quién ocupa qué:

Un desglose típico de este proyecto:

La lección: en una aplicación bien dividida, el peso es casi todo dependencias, y la palanca que queda no es minificar mejor, sino elegir menos bibliotecas. Si el presupuesto se pasa, la conversación es sobre arquitectura, no sobre configuración.

Vite expone al código solo las variables que empiezan por VITE_, y las sustituye en la construcción:

Y ahora la advertencia más importante de esta lección, porque es un error que se comete con frecuencia y tiene consecuencias reales:

Todo lo que pongas en import.meta.env acaba escrito, en texto legible, dentro de los ficheros JavaScript que descarga cualquier persona que visite la web. No es una variable «de servidor»: es una constante que se incrusta en el paquete. Cualquiera puede abrir las herramientas del navegador y leerla.

De ahí se deriva una frontera clara:

Lo que necesite un secreto necesita un servidor que lo guarde y haga la llamada por ti. No hay atajo. Y .env.production no se versiona: en el repositorio va .env.example con las claves y sin los valores, y los valores reales se configuran en la plataforma de despliegue.

Este es el fallo que sorprende a todo el mundo en su primer despliegue de una aplicación de una sola página. En local funciona; desplegado, entrar directamente en https://ciclourbano.example/reservas devuelve un 404.

La razón es que hay dos entidades distintas resolviendo rutas y solo una de ellas conoce las tuyas:

React Router vive dentro del JavaScript que carga index.html. Si el servidor no entrega index.html, no hay React, no hay Router y no hay ruta. La solución es siempre la misma idea —devolver index.html para cualquier ruta que no sea un fichero real— con una sintaxis distinta en cada plataforma:

Fíjate en el detalle del código 200 en Netlify: es una reescritura, no una redirección. La URL que ve el usuario sigue siendo /reservas, que es justo lo que React Router necesita leer. Con un 301 o un 302 la URL cambiaría a / y el usuario acabaría en el catálogo.

Y la comprobación que nunca hay que saltarse tras desplegar: abrir una ruta profunda en una pestaña nueva y recargarla. Navegar hasta ella desde el inicio no prueba nada, porque ese camino nunca toca el servidor.

El proyecto son ficheros estáticos, así que casi cualquier alojamiento sirve. Con una plataforma conectada al repositorio, el despliegue queda automatizado:

Paso 1. Sube el proyecto a un repositorio remoto (GitHub, GitLab). El flujo de trabajo de CI escrito en la lección anterior empieza a ejecutarse en cada cambio.

Paso 2. Conecta el repositorio en la plataforma y configura la construcción:

Paso 3. Añade las variables de entorno en el panel de la plataforma: VITE_API_URL con la URL real de la API y VITE_ENTORNO=produccion. Nunca en el repositorio.

Paso 4. Añade el fichero de reescritura de la sección anterior. Sin él, el despliegue «funciona» hasta que alguien comparte un enlace.

Paso 5. Despliega y comprueba, en este orden: la portada carga; una ruta profunda recargada en pestaña nueva funciona; el catálogo trae datos de la API real; una ruta inexistente muestra tu página de no encontrado; el panel de taller sigue vedado a un cliente; y la consola está limpia.

Paso 6. Activa los despliegues de vista previa por rama. Cada rama y cada solicitud de cambios obtiene su propia URL temporal, así que las revisiones dejan de ser «confía en mí» y pasan a ser «pruébalo aquí». Es, con diferencia, la función que más cambia la forma de trabajar en equipo.

Si el despliegue va a la infraestructura propia de la empresa, la forma equivalente es una imagen que construye y sirve:

Dos detalles que conviene entender. El primero es que la construcción de dos etapas deja una imagen final de unos pocos megabytes: Node solo existe mientras se construye. El segundo es el ARG VITE_API_URL: como las variables se incrustan en la construcción, una imagen construida apunta a una API concreta. No puedes cambiarla al arrancar el contenedor. Si necesitas una imagen que sirva a varios entornos, la URL debe leerse en tiempo de ejecución (por ejemplo, de un /configuracion.json que se pide al arrancar la aplicación).

Hay que decirlo sin adornos: json-server es una herramienta de desarrollo. Acepta cualquier escritura de cualquiera, no tiene autenticación, no valida nada y guarda los datos en un fichero. Desplegarlo con datos reales sería un incidente de seguridad, no un despliegue.

Lo que hace falta detrás de una aplicación como esta:

Vale la pena releer con esta luz lo que se dijo en Rutas Protegidas: RutaProtegida y RequiereRol mejoran la experiencia y no protegen nada. Cualquiera puede abrir las herramientas del navegador, modificar el estado de la sesión y ver la pantalla del taller. Lo que impide que haga daño no es tu componente: es el servidor rechazando la petición.

Un último aviso de sensatez profesional: en cuanto haya datos de personas reales de por medio —nombres, correos, ubicaciones, pagos— el diseño de autenticación, almacenamiento y permisos debe revisarlo alguien con experiencia en seguridad y protección de datos antes de exponerlo al público. Todo el dominio de este curso es ficticio precisamente para poder aprender sin ese riesgo.

Publicar no es terminar. En producción hay navegadores, redes y personas que no estaban en tu portátil, y hay dos preguntas que solo se responden con datos de allí.

¿Está fallando algo? El registrarError de src/utilidades/monitorizacion.js lleva todo el curso siendo un console.error. Ahora es cuando conecta con un servicio de verdad:

Ese enganche ya está puesto donde tenía que estar: el componentDidCatch del LimiteDeError que se escribió en Límites de Error. El valor de haberlo previsto entonces se cobra ahora.

¿Va rápida para la gente de verdad? Las mediciones del Profiler se hicieron en un portátil con buena red. Las métricas de usuarios reales se recogen en el propio navegador y se envían:

Y hace falta una tercera cosa que no es técnica: un canal de vuelta. Un enlace visible para informar de un problema, y alguien que lo lea. La mayoría de los fallos que importan los cuenta una persona antes de que ninguna métrica los delate.

El punto que más se olvida y más duele es el plan de reversión. Antes de publicar, hay que saber cómo se vuelve a la versión anterior y cuánto tarda. Las plataformas conectadas al repositorio lo dan hecho con un botón; con contenedores, es volver a desplegar la etiqueta anterior. Averígualo antes de necesitarlo.

CicloUrbano está viva y tiene una hoja de ruta natural, toda ella apoyada en lo que ya sabes:

El mejor consejo para elegir es el mismo que ordenó el proyecto desde el principio: incrementos verticales. Una mejora completa, de la interfaz a la prueba, antes de empezar la siguiente.

• La documentación oficial de React es, hoy, excelente. Sus páginas sobre «no necesitas un efecto» y sobre cómo estructurar el estado explican mejor que ningún tutorial por qué las cosas son como son. Vuelve a ellas con la experiencia que ya tienes: se leen distintas.
• Lee el código de las bibliotecas que usas. React Router, Redux Toolkit y TanStack Query son legibles y están bien escritas. Entender cómo resuelven un problema enseña más que cualquier curso, incluido este.
• Escribe tu propia versión reducida de algo que uses: un useQuery mínimo con caché, un enrutador de cincuenta líneas. Nada consolida un modelo mental como reimplementarlo.
• Reproduce los fallos que te encuentres en un ejemplo mínimo antes de pedir ayuda. La mitad de las veces se resuelven en el intento, y la otra mitad recibes una respuesta mucho mejor.
• Contribuye. Empieza por documentación y por reproducir incidencias; es la puerta de entrada más honesta a un proyecto de código abierto.
• Mantén el escepticismo con lo nuevo. El ecosistema de React se mueve rápido y no todo lo que aparece sobrevive. La forma de distinguir la moda de la mejora es preguntarse qué problema concreto resuelve y si tú lo tienes.

• Desplegar sin la regla de reescritura. La aplicación parece funcionar hasta que alguien recarga o comparte un enlace. Comprueba siempre una ruta profunda en pestaña nueva.
• Poner un secreto en una variable VITE_. Queda en texto legible en el paquete. Si algo debe ser secreto, necesita un servidor.
• Cachear index.html durante mucho tiempo. Los usuarios se quedan clavados en la versión anterior aunque los assets nuevos ya estén publicados. index.html sin caché, assets con hash y caché larga.
• Confiar en RutaProtegida como seguridad. Es experiencia de usuario. La autorización se comprueba en el servidor, en cada endpoint, siempre.
• Probar el rendimiento en el servidor de desarrollo. Los números no se parecen a los de producción. Mide sobre npm run preview o sobre el despliegue real.
• Desplegar un viernes por la tarde sin plan de reversión. No es una broma: si no sabes cómo volver atrás y cuánto tarda, no estás listo para publicar.
• Consejo final: automatiza el despliegue el mismo día que hagas el primero a mano. Un despliegue que requiere recordar pasos es un despliegue que alguien hará mal.

Ejercicio 1. Despliega CicloUrbano en una plataforma estática con la reescritura correcta y las cabeceras de caché de la sección 1. Documenta en el README.md el procedimiento y el plan de reversión, y verifica con grep sobre dist/ que no se ha colado ningún secreto.

Ejercicio 2. Prepara el proyecto para servirse desde una subruta (https://ejemplo.example/ciclourbano/) en lugar de la raíz del dominio. Averigua qué hay que cambiar en Vite, en React Router y en la configuración del servidor.

Ejercicio 3. Añade al flujo de integración continua un paso que falle la construcción si el paquete principal supera un presupuesto de 100 kB comprimidos, para que el tamaño no se degrade sin que nadie se entere.

Solución 1.

En el README.md:

Solución 2. Hay que tocar tres sitios, y olvidarse de cualquiera de ellos produce una pantalla en blanco o enlaces rotos:

Comprobación: dist/index.html debe referenciar /ciclourbano/assets/..., y una recarga en /ciclourbano/reservas debe funcionar. Los enlaces internos con <Link to="/reservas"> siguen escribiéndose sin el prefijo: lo añade el basename.

Solución 3.

La clave es el process.exit(1): sin él, el script informa pero la integración continua sigue en verde y el presupuesto se convierte en una sugerencia que nadie atiende.

Empezaste este curso con un <div id="root"> vacío y la pregunta de por qué alguien necesitaría una biblioteca para pintar una lista de bicicletas. Acabas con una aplicación completa, probada en cuatro niveles, medida, dividida en fragmentos, accesible y desplegada, y con criterio propio para decidir cómo construir la siguiente.

El camino ha sido este. En los fundamentos entendiste que React es declarativo y que la interfaz es una función del estado, y viste qué ocurre de verdad entre un cambio de estado y un píxel en la pantalla. Con los componentes, las props y el estado aprendiste a delimitar piezas y a parametrizarlas, y con los eventos, los formularios y la accesibilidad hiciste que respondieran a personas, no solo a datos. En los conceptos avanzados apareció la disciplina: elevar el estado al ancestro común, componer en lugar de heredar, y capturar los fallos antes de que se coman la pantalla. Los hooks te dieron el vocabulario completo —estado, sincronización con el exterior, referencias, contexto, reductores— y, sobre todo, la capacidad de extraer tu propia lógica reutilizable. React Router convirtió una pantalla en una aplicación con URLs compartibles y accesos controlados. La gestión del estado puso orden en el caos con una idea que vale más que cualquier biblioteca: cada dato tiene un sitio donde debe vivir, y los datos del servidor no son tuyos. El rendimiento te enseñó a medir antes de tocar y a no confundir optimización con decoración. Las pruebas te dieron la libertad de refactorizar sin miedo, probando comportamiento y no implementación. Los temas avanzados ampliaron el mapa hasta el servidor, los tipos y el móvil. Y el proyecto demostró que todo eso encaja.

Lo que te llevas no es una lista de APIs, que cambiarán. Es la forma de pensar que hay debajo: describir la interfaz en función del estado, poner cada dato en su sitio, medir antes de optimizar, probar el comportamiento visible, y no confiar nunca en el cliente para lo que debe garantizar el servidor. Eso sigue siendo cierto cuando cambia la versión, la biblioteca de moda o el framework entero.

Ya tienes lo que hace falta. Construye algo.