Architecture: How should the frontend API Dev Tools resolve API URLs to wo...

Documentation for Sessions

🏗️ Architecture: How should the frontend API Dev Tools resolve API URLs to wo...

Date: 2026-03-17
Time: 17:17:26 UTC
Session: gspace1-229.7
Agent: angular
Confidence: 97%
Status: ✅ Documented

📋 Decision Context

Question:

How should the frontend API Dev Tools resolve API URLs to work in both development (proxy) and production (direct domains)?

Task: Not specified

🎯 Decision Made

Chosen:

Inject the 4 URL tokens (API_BASE_URL, AI_API_URL, DOCS_API_URL, VITTO_API_URL) from @libs-foundational/api-config into ApiToolsService. Build the API configs at injection time using the resolved token values. In dev, tokens resolve to proxy paths (/api, /ai-api). In production, they resolve to full URLs (https://api.gograb.space/api). Zero configuration needed — the existing createSmartFactory() handles environment detection.

Options Considered:

  1. Hardcode proxy paths (dev-only, breaks in production)
  2. Use environment.ts imports directly (couples library to specific app)
  3. Inject URL tokens from @libs-foundational/api-config (chosen — standard pattern, works everywhere)
  4. Pass URLs as component inputs (awkward, pushes config to template)

💭 Reasoning

The initial implementation hardcoded relative proxy paths (/api, /ai-api, etc.) in a static API_CONFIGS constant. This only works in dev because the Angular dev server proxy forwards these paths to localhost backends. In production, there is no proxy — the frontend is static files. The codebase already has injection tokens with smart factories that detect localhost vs production and return the correct URL. Using these tokens is the standard pattern (used by AuthService, RealtimeTestComponent, etc.) and requires no additional configuration.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation