Effective collaboration between frontend and backend services in distributed architectures requires careful configuration of request routing, especially when switching between local development, staging, and production environments. This guide outlines three common deployment scenarios using Vue.js, Spring Cloud Gateway, Kubernetes, and Nginx, focusing on how to properly proxy API requests to ensure seamless communication without exposing internal service topology.

In all cases, the frontend communicates through a unified API entry point: /api/{service-name}. The goal is to strip away two layers of routing: first, the /api prefix from the frontend’s request; second, the gateway’s routing layer, which directs the request to the appropriate microservice.

Scenario 1: Local Frontend + Local Backend

During local development, the frontend runs on localhost:8080, and the backend API service listens on localhost:8034. To avoid CORS issues and simplify API calls, the Vue.js dev server proxies all requests starting with /api to the local backend, stripping the prefix before forwarding.

Configure vue.config.js as follows:

module.exports = {
  devServer: {
    port: 8080,
    hot: true,
    disableHostCheck: true,
    open: false,
    overlay: {
      warnings: true,
      errors: true
    },
    proxy: {
      '/api': {
        target: 'http://localhost:8034',
        changeOrigin: true,
        secure: false,
        ws: true,
        pathRewrite: {
          '^/api': ''
        }
      }
    }
  }
};

With this setup, a frontend request to http://localhost:8080/api/user/profile is internally rewritten to http://localhost:8034/user/profile, bypassing the need for CORS headers or manual URL manipulation in code.

Scenario 2: Production Frontend + Production Backend via Kubernetes

In a production Kubernetes cluster, the frontend is deployed as an Nginx-based container, exposed via an Ingress controller. All external traffic enters through a public domain (e.g., app.example.com), and the Ingress routes requests to the frontend service. The frontend container’s Nginx then proxies API calls to the backend gateway.

First, define the Ingress resource to route traffic to the frontend service:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: tls-cert
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-app
            port:
              number: 80

Next, configure the frontend container’s Nginx to handle API routing. The nginx.conf (mounted via ConfigMap) includes a location block that strips the /api prefix and forwards to the internal gateway service:

server {
    listen 80;
    server_name _;
    client_max_body_size 300m;
    server_tokens off;

    # Serve static assets
    location / {
        root /usr/share/nginx/html;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # Block sensitive endpoints
    location ^~/api/actuator {
        deny all;
        return 403;
    }

    # Proxy API requests to backend gateway
    location ^~/api/ {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
        add_header Cache-Control no-store;

        # Strip /api prefix before forwarding
        rewrite ^/api/(.*)$ /$1 break;

        # Forward to internal gateway service
        proxy_pass http://backend-gateway:8034;
    }
}

When a user accesses https://app.example.com/api/user/profile, the Ingress routes it to the frontend pod. Nginx removes the /api prefix and forwards the request to http://backend-gateway:8034/user/profile, where Spring Cloud Gateway then routes it to the correct microservice based on its service ID.

Scenario 3: Local Frontend + Remote Backend

When developing locally but testing against a staging or QA backend, the frontend still runs on localhost, but the API target is a remote endpoint. This avoids the overhead of deploying the backend locally and enables real-time testing with live data.

Modify the vue.config.js proxy configuration to point to the remote environment:

module.exports = {
  devServer: {
    port: 8080,
    proxy: {
      '/api': {
        target: 'https://staging.example.com',
        changeOrigin: true,
        secure: false,
        ws: true,
        pathRewrite: {
          '^/api': ''
        }
      }
    }
  }
};

Now, a request to http://localhost:8080/api/user/profile is proxied to https://staging.example.com/user/profile. This approach is ideal for debugging integration issues without requiring local replicas of all dependent services.

For added safety, ensure the remote backend allows cross-origin requests from your local development domain. If needed, configure the backend gateway to include appropriate CORS headers for http://localhost:8080.