Skip to content
Crosswalker
🚧 Early alpha — building the foundation. See the roadmap →

Obsidian app internals — research needed

Created Updated

Why this matters

Section titled “Why this matters”

Crosswalker needs to understand Obsidian’s internal architecture to know what’s possible and what’s limited. The distribution architecture identified that ~50-60% of our codebase is pure logic, but the plugin wrapper depends on Obsidian APIs that have constraints.

Research questions

Section titled “Research questions”

App lifecycle and rendering

Section titled “App lifecycle and rendering”
  • What’s the main event loop? (Electron → Obsidian app → plugin lifecycle)
  • When does app.vault become available?
  • How does the MetadataCache update? (sync vs async, debouncing)
  • What triggers re-renders of notes in reading/live-preview mode?
  • How do frontmatter changes propagate to Properties UI, Bases, Dataview?

File operations

Section titled “File operations”
  • Is app.vault.create() synchronous or async?
  • What happens if you create 1000 files rapidly? (throttling? queue?)
  • How does Obsidian handle file rename cascading (WikiLink updates)?
  • What’s the performance ceiling for vault operations? (files/second)

Plugin constraints

Section titled “Plugin constraints”
  • What’s the maximum main-thread blocking time before Obsidian warns?
  • Can plugins use Web Workers for heavy computation?
  • How do plugins communicate with each other? (global namespace? events?)
  • What’s the Obsidian API surface that ISN’T documented?

For Crosswalker specifically

Section titled “For Crosswalker specifically”
  • Can we show progress during long imports? (Notice API limitations)
  • Can we use processFrontMatter on 1000+ files without freezing?
  • How do modal interactions work with async operations?
  • What are the performance implications of generating large folder trees?

Resources to investigate

Section titled “Resources to investigate”
Section titled “Related”