Skip to content

Thoughts about Prejournal architecture #173

@michielbdejong

Description

@michielbdejong

Even though Prejournal is still very young, we use it as an R&D project so it has cycled through a few designs already.
Prejournal started as a collection of commands that can:

  • 1: convert source documents to a REA-like representation of the world
  • 2: generate bookkeeping journals from that representation

We soon added:

  • 3: generate export documents in other formats
  • 4: convert smaller bits of data (essentially one-liner source documents) to a REA-like representation of the world
  • 5: persist the REA-like representation in a database.

With these additions, Prejournal can be run as a server instead of as a script.
The way we use Prejournal for our own bookkeeping at Ponder Source, we still basically run it as a script from source documents.
This sometimes clashes with the expectations of others who use https://time.pondersource.com as a server with an API.
For instance, each time we our source documents change, we regenerate the database contents from scratch, and this means items that were added from other sources may be lost, or items may be renumbered.

A third way to use Prejournal would be as an event-sourced hosted application, so that all edits get logged, and that log then becomes our source document store.

It's probably best if we refactor Prejournal to that architecture, but I'm still trying to think the consequences of that through properly, and working out what the best timing for that would be.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions