So I built a search engine for personal blogs. Feel free to submit your blog's RSS feed here: https://rawweb.org/feeds

Tailscale or pure WireGuard is cool.

https://github.com/usememos/memos is perfect for using as a link blog

RSS is my main source of information. And I've built some RSS-related projects:

1. https://github.com/0x2E/fusion - A lightweight, self-hosted friendly RSS aggregator and reader

2. https://rawweb.org/ - A search engine for indie websites (the crawler collects data from RSS feeds)

3. https://github.com/0x2E/rss-finder - A tool for finding the RSS link of a website

Same for me, and would like to add my own list

1. https://lighthouseapp.io/ - feed reader combined with bookmarking

2. https://lighthouseapp.io/tools/feed-finder - tool to find RSS feeds (https://lighthouseapp.io/blog/deep-dive-finding-rss-feeds)

3. https://lighthouseapp.io/tools/newsletter-to-rss - tool to convert newsletters to RSS feeds

Also: https://kill-the-newsletter.com for use case 3. Free service with no signup that works reliably.

Nice list. I tried at some point to analyze html using a tree-sitter grammar and generate a list of articles, index them, and be on alert every so often for new entries.

RSS feed could be generated automatically with some AI code generator (or tree-sitter query generator), and just parsing the elements of the page.

Eventually i failed, but also i didn't try hard enough.

Rawweb is very cool! Curious, have you implemented your own crawler, RSS parser and search engine?

Crawler is a simple HTTP requester + RSS parser. Full-text searching uses Elasticsearch.

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.

You can custom the page size by params in url ( ?page_size=1000).

But large page size can cause page performance problems.

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.

It seems like the compiler used in project's front-end framework doesn't support OpenBSD.

There is nothing we can do about it at the moment. Maybe in the future we will change the tech stack to reduce the complexity of the front-end.

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.

For the SQLite driver, check out the one by modernc for pure Go

That makes a lot of sense, thanks for taking the time to explain it.

Why recommend Docker if it's a single binary?

And what's good about a single binary if you're going to recommend Docker?

Here: https://news.ycombinator.com/item?id=40525683

it's still easier to manage docker containers if they're 50 MB instead of 300MB and if the rest of the fleet is being managed via docker-(whichever) then there's something to be said about consistency. managing everything through one interface is easier than remembering all the special cases. but to each their own.

The image is 200 MB... There's 100 packages in there, including bash, perl, ext filesystem utilities, and the APT package manager.

Compared to all that, the current PHP app I use for RSS looks lighter. Especially since my VPS already runs PHP and PostgreSQL.

You can use the standalone binary (18 MB) to run it. Docker is just one deployment method.

But then why...

Hold on, I'm back to my earlier comment.

I don't even like docker, but it still doesn't sound that terrible to me. It's an option. Use docker or use the single binary, but presumably if you like docker and have it set up for other things, you'll just use that rather than rolling your own startup scripts etc.

I do something a bit similar for my own project - it's a single binary REST server, but I still package it up with dpkg-deb and deploy that to a private apt repo so I can update it easily on the servers with "apt-get update && apt-get install blah" and that fits nicely with my existing processes and I can just add the repo and dependency to my cloud-init setup. If I used docker, I'm sure I'd find his docker image the easiest path to getting it installed and updated.

The emphasis in my questions above was on recommend.

Consistency is key. it's easier if you're using docker to run all the things, then docker ps shows all the things running, instead of having to check docker, and then also check this other thing over here that's different