I can recommend https://github.com/nkanaev/yarr which is also a single Go binary, consumes only 40 MB of RAM and uses SQLite as well.
Show HN: I built a tiny-VPS friendly RSS aggregator and reader
11–20 of 49 posts
Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#12I've been using Slack /feed (ugh) to get RSS notifications because I want pings from certain feeds. I have not found a different, easy lightweight way to do this.
Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#13Earlier quoted context omitted.
Hi. Just to clarify. > Node 21 with NPM > Sveltekit, shadcn-svelte The front-end things are used during the build process. You don't need them when deploy. > And the documentation literally specifies it requires docker. Fusion can be deployed as a *single binary*. Docker is just the recommended way. Maybe we need to make documentation clearer.
Looks good! I am curious on why you recommend to deploy using docker, being a single binary with no external dependencies I find the deployment simple enough. I write all my personal projects using Go and one of the things I most like is that it compiles to a binary without external dependencies.
That's mostly for Windows users.
The SQLite driver uses cgo, so we use both Ubuntu and Windows Server in CI to avoid cross-compiling. However, we still can't confirm that it's 100% ok on Windows. If any weird bugs occur on Windows, we don't have much experience or energy to deal with them.
The Docker image is based on Debian, we are more familary with it.
Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#14Looks really great. I can't tell from the readme, but can this produce its own feed which is the aggregation of the other feeds? That is the feature I always want and don't see too much with apps like this.
Hi, thanks for the suggestion! Currently it doesn't have that feature.
You can create an issue about it on GitHub so we can evaluate how much it is needed.
Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#15Earlier quoted context omitted.
> Node 21 with NPM > Sveltekit, shadcn-svelte > Echo, GORM > gofeed And the documentation literally specifies it requires docker. How did this become "minimal dependencies"?
Hi. Just to clarify. > Node 21 with NPM > Sveltekit, shadcn-svelte The front-end things are used during the build process. You don't need them when deploy. > And the documentation literally specifies it requires docker. Fusion can be deployed as a *single binary*. Docker is just the recommended way. Maybe we need to make documentation clearer.
It's an interesting difference in backgrounds, maybe? I tried to build this on OpenBSD where we don't have docker and we use 'make' instead of random shell scripts.
For what it's worth, this is from the build log:
error code 1
error path /home/holsta/3rdparty/fusion/frontend/node_modules/@sveltejs/kit
error command failed
error command sh -c node postinstall.js
error /home/holsta/3rdparty/fusion/frontend/node_modules/rollup/dist/native.js:84
error throw new Error(
error ^
error
error Error: Your current platform "openbsd" and architecture "x64" combination is not yet supported by the native Rollup build. Please use the WASM build "@rollup/wasm-node" instead.Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#16Earlier quoted context omitted.
> Node 21 with NPM > Sveltekit, shadcn-svelte > Echo, GORM > gofeed And the documentation literally specifies it requires docker. How did this become "minimal dependencies"?
The docs literally specify it doesn't "Deploy with a single binary"
It would be nice if people realised that not everything is Linux (or Windows or Mac).
Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#17Earlier quoted context omitted.
> Node 21 with NPM > Sveltekit, shadcn-svelte > Echo, GORM > gofeed And the documentation literally specifies it requires docker. How did this become "minimal dependencies"?
Almost guaranteed this doesn't build in ~2 years and you would likely need to know all of those languages to fix it.
I don't think it's that bad, but skimming that repo leaves me feeling like the frontend stack used makes things far more complex than they need to be.
Still, seems like a great project. I added it to my list of things to check out whenever I have a free weekend... if I ever get there.
Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#18Earlier quoted context omitted.
Looks good! I am curious on why you recommend to deploy using docker, being a single binary with no external dependencies I find the deployment simple enough. I write all my personal projects using Go and one of the things I most like is that it compiles to a binary without external dependencies.
That's mostly for Windows users. The SQLite driver uses cgo, so we use both Ubuntu and Windows Server in CI to avoid cross-compiling. However, we still can't confirm that it's 100% ok on Windows. If any weird bugs occur on Windows, we don't have much experience or energy to deal with them. The Docker image is based on Debian, we are more familary with it.
That makes a lot of sense, thanks for taking the time to explain it.
Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#19Looks cool! I'm currently using Selfoss, which is fine in terms of requirements/maintenance, but if I didn't, I'd probably give this a try!
Re: Show HN: I built a tiny-VPS friendly RSS aggregator and reader
#20Earlier quoted context omitted.
> Node 21 with NPM > Sveltekit, shadcn-svelte > Echo, GORM > gofeed And the documentation literally specifies it requires docker. How did this become "minimal dependencies"?
Almost guaranteed this doesn't build in ~2 years and you would likely need to know all of those languages to fix it.
Encountered the same problem last year. My tech stack was React Native as I was mostly building stuff that has few interactions and it was easy to get something good on both platforms. Then, I got a notice from Google about API version. Updating the project was such a nightmare due to compatibility issue. Some libraries were abandoned. Some had breaking changes. It was easier to write the two native versions than to deal with npm mess.