Configuración entre dominios de solicitud de datos de microaplicaciones vue3.0
Actualmente existe una única aplicación desarrollada con vue2.6. Esperamos utilizar qiankun para convertir esta aplicación en una estructura de microaplicación.
Utilice vue3.0 para reconstruir algunas funciones mientras garantiza que las funciones originales estén disponibles.
Aquí hay un registro de cómo configurar el proxy de solicitud de datos de cada aplicación cuando se usa vue para el desarrollo de microaplicaciones.
Sabemos que, en general, si usa vue de forma independiente para desarrollar una única En la aplicación, puede configurar vue. {devServer: proxy} de config.js para implementar el proxy de solicitud de interfaz.
En el desarrollo de microaplicaciones, la situación es ligeramente diferente. Las situaciones específicas se pueden dividir en las siguientes situaciones:
El problema actual es que cuando la base y las subaplicaciones configuran servicios proxy de forma independiente, es normal que cada una desarrolle datos de solicitud de forma independiente.
Y después de que la subaplicación se cargue en la base, la solicitud de datos de la subaplicación será 404.
Versión base vue2.6.12,
A primera vista, no hay diferencia entre la configuración de proxy y la configuración singleton en la microaplicación. El proxy se basa en la configuración de vue.config.js o en la configuración del proxy del paquete web. La razón por la cual la subaplicación aquí puede solicitar datos normalmente, ya sea que se desarrolle de forma independiente o se cargue en la base para la depuración conjunta, es porque tanto la base como la subaplicación. están configurados con el mismo encabezado de proxy/proxyApi y solicitan que la dirección del servicio sea consistente
Aquí viene la pregunta, si la base y la subaplicación están configuradas de forma independiente, por ejemplo:
La dirección de solicitud cuando la subaplicación se desarrolla de forma independiente: /usuario
Cuando la subaplicación está anidada en la base, la dirección será: localhost: 9000/usuario
Usted Puede ver que la dirección de solicitud ha cambiado. La dirección /usuario original puede pasar el servidor webpack cuando se desarrolla de forma independiente. Se utiliza como un proxy normal.
En el microservicio, la dirección /usuario se transfiere al. Servicio de desarrollo local de la base localhost: 9000/user. El servicio de desarrollo no puede reconocer esta dirección de solicitud y, naturalmente, devuelve 404.
Entonces sincronizamos el encabezado del proxy de la subaplicación con la base, para que la solicitud de la base. La subaplicación se reenviará por proxy a través del servicio de desarrollo de la base. La razón por la que configuramos el mismo encabezado de proxy no es para configurar la subaplicación nuevamente en la base. Debería ser un proxy, también para facilitar la configuración. y seguir el principio de convención sobre configuración.
La URL base solicitada por el método anterior es la primera dirección de solicitud. De hecho, también podemos configurar directamente la dirección de solicitud completa.
Por ejemplo: axios.create({ baseURL: ' ' })
De esta manera, la dirección de solicitud de la subaplicación no se reescribirá y no se producirá 404 .