Hosted onhoraciohdev.dev.hyper.mediavia theHypermedia Protocol

Where Should Board State Live?Board State Persistence: Board Document vs Distributed Document Attributes

We have two persistence alternatives:

    Board-owned Seed document at a reserved hidden path

    Store the Board state in one hidden document, for example:

    /.seed/board

    This document owns the Board query, columns, ordering, and per-card workflow metadata.

    Attributes on referenced card documents

    Store Board-specific data directly on each document that appears as a card.

    For example, each referenced document would carry its own column, priority, labels, assignees, or other Board metadata.

Option 1: Board-owned hidden Seed document

Pros:

    One place to load/save Board state.

    The Board owns its query, columns, layout, labels, priorities, and card overrides.

    Works well when cards come from many different document paths.

    Supports multiple Boards cleanly.

    Moving a card does not mutate the referenced document.

    Board history is separate from document content history.

Cons:

    We need a reserved hidden path, for example /.seed/board.

    We need to define how the JSON state is encoded in a Seed document.

Option 2: Store Board data as attributes on referenced documents

Pros:

    The workflow metadata travels with the document.

    It is easy to ask “what Board-like metadata does this document have?”

Cons:

    It pollutes normal documents with app-specific Board state.

    It becomes awkward when the same document appears on multiple Boards.

    Moving a card would create a document change, even though the document content did not change.

    Permissions get confusing: editing Board layout would require editing every referenced document.

    Loading a Board means reading many document attributes instead of one Board state.

    Removing a Board would require cleaning metadata from many documents.

The decisive issue is multiple Boards.

If one document can appear on two Boards, this is ambiguous:

{ "boardColumn": "review", "priority": "High" }

Which Board does that belong to?

You could namespace it:

{ "boards": { "hm://site/.seed/board": { "columnId": "review", "priority": "High" }, "hm://site/.seed/roadmap-board": { "columnId": "backlog", "priority": "Low" } } }

But then you are spreading Board state across many documents, which makes loading, deleting, migrating, and permissioning harder.

Recommended model:

/.seed/board owns query owns columns owns per-card board overrides keyed by document id

Referenced documents stay clean:

/design/foo owns its own content and metadata only

So the Board render becomes:

Board state + Query results = Board UI

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime