Skip to main content

Explanation: JIT Federated Discovery (The Oracle)

JIT (Just-In-Time) Federated Discovery is the mechanism Framework M uses to resolve resource ownership in a distributed macroservice environment. It replaces the legacy model of unconditional startup broadcasts with a lazy, batch-capable query system.

The Problem: Broadcast Noise​

In a large-scale deployment with dozens of micro-frontends (MFEs), a broadcast-only model creates significant overhead:

  1. Network Noise: Every service heartbeat consumes bandwidth.
  2. Memory Bloat: Every service must maintain a full global map of all DocTypes, even ones it never uses.
  3. Monolith Friction: In local development, overlapping broadcasts from a monolith and a standalone service create discovery conflicts.

Instead of pushing data to everyone, the framework now pulls data only when needed. The Gateway acts as the Oracle—the central authority that knows which service owns which resource.

The Handshake Flow​

Discovery Oracle Flow

1. Fuzzy Suffix Matching​

To improve developer experience, the PluginRegistry supports fuzzy matching. If a developer requests Invoice, but the registry only knows about sales.Invoice, the registry will:

  1. Check for an exact match.
  2. If missing, iterate through registered resources to find a suffix match (*.Invoice).
  3. If found, it automatically maps the short name to the fully-qualified namespaced owner.

2. Batching & Pre-warming​

To minimize latency:

  • Batching: Multiple resource requests are aggregated into a single POST to the Oracle.
  • Pre-warming: The Shell identifies "Core" services (Auth, Settings, Navigation) and warms them during the prewarmCore phase before the UI is interactive.

3. Local Dev Parity​

In local development, the "Oracle" behavior is maintained by running a local NATS instance. Every local process writes its manifest to a shared NATS KV bucket, ensuring that the same code paths used in production (JIT queries and real-time watchers) are exercised on localhost.