![Distribución en la nube con la aplicación React y la aplicación WordPress alojadas en el mismo dominio: ¿cómo hacer que los navegadores con la aplicación React se almacenen en caché para representar la aplicación WordPress?](https://rvso.com/image/769274/Distribuci%C3%B3n%20en%20la%20nube%20con%20la%20aplicaci%C3%B3n%20React%20y%20la%20aplicaci%C3%B3n%20WordPress%20alojadas%20en%20el%20mismo%20dominio%3A%20%C2%BFc%C3%B3mo%20hacer%20que%20los%20navegadores%20con%20la%20aplicaci%C3%B3n%20React%20se%20almacenen%20en%20cach%C3%A9%20para%20representar%20la%20aplicaci%C3%B3n%20WordPress%3F.png)
Tengo un dominio que aloja un sitio web de reacción en un depósito s3 a través de Cloudfront. También hay un sitio de WordPress alojado en un subdominio de ese dominio, y en la distribución de la nube para la aplicación web, tengo dos comportamientos configurados con patrones de ruta en
y en/*
que están configurados con el subdominio de WordPress como origen.
Esta configuración parece funcionar cuando se visitan en/*
rutas en modo incógnito y en navegadores que nunca han visitado el dominio principal. Sin embargo, en un navegador que ha visitado el dominio antes, el navegador muestra la aplicación de reacción en lugar de la página de WordPress. Hacer un caché vacío y una recarga completa hace que se muestre la página de WordPress, pero después de otra actualización se vuelve a representar la aplicación web. Esto sucede de manera muy consistente.
Cuando la aplicación de reacción se representa en una URL que debería representar la aplicación de WordPress, aparece el siguiente encabezado de respuesta:
x-cache: RefreshHit from cloudfront
Además, si bien un navegador que nunca ha visitado la aplicación de reacción cargará correctamente la aplicación de WordPress cuando visite una ruta que comienza con /en
, una vez que ese navegador haya visitado la aplicación de reacción, las rutas que comienzan con /en
ya no representan la aplicación de WordPress.
Qué está pasando aquí? ¿Y hay alguna manera de lograr que represente la aplicación de WordPress de manera consistente sin que los usuarios tengan que borrar completamente el caché de su navegador? ¿Hay alguna manera de borrar el elemento de caché relevante usando javascript para poder hacerlo desde la aplicación de reacción cuando detecte que está en una de esas rutas?
Respuesta1
Resultó que el problema no estaba relacionado con mi configuración de Cloudfront o s3 y, en cambio, se debió a que el trabajador de servicio iniciado por la aplicación de reacción interceptó todas las solicitudes al dominio una vez que se inició. Eliminar el trabajador de servicio (lo cual pude hacer porque ya no es necesario) resolvió el problema.