Reference

Feature Flow Catalog

Look up syntax, contracts, layouts, algorithms, and exact behavior.

A LiveBoard feature belongs in the architecture when it has a clear route through the system: one obvious frontend owner, one obvious backend contract, one durable state owner when persistence is needed, and one realtime story when collaborators are affected. The following catalog summarizes those routes.

signup/login
  AuthScreen -> /api/auth/signup or /api/auth/login -> sessions -> dashboard

create canvas
  Dashboard -> POST /api/canvases -> canvases + owner membership -> rename modal

create nested folder
  Dashboard/FolderModal -> POST /api/folders(parentId) -> canvas_folders

move canvas into folder
  drag/drop -> PATCH /api/canvases/:id/folder -> canvases.folder_id

move folder into folder
  drag/drop -> PATCH /api/folders/:id/parent -> canvas_folders.parent_id

reorder mixed siblings
  insertion zone drop -> PATCH /api/dashboard/order -> sort_order rewrite

share canvas
  ShareModal -> POST /api/canvases/:id/invite -> canvas_members

delete folder subtree
  ConfirmModal -> DELETE /api/folders/:id -> folders, canvases, sockets closed

Dashboard feature flows. Dashboard features use HTTP because they are resource-management actions rather than high-frequency live canvas edits.

draw
  pointer draft -> create_shape -> PostgreSQL revision -> op_applied

move/resize/rotate
  local optimistic preview -> preview_op fanout -> pointer-up durable op

multi-select or group transform
  combined bounds -> batch preview -> batch durable op -> one undo step

style change
  toolbar control -> update_shape or batch -> server-derived inverse

text edit
  inline textarea draft -> update_shape on commit -> one history entry

paint bucket
  shape click -> update_shape fill patch
  background click -> update_canvas backgroundColor

z-order action
  context menu -> reorder_shape -> shapes array order changes

undo/redo
  toolbar/shortcut -> websocket undo/redo -> server history -> op_applied

Editor feature flows. Editor features use WebSockets when collaborators should see the result live and use the same durable operation pipeline when the result should be saved.

cursor movement
  canvas coordinates -> cursor message -> Redis fanout -> inverse-scaled remote cursor

durable op miss
  client observes revision gap -> GET /api/canvases/:id -> replace local state

rate-limited write
  backend rejects before persistence -> rate_limited snapshot to sender
  peers receive preview_reset -> refresh durable state

access removal
  DELETE member row -> Redis invalidation -> access_removed -> socket close

server scale-out
  any replica handles HTTP/WS -> PostgreSQL serializes writes
  Redis fans out transient and committed room events

Realtime and recovery flows. Recovery flows are explicit product behavior, not incidental error handling. They keep the editor understandable when the network or rate limiter interrupts normal collaboration.

Feature Flow Catalog

Continue exploring