WDG Playground - Architecture Overview

Solutions Architecture DocumentVersion: 1.0 Last Updated: October 2025 Author: WDG Solutions Architecture Team

Executive Summary

WDG Playground is a fully portable desktop application designed to democratize WordPress development with AI assistance. Built on Tauri 2.0, it embeds all necessary services (PHP, MySQL, Nginx, MCP server, vector database) into a single distributable package, eliminating the technical barriers that prevent designers, project managers, and strategists from leveraging modern AI-powered development workflows.

Problem Statement

The WDG AI Development Environment provides powerful AI-assisted WordPress development capabilities, but requires:

Docker Desktop installation (500MB+ download)
Command-line proficiency
Understanding of containers, volumes, and networking
Terminal-based workflows
System administration permissions

These requirements exclude 70%+ of the target audience who could benefit from AI-powered WordPress exploration and prototyping.

Solution

WDG Playground solves this by:

Bundling Everything - All services embedded in a single portable application
Zero External Dependencies - No Docker, no terminal, no system requirements
Visual-First Interface - Every operation accessible via intuitive GUI
Portable Execution - Runs from external drive, no installation required
Maintained Parity - Core features sync with WDG Dev Environment platform

Key Architectural Decisions

1. Tauri Over Electron

Decision: Use Tauri 2.0 instead of Electron

Rationale:

95% smaller bundle - 8MB vs 180MB (before adding services)
Native performance - Rust backend with system webview
Lower memory usage - ~50MB vs ~200MB at idle
Better security - Rust memory safety, restricted IPC
Cross-platform - Single codebase for Mac/Windows/Linux

Trade-offs:

More complex build setup (Rust toolchain required)
Smaller ecosystem vs Electron's maturity
Steeper learning curve for contributors

2. Embedded Binaries Over Docker

Decision: Bundle portable PHP/MySQL/Nginx binaries

Rationale:

Zero installation - No Docker Desktop dependency
True portability - Run from USB stick
Faster startup - Native processes vs container overhead
Simplified UX - Users don't need to understand containers

Trade-offs:

Larger bundle size (~200-300MB)
Platform-specific binaries to maintain (Mac/Win/Linux)
Manual process supervision required
Less isolation between services

Precedent: Local by Flywheel, MAMP, Laragon all use this approach successfully

3. TypeScript MCP Server (Node.js Sidecar)

Decision: Implement MCP server in TypeScript using Agent SDK, run as Node.js sidecar

Rationale:

Agent SDK integration - Use createSdkMcpServer() for native MCP support
Rapid development - TypeScript faster to develop than Rust
Ecosystem access - Full Node.js/npm ecosystem (@qdrant/js-client-rest, @xenova/transformers)
Easier maintenance - Same language as platform (TypeScript/JavaScript)
Lower learning curve - More developers know TypeScript than Rust

Trade-offs:

Additional process to manage (Node.js runtime ~40MB)
Slightly larger bundle size (~320MB vs ~280MB)
Node.js runtime startup overhead (~200ms)

4. Anthropic Agent SDK Over Custom Implementation

Decision: Use official Anthropic Agent SDK (TypeScript)

Rationale:

Production-ready - Proven infrastructure from Claude Code
Automatic context management - Prevents token overflow
Built-in tools - File operations, web search, code execution
MCP integration - Native support for Model Context Protocol
Official support - Anthropic maintains and updates

Trade-offs:

Dependency on Anthropic's SDK release cycle
Less control over low-level streaming behavior
Must adapt UI to SDK patterns

5. Single-Project Focus

Decision: Optimize for one active project at a time

Rationale:

Simpler UX - No mental overhead of managing multiple projects
Resource efficiency - Lower memory/CPU for target audience machines
Faster startup - Only start services for active project
Clearer context - AI assistant always knows which project

Trade-offs:

Users creating multiple projects need to switch between them
Can't compare/reference multiple projects simultaneously
Different from multi-project platform approach

High-Level Architecture

%%{init:{'theme':'neutral'}}%%
graph TB
   subgraph "WDG Playground App"
       subgraph "Frontend (React)"
           UI[Simplified UI]
           Chat[AI Chat Interface]
           Explorer[Visual Block Explorer]
           ProjectMgr[Project Manager]
       end

       subgraph "Tauri Backend (Rust)"
           IPC[IPC Bridge]
           ProcessMgr[Process Manager]
           GitMgr[Git Manager]
       end

       subgraph "Node.js Sidecar (TypeScript)"
           AgentSDK[Anthropic Agent SDK]
           MCPServer[MCP Server]
           Tools[MCP Tools]
           QdrantClient[Qdrant Client]
       end

       subgraph "Embedded Services"
           PHP[PHP 8.2]
           MySQL[MySQL 8.0]
           Nginx[Nginx]
           Qdrant[Qdrant Vector DB]
           Node[Node.js 20]
       end
   end

   subgraph "File System"
       Projects[(Projects)]
       Config[(Configuration)]
       DB[(Databases)]
   end

   UI --> IPC
   Chat --> IPC
   IPC --> AgentSDK
   AgentSDK --> MCPServer
   MCPServer --> Tools
   Tools --> QdrantClient
   QdrantClient --> Qdrant

   IPC --> ProcessMgr
   IPC --> GitMgr
   ProcessMgr --> PHP
   ProcessMgr --> MySQL
   ProcessMgr --> Nginx
   ProcessMgr --> Node
   Node --> AgentSDK

   PHP --> Projects
   MySQL --> DB
   Nginx --> PHP

Core Components

1. Tauri Application Shell

Technology: Tauri 2.0 (Rust + WebView)

Responsibilities:

Application lifecycle management
Window creation and management
System tray integration
Deep link handling (wdg-playground://)
Auto-update orchestration
Native file dialogs

2. React Frontend

Technology: React 18 + TypeScript + shadcn/ui

Responsibilities:

Simplified UI for non-technical users
AI chat interface with streaming
Visual project explorer
Block/plugin browser
Settings and configuration

UI Design:

shadcn/ui components matching WDG Dashboard
Tailwind CSS with dashboard design tokens
Lucide React icons
Consistent dark/light mode theming
Same color palette and typography as platform

Shared from Platform:

Markdown rendering component
Syntax highlighting
Design system (colors, fonts, spacing)
Tailwind configuration

3. Rust Backend

Technology: Rust with Tauri APIs

Responsibilities:

Process lifecycle management (start/stop/restart services including Node.js)
IPC bridge between React frontend and Node.js sidecar
File system operations
Git operations (via git2-rs)
Configuration management
System integration (file dialogs, notifications, auto-update)

4. Embedded Services

PHP 8.2:

Portable PHP binary (php-fpm)
Required extensions: mysqli, curl, gd, imagick, zip, xml
Configuration: optimized for single project

MySQL 8.0:

Embedded MySQL server (minimal configuration)
Single database per project instance
Automatic initialization on first run

Nginx:

Lightweight web server
Reverse proxy to PHP-FPM
SSL/TLS with self-signed certificates
Configuration generation per project

Qdrant:

Embedded vector database
Single collection per project
In-memory mode for performance
Persistent storage optional

Node.js 20:

Portable Node.js runtime (~40MB)
Runs TypeScript MCP server as sidecar process
Managed by Rust process supervisor
Communicates via HTTP/IPC with frontend

5. Node.js Sidecar (TypeScript)

Technology: Node.js 20 + TypeScript + Agent SDK

Responsibilities:

MCP server using Agent SDK createSdkMcpServer()
Anthropic Agent SDK integration
Qdrant vector search (@qdrant/js-client-rest)
Local embeddings (@xenova/transformers)
AI chat orchestration

6. AI Integration

Anthropic Agent SDK:

TypeScript implementation in Node.js sidecar
Streaming responses to React UI
Tool use via MCP integration
Automatic context management
Session persistence in SQLite

MCP Server (TypeScript):

search_codebase - Semantic search across project using Qdrant
search_functions - Find function definitions by name
search_classes - Find class definitions
search_wikit_blocks - Find Wikit Gutenberg blocks
Implemented using Agent SDK tool() and createSdkMcpServer()
Runs in Node.js sidecar process

Target User Personas

Primary Personas

1. Visual Designer (Sarah)

Goals: Explore Wikit blocks, create mockups, test layouts
Pain Points: Terminal intimidates her, doesn't want to "break" things
Needs: Visual interface, undo capabilities, safe experimentation

2. Project Manager (Marcus)

Goals: Demonstrate features to clients, plan technical scope
Pain Points: Doesn't code, needs to communicate with dev team
Needs: Quick prototypes, export/share functionality, clear visualization

3. Content Strategist (Elena)

Goals: Plan information architecture, test content structures
Pain Points: Limited technical knowledge, needs realistic environment
Needs: Custom post types, taxonomies, content modeling

Secondary Personas

4. Junior Developer (Alex)

Goals: Learn WordPress/Wikit patterns without complex setup
Pain Points: Overwhelmed by Docker, terminal, git
Needs: Guided workflows, examples, safety rails

5. Marketing Manager (Jennifer)

Goals: Create landing pages, test campaigns, preview content
Pain Points: Zero coding experience, needs quick turnaround
Needs: Templates, AI assistance, publish workflows

Key Differentiators

vs. Local by Flywheel

AI Integration: Claude agent built-in
Code-Aware: Vector search across all code
Framework-Specific: Optimized for Wikit
Git Integration: Visual git workflows

vs. WDG Dev Environment

No Docker: Everything embedded
Portable: Run from USB stick
Simplified UI: Non-technical focus
Single Project: Optimized for one at a time

vs. WordPress Playground (Wasm)

Native Performance: Real PHP, not WebAssembly
Full Extensions: All PHP extensions available
Persistence: Projects save between sessions
AI Features: Claude integration

Success Metrics

Technical Metrics

Startup Time: < 5 seconds to ready state
Memory Usage: < 500MB with project running
Bundle Size: < 300MB installed
Query Performance: Vector search < 100ms

User Experience Metrics

Time to First Project: < 2 minutes from download
Task Completion Rate: > 80% for common workflows
User Satisfaction: > 4.0/5.0 rating
Support Tickets: < 5% users need help

Business Metrics

Adoption Rate: Target 500+ active users in 6 months
Conversion Rate: 20%+ download-to-active-user
Platform Migration: 10%+ upgrade to full dev environment

Risk Assessment

Technical Risks

Risk	Impact	Probability	Mitigation
Binary compatibility issues across OS versions	High	Medium	Extensive testing matrix, fallback versions
Process management complexity	Medium	High	Robust supervision, health checks, auto-restart
Memory leaks in long-running services	Medium	Medium	Monitoring, automatic service restart
Vector database corruption	High	Low	Regular backups, rebuild capability
Rust MCP parity with Python	Medium	Medium	Comprehensive test suite, feature flags

User Experience Risks

Risk	Impact	Probability	Mitigation
Users expect full IDE features	Low	High	Clear positioning, educational content
Confusion with platform version	Medium	Medium	Distinct branding, clear documentation
Performance on older hardware	Medium	Low	Minimum system requirements, performance mode
Lost work from crashes	High	Low	Auto-save, session recovery, local backups

Future Roadmap

Phase 2 Features (Post-Launch)

Multi-project support (with project switching)
Cloud sync for projects (optional)
Collaboration features (share projects)
Plugin marketplace browser
Advanced git workflows (branching, merging)

Phase 3 Features

Local LLM support (CodeLlama, etc.)
Real-time collaboration
Deployment automation (push to hosting)
Theme/plugin development tools
Performance profiling

Conclusion

WDG Playground represents a strategic expansion of the WDG AI Development Environment ecosystem, targeting the 70%+ of potential users who need WordPress + AI capabilities but lack technical depth. By embedding all services in a portable Tauri application, we eliminate installation friction while maintaining the core value proposition of AI-assisted development with Wikit framework integration.

The architecture balances portability, performance, and user experience through careful technology selection (Tauri, embedded binaries, Agent SDK) and focused scope (single-project, visual-first interface). Success depends on maintaining parity with the platform while presenting a dramatically simpler interface.

Next Steps:

Review Technical Architecture for implementation details
Review User Experience Design for UX specifications
Review Implementation Roadmap for development plan

Document Status: Draft for Review Feedback: Please submit comments via GitHub Issues or internal Slack channel

WDG Playground - Architecture Overview ​

Executive Summary ​

Problem Statement ​

Solution ​

Key Architectural Decisions ​

1. Tauri Over Electron ​

2. Embedded Binaries Over Docker ​

3. TypeScript MCP Server (Node.js Sidecar) ​

4. Anthropic Agent SDK Over Custom Implementation ​

5. Single-Project Focus ​

High-Level Architecture ​

Core Components ​

1. Tauri Application Shell ​

2. React Frontend ​

3. Rust Backend ​

4. Embedded Services ​

5. Node.js Sidecar (TypeScript) ​

6. AI Integration ​

Target User Personas ​

Primary Personas ​

Secondary Personas ​

Key Differentiators ​

vs. Local by Flywheel ​

vs. WDG Dev Environment ​

vs. WordPress Playground (Wasm) ​

Success Metrics ​

Technical Metrics ​

User Experience Metrics ​

Business Metrics ​

Risk Assessment ​

Technical Risks ​

User Experience Risks ​

Future Roadmap ​

Phase 2 Features (Post-Launch) ​

Phase 3 Features ​

Conclusion ​

WDG Playground - Architecture Overview

Executive Summary

Problem Statement

Solution

Key Architectural Decisions

1. Tauri Over Electron

2. Embedded Binaries Over Docker

3. TypeScript MCP Server (Node.js Sidecar)

4. Anthropic Agent SDK Over Custom Implementation

5. Single-Project Focus

High-Level Architecture

Core Components

1. Tauri Application Shell

2. React Frontend

3. Rust Backend

4. Embedded Services

5. Node.js Sidecar (TypeScript)

6. AI Integration

Target User Personas

Primary Personas

Secondary Personas

Key Differentiators

vs. Local by Flywheel

vs. WDG Dev Environment

vs. WordPress Playground (Wasm)

Success Metrics

Technical Metrics

User Experience Metrics

Business Metrics

Risk Assessment

Technical Risks

User Experience Risks

Future Roadmap

Phase 2 Features (Post-Launch)

Phase 3 Features

Conclusion