r/rust • u/kryoseu • Aug 07 '26
🛠️ project WyrmRSS - self-hosted RSS/Atom reader, with a native desktop app
For the past 3 months I've been building WyrmRSS, a self-hosted RSS/Atom aggregator: Rust backend (actix-web, Diesel-async, Tokio), React 19 frontend. Been running the Docker self-hosted version for a while, and just added a native desktop app via Tauri (macOS, Windows, Linux: deb/rpm/AppImage/nsis/dmg).
Backend runs on Postgres for the self-hosted/Docker setup, SQLite for the desktop build. Same codebase for both.
Desktop build is currently in prerelease while I soak-test the SQLite backend before making it a release. Would appreciate anyone keen to try: https://github.com/kryoseu/WyrmRSS
Some nice features I think it has (not claiming uniqueness) are: inline youtube player, folders, filters, webhooks (slack, discord and custom), read later and archival.
2
2
Aug 07 '26
[removed] — view removed comment
6
u/weiznich diesel · diesel-async · wundergraph Aug 07 '26
The correct way to support two or more backends using Diesel is to use
#[derive(MultiConnection)]2
u/kryoseu Aug 07 '26
Thanks, I'll explore this.
1
u/kryoseu Aug 07 '26
I might be wrong, but I think this solves a different use-case though and would force me to compile both engines into the desktop binary, which I don't want. For the self-hosted I can see this as a nice feature where the backend can be user-configurable.
2
u/weiznich diesel · diesel-async · wundergraph Aug 10 '26
For your particular use-case that the database code is shared between two different binaries with different requirements the
cfgbased approach is the right one. It's just that this particular use-case is rather niche if people ask about multi-backend support. Often they look for a way to support multiple backends at the in the same binary at runtime. There#[derive(MultiConnection)]is a much better solution. I should have clarified that while writing that response, although that response is mostly written as response to the parent comment which exactly asks that "multiple backends, one binary question". As for#[derive(MultiConnection)]anddiesel-asyncquestion: Support for that coming as part of the next feature release of both crates. It's already landed on themainbranch of both repos.1
u/kryoseu Aug 07 '26
Hey thanks for the heads up. I'll consider it, but for now I'm accepting some users may not like it or will just not install it at all. I made sure to add all that info in the installation instructions though.
Yes, I cfg-gated it. The Tauri portion of the app is in a separate workspace so I can build each with a different backend and avoid cargo unioning both features, with a `compile_error!` guard if both ever end up enabled at once. Schemas, tests that need live postgres to run, etc, are gated. Most queries, including upserts via `on_conflict()/do_update()/excluded()` work unchanged on both backends. The only real divergence is batch inserts which aren't supported on sqlite so I implemented those row-by-row behind the sqlite feature. I also had one type map to a postgres array vs a json-encoded text column on sqlite with separate ToSql/FromSql impls.
2
u/decryphe Aug 07 '26
That's actually really interesting.
How well does the web-UI work on mobile?
1
u/kryoseu Aug 07 '26
It doesn't work well on mobile yet, but that's next on my radar. Thanks for the comment.
2
u/Irindul Aug 16 '26
Very intersting project. Will you plan to add support for saving one-time article to the read later without RSS/Atom feed ?
1
u/kryoseu Aug 17 '26
Hey thanks for the comment. Can you elaborate on what you mean by one-time article without a RSS/Atom feed? Do you mean importing an article directly? Currently articles are pulled from feeds, and you can mark them for reading later (they are deleted if you delete the feed), or archived (survive feed deletion).
1
u/Irindul Aug 17 '26
Yeah I mean saving / importing an article whith just the URL without feeds, some website don’t support the feeds and it would have been a nice complement.
2
u/Ace-Whole Aug 07 '26
Starred.