Site Configuration & Data Flow
Relevant source files
The following files were used as context for generating this wiki page:
FusionOps operates as a control plane for managing the lifecycle of PPC and affiliate landing pages. The system manages complex site configurations, ranging from brand identity and loan product parameters to technical tracking implementations, and facilitates their deployment across Cloudflare and GitHub-driven infrastructure.
This module ensures that data entered via the LP Wizard is sanitized, persisted, and correctly transformed into environment variables or asset maps required for functional landing pages.
Architecture & Data Schema
The system relies on a multi-tiered storage architecture. High-level configurations are managed within the web application, while operational data is distributed across D1 (SQLite) and Neon (Postgres) databases.
Site Configuration Fields
Configurations are categorized into functional groups such as Brand, Design, and Tracking. These fields are defined as constants to ensure consistency across the UI, API, and deployment scripts.
| Field Category | Key Variable Names | Description |
|---|---|---|
| Brand Identity | brand, domain, h1, sub, cta | Core copy and identity markers for the landing page. |
| Product Specs | amountMin, amountMax, aprMin, aprMax | Loan-specific ranges used for calculators and disclosures. |
| Design | colorId, fontId, layout, radius | Aesthetic tokens used to override template CSS variables. |
| Technical | aid, voluumDomain, conversionId | Affiliate IDs and tracking pixel configurations. |
Sources: src/constants/site-fields.js, src/utils/template-router.js:250-280
Data Distribution Flow
The following diagram illustrates how site configuration moves from the User Interface to various persistence and deployment layers.
Template Routing and Transformation
The template-router.js utility is the central engine for transforming raw site configuration into renderable assets. It handles both module-based templates and custom templates imported via external tools.
Normalization Logic
Before rendering, site data is passed through a normalization process. This ensures that values like loan amounts are formatted correctly (e.g., stripping '$' prefixes for numeric processing) and that defaults are provided for missing fields.
const normalizedSite = {
brand: site.brand || '',
phone: site.phone || autoPhone,
amountMin: formatAmount(site.amountMin, 100),
amountMax: formatAmount(site.amountMax, 5000),
redirectUrl: site.voluumClickUrl || site.redirectUrl || '#',
};
Sources: src/utils/template-router.js:254-282
Template Variable Substitution
FusionOps uses a "zero-GTM" tracking architecture. The router injects mandatory tracking blocks and design token overrides directly into the HTML <head> of the template.
- Astro Frontmatter Parsing: Scans
.astrofiles forimport.meta.env.PUBLIC_declarations and maps them to normalized site values. - JSX Evaluator: Processes
{items.map(...)}blocks by extracting array literals from the template source and rendering JSX for each item. - Design Token Overrides: Injects a
<style>block at the highest specificity level to override CSS variables like--primary,--secondary, and--radius.
Sources: src/utils/template-router.js:315-350, src/utils/template-router.js:520-545
Deployment Data Flow
Deployments are handled by specialized deployer modules that map site configurations to the specific requirements of the target platform.
GitHub Actions Integration
The GitHub Actions deployer is responsible for triggering the build of the Astro project. It transforms site configuration fields into GitHub Workflow inputs.
Environment Variable Mapping
The system maps UI fields to CI environment variables using a specific mapping structure:
| UI Field | Workflow Input / Env Var |
|---|---|
colorId | color_id / PUBLIC_COLORID |
fontId | font_id / PUBLIC_FONTID |
voluumDomain | voluum_domain / PUBLIC_VOLUUMDOMAIN |
conversionId | gtag_id / PUBLIC_CONVERSIONID |
Sources: src/utils/deployers/github-actions.js:25-50
Infrastructure Setup & Initialization
Proper data flow requires a correctly initialized backend. The setup-infrastructure.js script automates the creation of the database schemas required for site persistence.
Database Requirements
Three distinct D1 databases must be provisioned:
- fusionops-main: Stores core site configurations and deployment history.
- fusionops-pixel: Dedicated to high-volume analytics tracking events.
- fusionops-callback: Handles lead data and webhook notifications.
Sources: INFRASTRUCTURE_SETUP.md, scripts/setup-infrastructure.js:23-35
Site Versioning and Persistence
When a site is saved via App.jsx, the configuration is serialized and sent to the API Worker. The API layer utilizes Neon Postgres for relational site data (using a JSONB column for the data field) and Cloudflare D1 for deployment logs.
CREATE TABLE IF NOT EXISTS sites (
id TEXT PRIMARY KEY,
data JSONB NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
Sources: INFRASTRUCTURE_SETUP.md:144-150
Summary
The Site Configuration & Data Flow system in FusionOps bridges the gap between marketing-focused UI inputs and technical deployment requirements. By utilizing a standardized field mapping constant (site-fields.js), a sophisticated transformation engine (template-router.js), and automated infrastructure setup, the project ensures that landing pages are generated with accurate brand identity, working calculators, and compliant tracking across all environments.