Cuando React conoció a Flask - Episodio 43

Hay momentos en el desarrollo que no se miden en líneas de código, sino en latidos.
Después de muchos intentos de levantar servidores, peleando con puertos y configurando proxys, ver que tu frontend y tu backend se hablan por fin… es casi romántico.
Por eso hoy bautizo este momento como:
"El día que el frontend y el backend empezaron a hablar sin gritarse por CORS"
El día que el frontend y el backend empezaron a hablar sin gritarse por CORS - Diario de un SaaS
Hasta este punto, React vivía en su mundo: localhost:3001.
Flask, por su parte, respondía felizmente en el 5001, detrás del firewall y protegido por Plesk.
Ambos funcionaban bien por separado, pero no se conocían.
Era como tener dos mitades de un sistema que aún no se habían visto las caras.
El reto:
Unirlos bajo un mismo dominio, con HTTPS y sin dolores de cabeza por CORS.
(CORS: significa Cross Origin Resource Sharing. Se trata de un mecanismo de seguridad de los navegadores que controla qué sitios web pueden hacer peticiones al servidor.
En pocas palabras CORS es el portero del edificio Web que solo deja pasar las visitas si el dueño del piso las autoriza.)
Nada de configuraciones temporales, ni proxys locales, ni puertos abiertos.
Querías algo sólido.
De producción.
Desafíos encontrados
- React seguía llamando a
http://localhost:5001, lo cual ya no existía. - Plesk servía su 404 predeterminado (un clásico).
- El firewall bloqueaba cualquier intento externo de conexión directa.
- Flask funcionaba, pero el proxy de Apache no estaba reencaminando las peticiones HTTPS correctamente.
Cada test con curl era una mezcla de esperanza y decepción.
Un 404, un timeout, otro 404… hasta que todo empezó a encajar.
Solución
El cambio clave fue simple pero poderoso:
Configurar Apache dentro de Plesk como proxy inverso hacia Flask.
ProxyPass / http://127.0.0.1:5001/
ProxyPassReverse / http://127.0.0.1:5001/
Y duplicar esas directivas tanto para HTTP como para HTTPS.
Una vez aplicadas, Plesk redirigía automáticamente todas las peticiones entrantes del dominio xyz.net hacia Flask, de forma segura y transparente.
Después, cerramos el puerto 5001 al exterior.
Solo Apache puede acceder ahora al backend interno.
Seguridad total, misma fluidez.
Momento Eureka
Fue instantáneo.
Un nuevo curl https://masquerelojes.net/health devolvió un HTTP 200 OK con el esperado JSON:
{"status":"ok","database":true}
React por fin podía llamar al backend con una simple línea:
const API_URL = "https://masquerelojes.net";
Sin proxys locales, sin errores de CORS.
Todo fluía.
Lecciones aprendidas
- Flask y React se entienden mucho mejor cuando hablan el mismo idioma (HTTPS).
- Apache o NGINX son los traductores perfectos si los configuras bien.
- Cerrar puertos una vez que el proxy funciona es clave para la seguridad.
- Y sobre todo: cuando algo deja de devolver 404 y responde con un 200… se siente como un milagro.
Próximos pasos
- Implementar autenticación completa con JWT en el flujo React → Flask.
- Empezar las pruebas reales de
/register,/loginy/parts. - Añadir Fail2Ban y ModSecurity en Plesk otra vez.
- Documentar logs y monitoreo de rendimiento.
Cierre / Reflexión
Hoy React y Flask ya no viven en mundos separados.
Hoy comparten dominio, protocolo y propósito.En definitiva, hoy mi SaaS habla con el mundo.
Si quieres conocer otros artículos parecidos a Cuando React conoció a Flask - Episodio 43 puedes visitar la categoría Proyecto-IA.

Deja una respuesta