Core Concepts
The Archibald CMS integration is built on a set of core architectural patterns designed for flexibility and scalability. Understanding these concepts is crucial for building and extending CMS functionality.
Note: The concepts described here are specific to the CMS integration. For a broader explanation of the framework-level patterns like the Module System and Data Mappers, please refer to the main Core Concepts guide.
Key Component Clarification: CMSProvider vs. CMSClientProvider
Though their names are similar, these two components serve very different roles in different environments. They do not interact directly.
| Component | CMSProvider | CMSClientProvider |
|---|---|---|
| Environment | Server-side (Node.js) | Client-side (React) |
| Type | Abstract Class | React Component |
| Purpose | To fetch data directly from a third-party CMS (e.g., Contentful, SAP Commerce) and transform it into a standardized format for your Archibald application. | To provide an instance of the CMSClient to your React component tree. |
| Analogy | It's the data source connector that lives on your server. | It's the power outlet for your React components, allowing them to plug into the CMS functionality. |
Their relationship is indirect, linked by the process of SSR and client-side hydration, which is explained in more detail below.
The Provider & Adapter Pattern
The entire CMS integration is based on the Provider & Adapter pattern. This pattern decouples the client-side application from the server-side data fetching and the specific CMS implementation.
CMSProvider(Server-Side): As explained above, this abstract class is responsible for communicating with the actual CMS on the server.CMSAdapter(Client-Side): This abstract class communicates with your Archibald backend API, not the end CMS.
For a deeper dive into the theory behind this pattern, see the general Providers & Adapters documentation.
Client-Server Architecture & Lifecycles
To provide a complete picture, here are four views of the architecture.
1. Static Component Structure
This diagram shows the main building blocks and how they are composed. The CoreServer acts as the orchestrator, and the CMSModule registers its own set of components into the server.
2. Server Initialization Sequence
This diagram shows the sequence of events during server startup.
3. SSR & Data Hydration Flow
This diagram shows the indirect relationship between CMSProvider and CMSClientProvider during the initial page load.
4. Dynamic Client-Side Request Flow
This diagram illustrates a subsequent client-side data request (e.g., navigating to a new page).