Rustfava and extensions

[mescanne]

Context: I have 10+ years of history now converted into beancount, self-hosted and managed with a Fava instance. I would like to invest in a future platform.

What is the view of Rustfava for extensions? I am building some Fava extensions to support importing from APIs. They are all in JS / Python. Would the focus be more on using native rustledger importers (e.g. WASM based?). The current beancount importing technique is not well suited for APIs.

[robcohen]

Thanks for asking, and good that you're thinking long term before committing your data.

Straight answer: rustledger is the core of my work and it's going to be around. rustfava isn't. It's a demo to show rustledger running in the GUI the beancount community already uses. I don't plan to maintain it forever. The longer term plan is a purpose built GUI on top of rustledger, not a Fava fork. So building heavily on rustfava's extension API is building on a bridge.

The place to invest is rustledger itself, and importing is exactly where your experience would help. It already has a native Rust import framework (rustledger-importer): CSV with column inference, OFX/QFX, a dispatch registry, and WASM bindings. It's still file oriented today, so you're right that the classic beancount model is a poor fit for APIs. That gap is unsolved there too, which is why I'd want your input.

Suggested next steps:

• Read the import architecture and roadmap docs.
• Look at #923 (IBKR importer).
• Open an issue describing what a good API import surface looks like, and where file-identify-extract breaks down for APIs.

Keep your Fava extensions on rustfava if they're useful now, but if you're investing for the future, invest in rustledger.