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:
@@ -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 1001–1012, 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
|
||||
|
||||
Reference in New Issue
Block a user