Files
apf_portal/infra/local/dev.compose.yml
T
julien a84ea2d116
CI / commits (push) Has been skipped
CI / scan (push) Successful in 4m39s
CI / check (push) Successful in 7m6s
CI / a11y (push) Successful in 2m38s
CI / perf (push) Successful in 7m52s
feat(spa): proxy /api in dev-server, relative bffApiBaseUrl (#259)
## Summary

Make the SPAs reach the BFF as a **same-origin** call via an Angular dev-server `/api` proxy. Solves the "Backend unreachable" error surfaced during the ADR-0030 dockerised dev mode VM validation when the SPA is accessed from a remote browser (e.g. `http://<vm-ip>:4200/`), and bypasses CORS in dev altogether. Follow-up to the just-merged ADR-0030 implementation.

## Root cause it fixes

Before this PR, both SPAs hardcoded `bffApiBaseUrl: 'http://localhost:3000/api'` (per ADR-0018) and the BFF's `CORS_ALLOWED_ORIGINS` only allowed `http://localhost:4200,http://localhost:4300`. Both assumptions hold for native `nx serve` (developer on the same machine as the BFF) but break the moment the browser sits on a different host than the BFF — exactly the case for the ADR-0030 `apps` Compose profile: open `http://<vm-ip>:4200/` from your workstation and the SPA's `localhost:3000` call hits your **workstation's** loopback (nothing there), not the VM's BFF. Even if the URL were right, the origin `http://<vm-ip>:4200` is not in the CORS allowlist.

## Fix

Switch to a same-origin dev pattern: the Angular dev-server proxies `/api/*` to the BFF, and `environment.ts` uses a relative `'/api'` URL.

| File | Change |
| --- | --- |
| `apps/portal-shell/proxy.conf.js` | **New.** Maps `/api → ${BFF_TARGET:-http://localhost:3000}` (JS form so the env var can swap the target at startup). |
| `apps/portal-admin/proxy.conf.js` | **New.** Same shape. |
| `apps/portal-shell/project.json`, `apps/portal-admin/project.json` | `serve.options.proxyConfig` points at the new file. |
| `apps/portal-shell/src/environments/environment.ts`, `apps/portal-admin/src/environments/environment.ts` | `bffApiBaseUrl: 'http://localhost:3000/api'` → `'/api'`. The comment block explains the rationale + how production siblings can still use an absolute origin if SPA + BFF live on different hosts. |
| `apps/portal-shell/src/observability/tracing.ts` | `new URL(environment.bffApiBaseUrl)` would throw on a relative URL — resolved against `window.location.origin` so both relative (dev) and absolute (prod cross-origin) bases work. |
| `infra/local/dev.compose.yml` | `BFF_TARGET=http://portal-bff:3000` added to `portal-shell` and `portal-admin` so the proxy hits the BFF **container** by name (Compose DNS) when the `apps` profile is up. Native `nx serve` leaves the var unset and falls back to `localhost:3000`. |

## Why a relative URL is safe

- `${bffApiBaseUrl}/health` etc. compose to `/api/health` — relative paths work in `fetch` / `HttpClient`.
- `tracing.ts` propagates `traceparent` on requests whose origin matches the BFF origin. Resolving the relative base against `window.location.origin` gives the current page's origin, which is exactly the origin the dev-server proxy serves from — so the regex still matches the right requests in dev. In a future cross-origin production deployment, `environment.prod.ts` can set an absolute `bffApiBaseUrl`; the URL constructor's second arg is ignored when the first is absolute, so the same code path keeps working.
- Auth flow (`feature-auth` / `auth.config.ts`): consumes `bffApiBaseUrl` via DI as a string prefix — agnostic to absolute vs relative.

## Scope notes

- The OTel HTTP exporter (`environment.otlpEndpoint = 'http://localhost:4318/v1/traces'`) and the cross-SPA links (`adminAppUrl`, `shellAppUrl`) **remain absolute**. They hit the same remote-browser problem on `apps`-profile access, but neither is blocking the user-visible "Backend unreachable" path this PR targets. Out of scope here; a follow-up could either proxy them too or surface them via runtime config.
- This pattern is dev-server only — production builds do not use the proxy. Per-environment `bffApiBaseUrl` overrides remain the supported lever (ADR-0018), unchanged.

## Test plan

- [x] `docker compose -f dev.compose.yml --profile apps config` still validates.
- [ ] **On the VM**, `./infra/local/dev.sh up apps`, then in the workstation browser open `http://<vm-ip>:4200/` → SPA loads, the "Backend unreachable" message is gone, network tab shows `/api/...` calls succeeding (same-origin, no CORS preflight).
- [ ] Native `nx serve portal-shell` still works (the proxy falls back to `localhost:3000`).
- [ ] Trace headers (`traceparent`) appear on `/api/*` fetches in the browser network tab.
- [ ] `pnpm exec nx affected -t test build` green on the two SPAs.

## Related

- [ADR-0030](docs/decisions/0030-dockerised-dev-mode.md) — the dockerised dev mode this enables to actually work from a remote browser.
- [ADR-0018](docs/decisions/0018-environment-configuration-strategy.md) — the `environment.ts` per-env strategy this complements (does not supersede — production behaviour unchanged).

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #259
2026-06-01 11:39:40 +02:00

302 lines
11 KiB
YAML

# Local-dev infrastructure stack for `apf_portal`.
#
# Spins up the runtime dependencies the BFF and ADRs assume:
# - PostgreSQL 17 (per ADR-0006)
# - Redis 7 (per ADR-0010 — single node in dev,
# Sentinel HA in prod)
# - OpenTelemetry Collector (per ADR-0012 — receives OTLP from the
# BFF and the SPA, debug-logs traces in
# v1, forwards to Jaeger when activated)
#
# Optional viewers / tooling behind Compose profiles:
# - --profile dbtools → pgweb (Postgres GUI)
# - --profile observability → Jaeger UI (trace explorer)
# - --profile serve-static → Caddy reverse proxy that serves the
# production build with the per-locale
# routing the production reverse proxy
# will use (per ADR-0019)
#
# Usage from infra/local/:
# cp .env.example .env
# $EDITOR .env # set strong dev passwords
# docker compose -f dev.compose.yml up -d
#
# To bring up viewers too:
# docker compose -f dev.compose.yml --profile dbtools --profile observability up -d
#
# State persists in named volumes (`apf-portal-postgres-data`,
# `apf-portal-redis-data`). To wipe and start fresh:
# docker compose -f dev.compose.yml down -v
#
# Bootstrap SQL (audit roles + schema, per ADR-0013) is applied on
# first boot from init/postgres/. To replay after editing it, wipe
# the volume with `down -v` above.
name: apf-portal-dev
# Shared base for the ADR-0030 `apps` profile — dev servers for the three
# Nx apps. The repo is bind-mounted for hot reload; node_modules and the
# Nx cache live in named volumes so the container's install (native
# modules built for THIS image) is never shadowed by the host's.
x-app-base: &app-base
build:
context: .
dockerfile: Dockerfile.dev
profiles: [apps]
working_dir: /workspace
volumes:
- ../../:/workspace
- app-node-modules:/workspace/node_modules
- app-nx-cache:/workspace/.nx
networks:
- apf-portal-dev
services:
postgres:
image: postgres:17.2-alpine
container_name: apf-portal-postgres
restart: unless-stopped
environment:
POSTGRES_USER: ${POSTGRES_USER:-portal}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD must be set in infra/local/.env}
POSTGRES_DB: ${POSTGRES_DB:-portal_dev}
ports:
- '${POSTGRES_PORT:-5432}:5432'
volumes:
- postgres-data:/var/lib/postgresql/data
# Bootstrap SQL runs only on a fresh data volume.
- ./init/postgres:/docker-entrypoint-initdb.d:ro
networks:
- apf-portal-dev
healthcheck:
test:
['CMD-SHELL', 'pg_isready -U "${POSTGRES_USER:-portal}" -d "${POSTGRES_DB:-portal_dev}"']
interval: 5s
timeout: 3s
retries: 5
redis:
image: redis:7.4-alpine
container_name: apf-portal-redis
restart: unless-stopped
# AOF (`--appendonly yes`) keeps sessions across container restarts —
# the dev equivalent of the persistence we want from the prod
# Sentinel cluster (per ADR-0010 §"Persistence").
command:
- redis-server
- --requirepass
- ${REDIS_PASSWORD:?REDIS_PASSWORD must be set in infra/local/.env}
- --appendonly
- 'yes'
ports:
- '${REDIS_PORT:-6379}:6379'
volumes:
- redis-data:/data
networks:
- apf-portal-dev
healthcheck:
test: ['CMD', 'redis-cli', '-a', '${REDIS_PASSWORD}', 'PING']
interval: 5s
timeout: 3s
retries: 5
otel-collector:
image: otel/opentelemetry-collector-contrib:0.150.1
container_name: apf-portal-otel-collector
restart: unless-stopped
command: ['--config=/etc/otel-collector.yaml']
volumes:
- ./otel-collector.yaml:/etc/otel-collector.yaml:ro
ports:
# OTLP receivers — the BFF and the SPA send here.
- '${OTEL_GRPC_PORT:-4317}:4317'
- '${OTEL_HTTP_PORT:-4318}:4318'
networks:
- apf-portal-dev
# ------------------------------------------------------------------
# Optional: Postgres GUI (`--profile dbtools`).
# pgweb is a lightweight, no-config alternative to pgAdmin.
# ------------------------------------------------------------------
pgweb:
image: sosedoff/pgweb:0.16.2
container_name: apf-portal-pgweb
restart: unless-stopped
profiles: [dbtools]
# Use discrete CLI flags rather than `PGWEB_DATABASE_URL`. The URL
# form is fragile: any special character in POSTGRES_PASSWORD
# (`@`, `#`, `:`, `/`, `?`, `%`, `&`, …) breaks the userinfo
# parser, and the resulting "Invalid URL" error is opaque. Discrete
# flags accept any password verbatim. The image's ENTRYPOINT
# already passes `--bind=0.0.0.0 --listen=8081`; these args are
# appended.
command:
- --host=postgres
- --port=5432
- --user=${POSTGRES_USER:-portal}
- --pass=${POSTGRES_PASSWORD:?POSTGRES_PASSWORD must be set in infra/local/.env}
- --db=${POSTGRES_DB:-portal_dev}
- --ssl=disable
ports:
- '${PGWEB_PORT:-8081}:8081'
depends_on:
postgres:
condition: service_healthy
networks:
- apf-portal-dev
# ------------------------------------------------------------------
# Optional: Jaeger UI for trace exploration (`--profile observability`).
# The collector pipeline above always tries to forward to `jaeger:4317`;
# when this profile is off, those exports fail silently (logged at
# warn level by the collector — no blocking effect on the debug
# exporter that prints traces to stdout).
# OTLP ports (4317/4318) are NOT published from this service to
# avoid colliding with the collector — the collector talks to
# Jaeger on the internal Compose network.
#
# Image is Jaeger v2 (`jaegertracing/jaeger`, distinct from the v1
# `jaegertracing/all-in-one`). v2 is the rewrite built on top of
# OpenTelemetry Collector and is the actively-developed line. OTLP
# receivers are enabled by default (no COLLECTOR_OTLP_ENABLED env
# needed) and the UI ships a built-in Light/Dark/Auto theme
# selector — features the v1 image did not have.
# ------------------------------------------------------------------
jaeger:
image: jaegertracing/jaeger:2.17.0
container_name: apf-portal-jaeger
restart: unless-stopped
profiles: [observability]
ports:
- '${JAEGER_UI_PORT:-16686}:16686'
networks:
- apf-portal-dev
# ------------------------------------------------------------------
# Optional: Caddy reverse proxy for the production build
# (`--profile serve-static`).
#
# Workflow:
# pnpm exec nx build portal-shell --configuration=production
# ./infra/local/dev.sh up serve-static
# open http://localhost:${SERVE_STATIC_PORT:-4200}/
#
# Mirrors what the production reverse proxy will do per ADR-0019:
# smart redirect at `/` (Accept-Language → `/fr/` or `/en/`),
# per-locale SPA fallback, and `/{locale}/<deep-link>` routing.
# No locking-down on TLS / auth — this is a local convenience that
# boots in <1 s and binds to localhost only.
# ------------------------------------------------------------------
serve-static:
image: caddy:2.10-alpine
container_name: apf-portal-serve-static
restart: unless-stopped
profiles: [serve-static]
command: ['caddy', 'run', '--config', '/etc/caddy/Caddyfile', '--adapter', 'caddyfile']
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
# Bind-mount the production build folder read-only. The path
# resolves relative to this compose file, i.e.
# <repo>/dist/apps/portal-shell/browser/. Empty until the
# production build runs — caddy will 404 every request in that
# state, which is the right signal.
- ../../dist/apps/portal-shell/browser:/srv/dist:ro
ports:
- '${SERVE_STATIC_PORT:-4200}:4200'
networks:
- apf-portal-dev
# ------------------------------------------------------------------
# ADR-0030 dockerised full-stack dev mode (`--profile apps`).
#
# ./infra/local/dev.sh up apps → infra + the three dev servers,
# no native Node/pnpm on the host.
#
# Hot reload via the repo bind-mount. See docs/setup/ for the
# "which mode when" guidance (native / devcontainer / compose apps).
# NOTE: the SPA dev servers default to 4200/4300 — the same 4200 the
# `serve-static` profile uses; don't run `apps` and `serve-static`
# together, or override SHELL_PORT.
# ------------------------------------------------------------------
# One-shot: populate the shared node_modules volume once so the three
# app services don't race three concurrent installs on it. Exits when
# done; the apps gate on its successful completion.
apps-deps:
<<: *app-base
container_name: apf-portal-apps-deps
command: ['pnpm', 'install', '--frozen-lockfile']
portal-bff:
<<: *app-base
container_name: apf-portal-bff-dev
environment:
APF_ROLE: bff
NODE_ENV: development
PORT: '3000'
# Host-specific URLs rebuilt from infra/local/.env creds → Compose
# service names. Compose `environment` wins over `env_file`, so
# these override the localhost values in the BFF's own .env.
DATABASE_URL: 'postgresql://${POSTGRES_USER:-portal}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB:-portal_dev}?schema=public'
REDIS_URL: 'redis://default:${REDIS_PASSWORD}@redis:6379/0'
OTEL_EXPORTER_OTLP_ENDPOINT: 'http://otel-collector:4318/v1/traces'
# Secrets (Entra / session / jwks) come from the BFF's own dev env.
# `required: false` so SPA-only devs can `up` without it — the BFF
# then fails its own boot-time config validators with a clear message
# rather than Compose erroring on a missing file.
env_file:
- path: ../../apps/portal-bff/.env
required: false
command: ['pnpm', 'exec', 'nx', 'serve', 'portal-bff']
ports:
- '${BFF_PORT:-3000}:3000'
depends_on:
apps-deps:
condition: service_completed_successfully
postgres:
condition: service_healthy
redis:
condition: service_healthy
portal-shell:
<<: *app-base
container_name: apf-portal-shell-dev
environment:
# Read by apps/portal-shell/proxy.conf.js — points the dev-server
# /api proxy at the BFF container by name (Compose DNS). Native
# `nx serve` leaves BFF_TARGET unset and falls back to localhost.
BFF_TARGET: http://portal-bff:3000
command: ['pnpm', 'exec', 'nx', 'serve', 'portal-shell', '--host', '0.0.0.0', '--port', '4200']
ports:
- '${SHELL_PORT:-4200}:4200'
depends_on:
apps-deps:
condition: service_completed_successfully
portal-admin:
<<: *app-base
container_name: apf-portal-admin-dev
environment:
# See portal-shell — same proxy target for the admin SPA.
BFF_TARGET: http://portal-bff:3000
command: ['pnpm', 'exec', 'nx', 'serve', 'portal-admin', '--host', '0.0.0.0', '--port', '4300']
ports:
- '${ADMIN_PORT:-4300}:4300'
depends_on:
apps-deps:
condition: service_completed_successfully
volumes:
postgres-data:
name: apf-portal-postgres-data
redis-data:
name: apf-portal-redis-data
app-node-modules:
name: apf-portal-app-node-modules
app-nx-cache:
name: apf-portal-app-nx-cache
networks:
apf-portal-dev:
name: apf-portal-dev