ADR-0001: GraphQL as the source access interface¶
- Status: accepted
- Date: 2026-08-24 (ported from reference architecture v0.6.2)
- Satisfies: P-02, D-09, GO: GraphQL as a selective query mechanism
- Deliberation: Reference architecture v0.6.2, decision 1, and its GraphQL + PBAC proposal (archived and unpublished)
- Implemented in: services/graphql-server, services/brp-graphql-server, services/lvg-graphql-server
Context and problem statement¶
Data minimization (dataminimalisatie) requires a different set of fields for each consent scope. With REST, each scope needs a separate endpoint or separate filter parameters. Policies must then also state who can use which filter. As a result, the API layer and the policy layer hold the same logic twice.
Decision¶
Bronhouders expose GraphQL endpoints. The selection set of the consumer is the data minimization: the query names exactly the fields that the consumer wants. The policy engine authorizes that query field by field.
Selectors that matter for authorization, such as the belastingjaren year
filter, must travel inside the query. Then the PDP can enforce them.
Consequences¶
- The query is the authorization object. For more information, see ADR-0009 and ADR-0013.
- GraphQL runs over HTTP, so FSC proxies it unchanged (ADR-0003).
- GraphQL is not a recognized type of FDS data service (datadienst). ADR-0025 proposes to standardize it. The iWlz/nID production precedent supports the pattern.