docs: document the Angular portal in README

Notes the /portal path, that it's kept alongside new-frontend rather
than replacing it, and updates the container count and click-through
intro accordingly.
This commit is contained in:
eho
2026-07-31 09:19:04 +02:00
parent a3ba1573e1
commit ec965976b0
+25 -10
View File
@@ -10,9 +10,11 @@ migration strategy can be watched instead of slide-decked.
docker compose up -d --build
```
Then open **http://localhost:8080**. That's the only host port published —
`legacy-backend` and `case-framework` are deliberately unreachable from the
host (see §4 below).
Then open **http://localhost:8080** (Session 1's placeholder UI) or
**http://localhost:8080/portal** (Session 2's Angular portal) — both are
reachable side by side through the same proxy, for comparison. That's the
only host port published — `legacy-backend` and `case-framework` are
deliberately unreachable from the host (see §4 below).
**Memory:** SQL Server (`legacy-db`) needs roughly 2GB of RAM; budget ~6GB
total for Docker/Podman. First start takes a minute or two while SQL Server
@@ -28,13 +30,22 @@ Verify everything end to end:
Run this against a **freshly started** stack — it depends on the untouched
seed data (legacy ids 10011012, owned ids `REG-2026-0001..0005`).
## What's built so far (Session 1 — backend)
## What's built so far
Nine containers: two frontends (one placeholder, see below), three backends,
three databases, one proxy. `new-frontend` in this session is a deliberately
plain, unstyled HTML page (`new-frontend/index.html`) that exercises the same
API a real UI would — it exists to prove the backend before a real Angular
portal replaces it in Session 2, not to be a good UI.
**Session 1 — backend.** Ten containers: three frontends, three backends,
three databases, one proxy. `new-frontend` (reachable at `/`) is a
deliberately plain, unstyled HTML page (`new-frontend/index.html`) that
exercises the same API a real UI would — it exists to prove the backend, not
to be a good UI.
**Session 2 — Angular portal.** `portal-frontend` (reachable at `/portal`) is
a real Angular application over the same API, kept alongside `new-frontend`
rather than replacing it, so the two can be compared side by side. It covers
full functional parity with the placeholder: the worklist, case detail, and
all four actions (edit applicant details, record assessment, take/release
ownership) — driven entirely off the API's own `actions`/`seams` blocks in
each response, never a hardcoded URL. See
[`portal-frontend/`](portal-frontend) for the app itself.
## The seams and write paths
@@ -100,7 +111,11 @@ work for `LegacyAanvraagMapper` instead of a copy-paste.
## 10-minute click-through
1. **Werkvoorraad**`GET /api/worklist` (or the placeholder page at `/`):
Every step below works identically through the raw API, the Session 1
placeholder at `/`, or the Session 2 Angular portal at `/portal` — they're
three windows onto the same backend.
1. **Werkvoorraad**`GET /api/worklist` (or either frontend's root page):
17 cases from two databases in one list. Filter `?origin=Legacy` /
`?origin=Owned` to see which is which.
2. **`A-1001`** (`GET /api/worklist/legacy/1001`) — all three write paths