Comfy-Org/ComfyUI_frontend
1
0
Fork 0
mirror of https://github.com/Comfy-Org/ComfyUI_frontend.git synced 2026-02-28 18:54:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix: Remove unnecessary README files and revert services README

Browse Source 
- 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>
This commit is contained in:
bymyself
2025-08-13 01:09:34 -07:00
parent a8dbe05749
commit ca43f90c93
3 changed files with 429 additions and 211 deletions
Download Patch File Download Diff File Expand all files Collapse all files

177
docs/architecture/graph-architecture-evolution.md Normal file
View File

@@ -0,0 +1,177 @@
# 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.**