002 – BFF Pattern
| Status | Accepted |
| Concerns | Architecture, Security, API Design |
Context
The frontend (Nuxt) needs to consume data from three backend modules. Exposing each module directly to the browser would require the frontend to manage authentication against multiple endpoints, assemble and transform data itself, and would expose internal service boundaries to the outside world.
Decision
Introduce a Backend For Frontend (BFF) — a dedicated Spring Boot WebFlux container that is the only backend endpoint accessible from the browser. The BFF:
- owns the full OIDC authentication flow (Spring Security OAuth2 Client) and validates the JWT on every request
- provides a frontend-oriented API — it shapes and adapts module responses to match what the frontend needs, keeping business logic out of the UI
- delegates domain operations to each module through their inbound service interfaces
- is the only container with a public-facing port
Consequences
- Backend modules are fully internal — they are never directly accessible from the browser.
- Authentication and authorisation are enforced at a single choke point. Modules do not validate tokens independently.
- The frontend consumes a purpose-built API and carries no data assembly or transformation logic.
- Adding a new consumer (e.g. a mobile app) would require either extending the BFF or creating a second BFF alongside it.