CDF Architecture
CDF is the single integration surface between your app UI and any number of IoT ecosystems. It is SDK-agnostic by design: SDKs plug in through adaptors, CDF owns the entities and stores, and your UI only ever imports CDF types.
Layered architecture overview
CDF is the central hub that connects your app to multiple SDKs. Each SDK has an adaptor that translates its data into CDF entities and operations. Your app only imports CDF types.
Key concepts:
- Multiple SDKs — Support RainMaker, Matter, RM NG, or add your own
- One adaptor per SDK — Each adaptor translates its SDK's data to CDF shape
- Single CDF — All adaptors feed into one unified interface
- UI imports CDF only — App developers never import SDK types directly
What each layer does
| Layer | Responsibility |
|---|---|
| App / UI | Screens and components — read stores, call entity methods |
| Stores | Observable data containers — what the UI displays and updates |
| Entities | Wrappers around SDK functionality — group operations and handle SDK calls |
| Adaptors | Transform SDK data into CDF shape — bridge between SDK and CDF |
| SDKs | Raw APIs and protocols — auth, HTTP, device communication |
| Registry | Manage which adaptor is active — route all calls to the right SDK |
Why the design works this way
| Design choice | Benefit |
|---|---|
| Entities delegate to SDK | UI methods map cleanly to SDK operations — no translation in screens |
| Adaptors transform data | Each SDK adaptor owns the translation — easy to add new SDKs |
| Single AdaptorRegistry | Switch SDKs at runtime without changing UI code |
| Stores update via callback | All data changes go through one path — no race conditions or inconsistency |
| No SDK types leak to UI | UI never imports SDK packages — cleaner dependencies and easier to test |
Related Resource
- CDF overview — terminology
- Getting started — bootstrap sequence
- Adaptor registry — registry, adaptors, transformers
- Entities — entity wrapper, catalog, events