FDK Architecture

Overview

The Frontend Development Kit (FDK) is a configuration-driven code generation system for building operational dashboards and data-rich user interfaces. It follows a simple principle: configuration is the single source of truth. All frontend code is generated from declarative configuration files, eliminating manual scaffolding and wiring.

Core Concept: Config-Driven Development

Traditional frontend development requires writing and maintaining code for:

• Component structure and layout
• Data connections and API calls
• Routing and navigation
• State management
• Build configuration

The FDK inverts this. Instead of writing code, you define your application in a configuration file. The FDK reads that configuration and generates all the boilerplate code automatically.

Benefits:

• No Manual Scaffolding — Projects are created and structured programmatically
• Consistency — All applications follow the same patterns
• Rapid Development — Changes to config regenerate code instantly
• Low-Code Capability — Non-technical users can build interfaces through visual tools
• Version Control Friendly — Configuration changes show as clean JSON diffs

How It Works

Application Structure

FDK applications are defined by a single configuration file that describes:

Project Structure:

• Application metadata (name, version)
• Build settings and dependencies
• Routing configuration

Panels (Pages):

• Each panel is a route in your application
• Contains layout definition
• Lists components to display

Components:

• Individual UI elements (charts, tables, forms, maps)
• Data connections (which API to query)
• Display configuration (colors, labels, options)

Data Connections:

• GraphQL endpoints to query
• Query definitions and variables
• Data transformation rules

Generation Workflow

1. Define Configuration — Describe your application structure in JSON
2. Parse Configuration — Parser validates and builds application model
3. Generate Code — Generator creates React components and supporting files
4. Run Application — Generated code runs like any React application
5. Iterate — Update configuration and regenerate as needed

Example: Adding a Dashboard Panel

Traditional Approach:

1. Create new component file
2. Write component code
3. Add data fetching logic
4. Wire up API calls
5. Add to routing
6. Style and layout
7. Test and debug

FDK Approach:

1. Add panel definition to config
2. Specify components and layout
3. Define data connections
4. Regenerate
5. Done

The FDK handles all the boilerplate automatically.

Config-as-Source-of-Truth

Because configuration is data, not code, it can be:

Visualized:

• Visual tools can display configuration graphically
• Drag-and-drop interfaces manipulate config directly
• Non-technical users see changes before code generation

Validated:

• Configuration has a strict schema
• Invalid configurations are rejected before generation
• Type-safe throughout the system

Versioned:

• Configuration changes are clean JSON diffs
• Easy to review what changed
• Rollback is straightforward

Shared:

• Same config works across different environments
• Teams can collaborate on application structure
• Templates can be reused across projects

Low-Code Capability

The FDK's architecture enables visual development tools:

Panel Builder Interface:

• Drag components onto canvas
• Connect to data sources visually
• Configure appearance through forms
• See changes in real-time preview
• Export configuration for version control

Who It's For:

• Domain Experts — Build operational dashboards without coding
• Analysts — Create data visualizations quickly
• Operators — Customize interfaces for their workflows
• Developers — Accelerate frontend development

All these users work with the same underlying configuration. Developers see JSON diffs in version control; operators see visual changes in the builder.

Design Principles

Separation of Concerns

Configuration Layer — What to build (panels, components, data) Generation Layer — How to build it (React, bundling, optimization) Runtime Layer — The running application

Changes to generation strategy don't affect configurations. Improvements to code generation benefit all applications automatically.

Convention Over Configuration

The FDK has strong opinions about:

• Project structure (where files go)
• Component patterns (how components are built)
• Data fetching (how APIs are called)
• Routing (how navigation works)

This means less configuration to write and more consistency across applications.

Generated vs Custom Code

Generated Code:

• Created automatically from configuration
• Never edited manually (changes are overwritten)
• Handles standard functionality

Custom Code:

• For specialized business logic
• Written by developers when needed
• Preserved during regeneration

The system knows which files it owns and which belong to developers.

Integration with Platform

DDK Integration

FDK applications connect to DDK-generated GraphQL servers:

• Configuration specifies GraphQL endpoint
• Generated code includes data fetching hooks
• Type-safe queries based on DDK schemas
• Automatic error handling and loading states

Component Library

FDK provides pre-built components:

• Data Visualization — Charts, graphs, metrics
• Data Display — Tables, lists, cards
• Forms — Inputs, selectors, validators
• Maps — Geographic visualizations
• Custom — Build your own reusable components

All configurable through JSON, no code required.

Benefits Over Traditional Development

Speed

• New panels created in minutes, not hours
• Changes regenerate instantly
• No manual wiring or scaffolding

Quality

• Consistent patterns across all applications
• Type-safe from config to runtime
• Built-in best practices

Maintainability

• Configuration is easier to understand than code
• Less code to maintain (most is generated)
• Updates to generator improve all applications

Accessibility

• Non-developers can build interfaces
• Visual tools hide complexity
• Focus on what to build, not how

When to Use FDK vs Custom Development

Use FDK When:

• Building operational dashboards
• Creating data visualization interfaces
• Need rapid iteration
• Want consistent patterns
• Have non-technical stakeholders building UIs

Use Custom Development When:

• Highly specialized UI requirements
• Need complete control over implementation
• Building consumer-facing applications
• Unique user interactions not supported by component library

Many projects use both: FDK for standard operational interfaces, custom code for specialized features.

Best Practices

Configuration Design

1. Start Simple — Begin with basic panels, add complexity gradually
2. Reuse Components — Define components once, use in multiple panels
3. Modular Data — Keep data connections independent
4. Descriptive Names — Use clear names for panels and components

Development Workflow

1. Version Control — Commit configuration changes regularly
2. Preview Often — Regenerate and test frequently
3. Use Templates — Start from existing patterns
4. Document Custom Code — Explain any custom logic clearly

Team Collaboration

1. Clear Ownership — Who can modify configuration
2. Review Changes — Review config diffs like code
3. Shared Components — Build reusable component library
4. Communication — Discuss UI changes before implementing

See Also

• DDK Architecture — How FDK connects to data servers
• Building Workflows — Creating complete applications