mirror of
https://github.com/Comfy-Org/ComfyUI_frontend.git
synced 2026-02-28 10:44:12 +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>
177 lines
8.9 KiB
Markdown
177 lines
8.9 KiB
Markdown
# 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:
|
|
|
|
1. **Data Model** → Pure business logic, no UI
|
|
2. **Layout Tree** → Pure spatial data, no logic
|
|
3. **Renderers** → Consume what they need
|
|
4. **Services** → Clean mutation APIs
|
|
5. **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.** |