Skip to content

DIRAC Federation

DIRAC Federation defines the consistent federated BFF layer for the DIRAC platform.

Use this site when you need to understand what the FED layer is supposed to serve, how DIRAC functionality is normalized into a shared backend layer for UXI applications, and which docs are authoritative before changing schema, mappings, or resolver behavior.

The governing intent is straightforward: dirac-fed brings together underlying DIRAC functionality and DTO layers into a stable set of UXI-domain-focused modular BFF contracts. That keeps frontend applications decoupled from backend implementation details that may change over time, and it puts fixed contract targets in place so backend developers do not keep aiming at moving goal posts.

The marketing domain is one active worked example in this repo, not the repo's full boundary. The same FED approach is intended to extend to other DIRAC UXI capability areas, including dashboards and the PA.

What This Site Is For

This repo is the contract and mapping home for:

  • GraphQL-first FED schema boundaries
  • BFF modules that bring DIRAC functional capability into one consistent federated layer
  • provider-agnostic DTO expectations
  • Odoo-to-FED mapping guidance
  • downstream reuse across DIRAC UXI applications

Start Here

Core Repo Authorities

  • schema/marketing.graphql is the FED contract boundary for GraphQL behavior
  • vocab/marketing.vocab.yaml is the semantic registry authority
  • this docs site explains workflow, intent, and mapping rules for turning source-system capability into stable UXI-facing BFF contracts
  • current checked-in schema and vocabulary focus on the marketing example, but the repo intent is broader than that single domain

Small notes: progressive architecture decisions are tracked in Architecture Decision Records; stable lookup material lives under Reference.