mirror of
https://github.com/Comfy-Org/ComfyUI_frontend.git
synced 2026-02-05 23:50:08 +00:00
ca43f90c93
- Remove unnecessary types/README.md file - Revert unrelated changes to services/README.md - Keep only relevant documentation for the layout system implementation These were issues identified during PR review that needed to be addressed. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
8.9 KiB
8.9 KiB
Graph Architecture Evolution
A visual journey through the architectural transformation of ComfyUI's graph system.
Slide 1: Traditional LiteGraph Architecture
┌─────────────────────────────────────┐
│ LiteGraph Node │
│ ┌─────────────────────────────┐ │
│ │ • Data (inputs/outputs) │ │
│ │ • UI (position, size) │ │
│ │ • Rendering (draw methods) │ │
│ │ • Interaction (mouse) │ │
│ │ • Business Logic │ │
│ └─────────────────────────────┘ │
│ │
│ Everything tightly coupled in │
│ a single monolithic structure │
└─────────────────────────────────────┘
Problem: All concerns mixed together - data, UI, rendering, and interaction are inseparable.
Slide 2: Separation of Concerns
┌─────────────────────┐ ┌──────────────────────┐
│ Graph Data Model │ │ Layout Tree │
├─────────────────────┤ ├──────────────────────┤
│ • Node connections │ │ • Node positions │
│ • Input/output data │ │ • Node sizes │
│ • Execution state │ │ • Z-index/stacking │
│ • Business logic │ │ • Visibility states │
│ │ │ • Bounds/spatial │
│ Pure data structure │ │ Pure UI structure │
│ No UI concepts │ │ No business logic │
└─────────────────────┘ └──────────────────────┘
Benefit: Clean separation - graph logic vs presentation concerns.
Slide 3: Multiple Renderer Support
Layout Tree
│
┌────────────────┼────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Canvas Render│ │ Vue Render │ │ Three.js 3D │
├──────────────┤ ├──────────────┤ ├──────────────┤
│ │ │ │ │ │
│ [Canvas] │ │ <Component> │ │ [WebGL] │
│ │ │ </Component> │ │ │
└──────────────┘ └──────────────┘ └──────────────┘
┌────────────────┼────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Native iOS │ │Native Android│ │ Terminal │
├──────────────┤ ├──────────────┤ ├──────────────┤
│ UIKit │ │ Compose │ │ ASCII │
└──────────────┘ └──────────────┘ └──────────────┘
Power: Same layout tree, infinite rendering possibilities.
Slide 4: Alternative UI Paradigms
Graph Data Model
│
├─────── With Layout Tree ─────► Traditional Node UI
│
└─────── Without Layout ───────┐
▼
┌──────────────────┐
│ Form-Based UI │
├──────────────────┤
│ ┌──────────────┐ │
│ │ Input Fields │ │
│ ├──────────────┤ │
│ │ Sliders │ │
│ ├──────────────┤ │
│ │ Buttons │ │
│ └──────────────┘ │
│ │
│ Like Gradio/A1111│
└──────────────────┘
Flexibility: Renderers can interpret the graph data model however they want.
Slide 5: Service Architecture
┌─────────────────────┐ ┌──────────────────────┐
│ Graph Mutations │ │ Layout Mutations │
│ Service │ │ Service │
├─────────────────────┤ ├──────────────────────┤
│ • addNode() │ │ • moveNode() │
│ • connectNodes() │ │ • resizeNode() │
│ • updateNodeData() │ │ • bringToFront() │
│ • executeGraph() │ │ • setVisibility() │
└──────┬──────────────┘ └──────┬───────────────┘
│ │
▼ ▼
┌─────────────────────┐ ┌──────────────────────┐
│ Graph Gateway │ │ Layout Gateway │
│ (Interface) │ │ (Interface) │
└─────────────────────┘ └──────────────────────┘
Clean APIs: Well-defined interfaces for all operations.
Slide 6: Deployment Flexibility
┌────────────────────────────────────────────────┐
│ Graph Data Model │
│ Layout System │
│ Service Layer │
└─────────────┬───────────┬───────────┬──────────┘
│ │ │
Local │ Cloud │ Native │ Hybrid
▼ ▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│Browser │ │ AWS │ │ iOS │ │Electron│
│ │ │Lambda │ │ App │ │ + │
│ Yjs │ │ + │ │ + │ │ Rust │
│ CRDT │ │GraphQL │ │ Swift │ │Backend │
└────────┘ └────────┘ └────────┘ └────────┘
Because everything is behind interfaces, easily switch implementations without major development effort:
• Move graph execution to GPU cluster
• Run layout calculations in WebAssembly
• Store state in any database
• Sync across any network protocol
Ultimate Flexibility: Plug and play any component, deploy anywhere.
Summary
By separating concerns and defining clear interfaces:
- Data Model → Pure business logic, no UI
- Layout Tree → Pure spatial data, no logic
- Renderers → Consume what they need
- Services → Clean mutation APIs
- Gateways → Swappable implementations, automatically map across differing API versions or schemas
This architecture enables:
- Multiple simultaneous renderers
- Alternative UI paradigms
- Cloud/edge/native deployment
- Real-time collaboration
- Time-travel debugging
- Performance optimization per layer
- Better performance for state observers and undo/redo
The key insight: When you separate concerns properly, everything becomes possible.