Architecture
Data Source
How the portal communicates with its API.
Buyer documentation is provided in English.
The frontend always talks to a compatible API over HTTP. There is no fixture import, mock adapter, or second frontend data path to keep in sync.
Layering
Components import resolvers, resolvers own server-state operations, and services own HTTP transport. Each layer has one file per domain, so components never import the HTTP client directly.
text
components/ render and handle interaction
└── resolvers/ one file per domain, what components consume
└── services/ one file per domain, HTTP transport onlyConfiguring the API
bash
# portal/.env.local
NEXT_PUBLIC_API_URL=http://localhost:8080/api/v1The frontend package can be paired with the included Go API or another backend that implements the documented request, response, pagination, and authentication contracts.
Response envelope
JSON endpoints return a common envelope with a request ID. File downloads return raw bytes.
json
{
"status": 200,
"message": "Jobs retrieved successfully",
"request_id": "c571f1bd-ab09-418d-bb57-ebc2c42ae05f",
"response_time_ms": 0,
"server_time": "2026-09-18T19:18:33Z",
"meta": { "page": 1, "per_page": 20, "total": 1, "total_page": 1 },
"data": []
}Keep backend-specific behavior behind the REST boundary. Adding fixture imports or alternate transports to the portal creates contract drift and is rejected by the architecture check.