Modular Architecture

[alensiljak]

I would suggest a modular design of the application, to provide multiple benefits to the end-users.

There is already discussion about a separate parser crate (#11) as there is a need for that specific functionality. In line with this, I would suggest that we have different components that can interact together but also be utilized on their own.

Different components of the system may be useful for the full ecosystem and the community.

One interesting aspect is JavaScript/WASM interop, so having the library/API available (that the CLI calls into) would be perfect. For the same reason, introducing/separating the output formatters.

Approximate idea:

[rcaputo]

I for one would like a parser library I could reuse in tools.

But this is more a response to your need for a diagramming tool. github has diagramming built in: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams

[alensiljak]

Thanks for the tip!
I was under the impression that draw.io can publish but I guess I was wrong. Collaboration tool requires a totally new environment setup. :)
The Mermaid flowcharts are ok but I'd like to have some UML elements. In this case Components.
I could add the draw's xml file but it is cumbersome to work with files, I guess.

[alensiljak]

Your suggestion prompted me to look at the text-based UML tools again (plain-text diagramming! :) and I finally spent some time to check out the PlantUML syntax. It would be great if that worked with GitHub somehow.

[alensiljak]

Indeed!

[g-duff]

Hello, a rust newbie and interested observer here!

I, for one, would re-use the "core" library - I think "lib" in the diagram? It's these core business rules that pique my interest.

I also wonder if the lib must depend on the parser, or could a more composition-based approach be taken? Eg would this parser be required for external apps or could external apps only want to call "core business rules" with data from some other source (eg from a database, structured/form input on a webpage, etc...)?

A quick sketch...

graph TD;
    id1[external app]-->id2[ledger lib];
    id3[ledger CLI]-->id2[ledger lib];
    id3[ledger CLI]-->parser;
    id3[ledger CLI]-->id4[output formatter];

Loading

Forgive me if this was already the plan, or is simply unfeasible.

[alensiljak]

Hi and welcome!

It's these core business rules that pique my interest

Could you elaborate just a bit. I'd be interested to know how you'd build upon the lib. It would make another use-case to consider.

For example, I would like to call the same API from a JavaScript application in a browser and display the results directly, avoiding a need for console.

would this parser be required

For now, I've just used the lib as a placeholder for "everything else" and will likely be broken down further in any design docs. For now it simply means that it is testable through an API instead of console, so the integration tests are easier. But also integration with other systems. As Rust has a pretty good FFI, it would mean that it can be called from Python, C, JavaScript...

Forgive me if this was already the plan

There's no big plan as of yet. Just a bunch of ideas, looking to be shaped into something concrete and having fun along the way! ;)

[alensiljak]

Forgot to refer to the main point about the parser. The parser is required to transfer the Ledger file (plain text) into a structure that the program can work with. Let's say a list of transactions with postings. Then, from this list, the reports are calculated.
Put like that, the parser is a necessary part of the lib's functionality. Of course, if we make the whole thing more generic (using interfaces/traits), it might be possible to switch parser components, or others, too.

[g-duff]

Yes to the last bit! I would vote in favour of good ol' dependency inversion where possible, especially for loading/parsing data.

For external use-cases I had in mind: generating local plots (like ledger-cli/gnuplot, but straight to, say, plotters without the intermediate output file) and using the core reporting logic to process transactions in other formats/pre-existing databases, where loading data would be the consumer's responsibility.

Happy to take part in any case, and looking forward to seeing how the design conversations progress :)