Skip to content

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 only

Configuring the API

bash
# portal/.env.local
NEXT_PUBLIC_API_URL=http://localhost:8080/api/v1

The 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.