Appearance
What Is Favn
Favn is a runtime composition platform for multi-team frontend systems.
It is designed around one constraint: teams must be able to publish independently, while the host can discover and activate those artifacts safely without restarts.
Core idea
Favn separates concerns into three layers:
Favn Server
Handles discovery, verification, routing, shell rendering, and RPC transport.Domain Features(featureType: "domain")
Route-owning features that orchestrate workflows and can own data fetching.Facet Modules(featureType: "facet")
Reusable embedded UI units that receive data/props and emit user intent.
Legacy aliases are still accepted:
application->domainmodule->facet
Why it exists
Most micro-frontend systems optimize one side of the problem well:
- bundler/runtime composition,
- client-side orchestration,
- or server-side fragment composition.
Favn focuses on a different center of gravity:
- signed artifact discovery at runtime,
- operationally safe version/channel control,
- strict host boundary (transport/security/runtime), with business logic owned by teams.
How it differs from common approaches
| Area | Favn | Module Federation | Podium | single-spa |
|---|---|---|---|---|
| Primary unit | Manifested feature artifact (domain/facet) | Bundler remotes/containers | Server-rendered fragments/podlets | Client apps registered in root config |
| Discovery model | Runtime discovery from local artifacts and/or remote index | Remote container URLs configured at build/runtime | Layout + podlet registration | Runtime registration/import maps |
| Built-in trust chain | Yes: signed release index + signed manifest + integrity checks | No built-in signature chain by default | No built-in signature chain by default | No built-in signature chain by default |
| Routing ownership | Host resolves domain features by prefix; facets are embedded | App-defined, usually router/bundler-driven | Server layout/router-driven | Root config + client router integration |
| Shared deps model | Host import map + declared shared requirements | Federation shared scope negotiation | App/runtime dependent | App/runtime dependent |
| Server function transport | First-class /rpc/:feature/:fn with host context + proxy/module modes | Not a built-in concept | Not a built-in concept | Not a built-in concept |
| Team authorization model | Feature-owned business authz (host handles authn/transport) | Team/application-defined | Team/application-defined | Team/application-defined |
Mental model
What Favn is not
- Not a replacement for domain service design.
- Not a framework-level RBAC/business policy engine.
- Not tied to a single UI framework strategy beyond runtime contract requirements.
When Favn is a good fit
- 10+ teams shipping independently.
- Need runtime deployability without host rebuild/restart.
- Need strong provenance/integrity guarantees for loaded artifacts.
- Need an operational control surface for channel changes and rollback.
When Favn is likely overkill
- Small team with one deploy train.
- No requirement for runtime discovery or independent release cadence.
- No need for trust-chain verification across artifacts.