Skip to content

FED-BFF Layer

This page describes the Federation (FED) layer — the consistent BFF (Backend for Frontend) service that bridges backend systems (Odoo, MongoDB, InfluxDB) with UXI frontend applications.

Role

dirac-fed provides provider-agnostic DTOs to UXI applications through GraphQL BFF modules. It decouples frontend applications from backend implementation details while giving backend developers fixed contract targets.

Architecture

UXI Apps (Next.js)
    │
    ▼  GraphQL
FED-BFF (Apollo Server)
    │
    ├── Odoo (products, articles, contacts)
    ├── MongoDB (content, site structure)
    └── InfluxDB (metrics, dashboards)

Key Concepts

  • Intent-Driven BFF Contracts: Contract changes must be designed and governed through explicit intent, not ad-hoc field additions
  • Modular BFF Design: Each domain (marketing, dashboards, PA) gets its own BFF module
  • ContentNode\<T> Wrapper: All data uses a standard wrapper: { contentKey, contentType, schemaVersion, data: T, publishState, tags, createdAt, updatedAt }
  • Provider-Agnostic DTOs: UXI apps consume stable DTOs regardless of which backend provides the data

Current BFF Modules

Module Domain Status
Marketing Product detail, articles, pages, sites Active (current worked example)
Flux AaaSIoT Dashboard Active
Contact Sales portal registration, branded emails Active
Dashboards Future — metrics and informatics Planned
PA Future — portal applet support Planned

Odoo Integration

The FED layer depends on oves_product_marketing, a custom Odoo module providing:

  • product.property.line — Bill of Properties (BoP)
  • product.media — Media gallery (images + videos)
  • Extended product.template fields: x_product_key, x_slug, x_general_description_md, x_main_media_id, x_publish_state

Cross-Repo Sync

FED contracts must stay in sync with dirac-uxi-isr:

  • When UXI adds a field: Update Odoo model + resolver
  • When FED changes a structure: Update UXI contract + sample data
  • Always: Test against mock JSON to verify output matches