Framework Internals
How the Reventless framework is structured and operates internally. Read the pages below in order — each builds on the previous — then move on to Extending the framework.
Architectural patterns
Reventless leans on a few patterns throughout, for consistency, type safety, and provider independence:
- Component structure pattern — every component is two required files
(
Component.resfor types,Component_Builder.resfor the construction functor) plus up to three optional ones (_Adapter,_Operations,_Callback). See Component structure pattern. - First-class modules and functors — components are parameterized over their specs and adapters, so the same builder works for any provider.
- Adapter pattern — infrastructure is injected through adapter interfaces; the core depends on no provider.
- Deploy-time vs runtime separation —
Pulumi.Output.t-wrapped values keep deploy-time (infrastructure) and runtime (Lambda) concerns distinct.
The ordered tour
- Messages — how commands and events are shaped, correlated, and routed.
- Serialization — encoding/decoding with sury and the
@schemaPPX. - Resources — how infrastructure resources are modeled.
- Runtime & deployment — runtime environments and the Single/PerAggregate/Micro deployment strategies.
- Pulumi integration — deploy-time vs runtime separation in depth.
- Component structure pattern — the file pattern used by every component, walked through with EventLog.
- MCP — AI-native access via tools and resources.
Then: Extending the framework → — add a new component or a new provider adapter.
Where the implementations live
- Framework core:
reventless/reventless-core/src/components/(andsrc/admin/for the built-in Platform Admin components). - Provider adapters:
reventless/reventless-aws/src/adapter/andreventless/reventless-local/src/adapter/. See the AWS adapter reference for the concrete AWS mappings.
Related
- Component Overview — high-level component architecture
- ReScript Syntax — language features used throughout the framework