Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_WEB/llms.txt

Use this file to discover all available pages before exploring further.

Dragon Guard WMS Web is designed to run in production environments where the backend URL may change between deployments, tenants, or infrastructure upgrades — without requiring a frontend recompile each time. This page explains the default same-origin routing behavior, when to override it, and how to use src/assets/runtime-config.js to supply a custom backend URL at startup.

​
Default Production Behavior

In production mode, environment.prod.ts does not hardcode any IP address or hostname. Instead, it derives both URLs from the browser’s current location at runtime: 
const serverUrl = window.location.origin;

export const environment = {
  production: true,
  serverUrl: serverUrl,
  apiUrl: `${serverUrl}/api`,
  appName: 'Dragon Guard WMS'
};
This means that when the frontend is served from https://dragonguard.mycompany.com, it will automatically direct all API calls to https://dragonguard.mycompany.com/api — with no configuration needed. This approach allows the same build artifact to be dropped onto any server and work correctly, as long as the frontend and backend are co-hosted under the same domain.

​
Why Same-Origin by Default?

Warehouse deployments commonly run on isolated LAN environments where hostnames or IP addresses change between sites, customers, and network segments. Hardcoding a specific address in the compiled bundle would require a new build for every environment. By anchoring to window.location.origin, a single production build works across all same-host deployments.

​
Overriding the Backend URL at Runtime

When the frontend and backend are hosted on different domains or ports — for example, a CDN-served SPA calling a separate API server — you must tell the application where the backend lives without recompiling. Create or edit src/assets/runtime-config.js and define the window.__dragonGuardConfig object: 
window.__dragonGuardConfig = {
    serverUrl: 'https://dragonguard.mycompany.com',
    apiUrl: 'https://api.mycompany.com/api'
};
This file is loaded by the application at startup, before Angular bootstraps. When window.__dragonGuardConfig is present, its values take precedence over the defaults derived from window.location.origin.
You can update runtime-config.js on the server at any time — no rebuild or redeployment of the Angular bundle is needed. This makes it ideal for ops teams who need to point the frontend at a new backend without involving a development pipeline.

​
Configuration Rules

Follow these rules for every production and staging deployment:
  • Do not hardcode internal LAN IPs in environment.prod.ts. Use the same-origin default or the runtime-config.js override instead.
  • Validate the real host on the target network before deploying. Confirm that serverUrl resolves correctly from the client machines in that environment (warehouse terminals and workstations may have restricted DNS).
  • If using a reverse proxy, confirm that /api on the frontend host correctly proxies requests to the backend service. Misconfigured proxy rules are the most common cause of 404 or 502 errors on first deployment.
  • Version operational overrides outside the source repository when infrastructure requires it. The runtime-config.js file for a given environment should be managed by the infrastructure or ops team, not committed alongside application code.
Never commit live backend IPs or production credentials to the repository. The runtime-config.js file is gitignored in production deployments and must be provisioned separately on each target host.

​
Deployment Scenarios

The simplest and recommended deployment topology: the Angular frontend and the .NET Wms.Api backend are served from the same domain (e.g., via IIS, nginx, or a reverse proxy on a single server).No runtime-config.js override is needed. The default window.location.origin behavior routes all API calls correctly.Example setup with nginx:
server {
    listen 443 ssl;
    server_name dragonguard.mycompany.com;

    # Serve the Angular SPA
    location / {
        root /var/www/dragon-guard-wms;
        try_files $uri $uri/ /index.html;
    }

    # Proxy API calls to the .NET backend
    location /api {
        proxy_pass http://localhost:5262;
        proxy_set_header Host $host;
    }
}
With this configuration the frontend at https://dragonguard.mycompany.com will send API requests to https://dragonguard.mycompany.com/api, which nginx forwards to the local .NET process on port 5262.

Build docs developers (and LLMs) love

Get started for freeTalk to us