Creando un Proxy en Angular para conectarte a un API local y de producción

Aprende cómo configurar un Proxy local para Angular y evitar problemas con CORS o simplemente conectarte a un API local

Cuando estamos trabajando en staging normalmente nos toca conectarnos entre puertos en local para nuestra API o servicio de backend y Angular en el Frontend. Y muchos pensaremos, bueno, ¿pero estamos en local no debería haber problema o sí?.

Pues sí hay, y hay 3 opciones: Nuestra primer opción es tener un servidor de desarrollo donde detrás de un proxy como Nginx corra nuestro ambiente de desarrollo de Angular y nuestro API sobre el mismo dominio. Otra opción es que corremos todo en local y abrimos CORS en nuestro API a nivel local / staging / desarrollo y en producción lo cerramos o la última opción dejamos ambos en local y abrimos un Proxy con Angular para que conecte sin problemas.

Esto suena bastante complicado pero para serte sincero, no lo es. En este tutorial veremos cómo hacerlo para que cuando estemos en producción se conecte directamente a la URL final y no haga este salto.

Empecemos a configurar…

Lo primero es que como siempre ya tenemos nuestras dos cosas listas, es decir, nuestra app de Angular a la cual aplicar el Proxy y nuestro Backend listo para empezar a dar información al front.

No voy a explicar qué onda con el back ni tampoco iremos a fondo de cómo funciona el Proxy, eso se los dejo de tarea, la cuestión aquí será explicar cómo configurarlo.

Lo primero es abrir nuestro archivo environment.ts y environment.prod.ts ambos se encuentran dentro de la carpeta src/environments . Una vez ahí vamos a editar los dos, en ambos dentro del objeto environment hay que agregar un índice llamado apiUrl para el caso de environment.ts:

export const environment = {
  production: false,
  apiUrl: 'api/v1'
};

Para el caso de environment.prod.ts :

export const environment = {
  production: true,
  apiUrl: 'http://ejemplo.com/api/v1'
};

¿En qué se diferencia?. El primero será llamado en desarrollo y el segundo en producción, por lo que en automático mientras trabajamos en local vs en producción hará el switch entre las URLs. La primera se conectará a local y hará el proxy, puedes ponerle la ruta aparente a la que conectará, básicamente api/v1 en este caso se le hará un append a la URL que configuraremos posteriormente.

Ahora, en el root de nuestra aplicación, ahí donde está el package.json vamos a crear un archivo llamado proxy.conf.json con el contenido:

{
  "/api/*": {
    "target": "http://localhost:8000",
    "secure": false,
    "logLevel": "debug",
    "changeOrigin": true
  }
}

¿Qué hace esto?. Bueno, cuando detecte api en la request HTTP que hará Angular, se va a interceptar, se hará el switch y se dará el append a la URL quedando por ejemplo:

api/v1/users -> http://localhost:8000/api/v1/users

En este caso uso el /api/* como un comodín ya que puedo conectarme tanto a api/v1 como api/v2 en mi caso en los environments dejo v1 ya que por ahora no tengo una v2 del API pero, ustedes pueden dejarlo solo como api/ o incluso forzarlo en la configuración dejando /api/v1/* recuerden que el * es un comodín que hará match con cualquier cosa después de lo anterior.

Ahora bien, secure solamente nos permite saber si hará una conexión segura (HTTPS para los amigos), el logLevel nos permitirá ver en consola las requests para depuración y saber a dónde están aventando las cosas y el changeOrigin es una configuración que aquí anexo pero en localhost no sería necesaria realmente, ¿qué hace entonces?, básicamente nos cambia el origen de las peticiones, por ejemplo de localhost a miurl.com y entonces con esta configuración podemos indicarle esa situación que haremos el cambio de origen. Este lo anexo como menciono por si te es útil, si sigues en local y lo quieres dejar, no te preocupes, el proxy funcionará.

Ya casi está…

¿Qué más nos falta?. Pues arrancar nuestro servicio para que siempre use el proxy a la hora de iniciar a desarrollar.

Para eso abrimos nuestro package.json y modificamos el comando start :

{
  ...
  "scripts": {
    ...
    "start": "ng serve -o --proxy-config proxy.conf.json",
    ...
  },
  ...
}

¿Qué hace aquí?, bueno en este caso agrego dos flags/banderas/opciones o como les conozcas:

-o hará que cuando ejecutemos el comando abra la pestaña en automático (nos ahorramos como 3 segundos valiosos en nuestra vida :D) y por supuesto la configuración del proxy cargada.

Ya solo que iniciemos a trabajar deberemos ejecutar npm start en vez del ng serve (que creo que la mayoría de nosotros iniciamos con npm start ).

Conclusión

Yo en lo personal siempre recomiendo tratar de tener los ambientes separados entre desarrollo, pruebas y producción, pruebas ya sería un ambiente con Angular compilado + el API (o el back) como si fuera producción después de pasar los tests y demás pero hacerle ya pruebas más manuales y reales, por ello es que Staging casi siempre lo mejor es tenerlo todo en local y el Proxy será una gran herramienta para evitar que dejes el CORS abierto y luego lo mandes a producción y sin querer termines con 103,463 correos de contacto spam de alguien que se le ocurrió hacerle unos requests para molestarte (historia real con los números reales).

¿Cuál es tu reacción?
+1
0
+1
0
+1
0
+1
0
+1
1
Total
0
Shares
Publicación anterior

Usando APP_INITIALIZER en Angular

Siguiente Publicación

Categorizando textos con inteligencia artificial en NodeJS

Publicaciones Relacionadas