ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Backend for Frontend

One API per customer experience: stop compromising with a single API that "serves everyone badly".

Problem

An EDI hub exposes a REST API /orders common to the web supplier portal (Next.js), the ops mobile app (React Native) and the finance dashboard (Power BI). Each has incompatible needs: the portal wants the full order detail with lines; mobile wants a minimal compressed payload; finance wants quarterly aggregates. If the API tries to serve everyone, it over-fetches for mobile (latency) and under-fetches for finance (10 chained calls). If it adds ?include=lines&agg=quarter parameters, it becomes an unmanageable complexity hub.

Forces

  • UX contexts diverge. Mobile = limited bandwidth, small screen. Desktop = detailed data. Reporting = heavy aggregates.
  • Teams differ. Portal team = product + design; ops team = SRE; finance team = data engineers. A single API forces joint release cycles.
  • Client-side aggregation is expensive. Mobile making 12 calls to build a view = battery + latency.
  • Security differs. Portal = supplier OAuth; ops = internal SSO; finance = strict MFA. Auth policies per consumer.

Solution

Build one BFF per customer experience. The Supplier Portal BFF exposes GET /orders/:id aggregating the order service, the invoice service and the audit service in a single rich payload. The Ops Mobile BFF exposes GET /alerts returning only real-time KPIs filtered by watched partner. The Finance BFF exposes GET /revenue?period=quarter with pre-aggregation and long cache. Each BFF is owned by the team shipping the UI. Internal services (Order, Invoice, Routing) stay stable and generic. 

    Supplier Portal       Ops Mobile App       Finance Dashboard
    (Next.js / web)       (React Native)       (BI dashboard)
          │                     │                     │
          ▼                     ▼                     ▼
    ┌─────────────┐       ┌─────────────┐       ┌─────────────┐
    │ Supplier    │       │ Ops BFF     │       │ Finance BFF │
    │ BFF         │       │ /alerts     │       │ /kpis       │
    │ /orders     │       │ /retries    │       │ /revenue    │
    │ /invoices   │       │ /backlog    │       │ /aging      │
    └──────┬──────┘       └──────┬──────┘       └──────┬──────┘
           │                     │                     │
           ▼                     ▼                     ▼
    ┌──────────────────────────────────────────────────────────┐
    │  Internal services: Order, Invoice, Routing, Audit, ML   │
    └──────────────────────────────────────────────────────────┘

EDI implementation

Concrete case: a multi-channel EDI hub: web supplier portal for industrials who see their INVOIC sent and MDN status; mobile app for operators who see flows in error to reprocess; executive dashboard for business KPIs. The Supplier BFF translates the internal model (raw EDIFACT INVOIC) into a domain-friendly payload (invoice number, human status). The Ops BFF prioritises dead-letter-channel exceptions with retry context. The Finance BFF pre-computes on-time delivery rate, average DSO, partner aging. Internal services (EDIFACT parser, AS2 broker, archive) are unchanged.

Anti-patterns

  • BFF that becomes a monolith. If every UI ends up hitting the same BFF with parameters: the monolithic API has been reinvented. One BFF per UI, isolated.
  • BFF containing business logic. The BFF aggregates and adapts, it does not create. If the rule "should we retry?" lives in the Ops BFF and not in the retry service, the business rule becomes inconsistent across clients.
  • BFF per device instead of per experience. One iOS BFF, one Android BFF, one Web BFF all doing the same thing: useless duplication. One BFF per UX use case.
  • API Gateway: similar but more generic; the BFF is a Gateway specialised to a UI.
  • Composed Message Processor — the BFF often aggregates heterogeneous messages.
  • Content Enricher — the enrichment phase often embedded in the BFF.
  • Service Mesh — the mesh between BFF and internal services.

Sources