Nevkontakte
@me@m.nevkontakte.com
Lawful neutral. Definitely not a cat in a hat. Opinions are of Cthulhu. what/why.
In 3 days Pocket is shutting down, so it's high time to worry about a replacement, if you haven't already. I know a lot of folks took this as a cause to try more sophisticated knowledge management apps (hey @obsidian@mas.to 
).
Personally, I was looking to keep the experience of the simple reading stack. And boy, @readeck@mastodon.online is exactly what I was looking for, and better than I was hoping for:
- Open source, written in Go, simple frontend stack.
- Self-hosted, tiny resource footprint, very snappy.
- Does exactly what Pocket used to do, without any of the "discover random shit" nonsense.
- Browser extension and neat workarounds for mobile OSes that make saving pages for later quick and easy. This was where a lot of alternatives fell through for me, saving links was just too fiddly.
- Works equally well on desktop and mobile, supports PWA.
- Pretty well functioning readable mode! And if I find something that doesn't work I could actually go and patch it, if I care enough. Pocket tends to swallow or mangle code blocks more often than not, which was a big pain.
Last but not least, it can import your data from Pocket, so migration is pretty smooth. It did take a few hours to chew through ~2500 articles I've apparently saved over the years, since it had to fetch the links and re-extract the content. This is actually one gripe I have with the Pocket export: it just gives you a CVS with links and light metadata, but it doesn't export the saved article content. If you have a 10 year old link in there somewhere, ~pray~ donate to web archive gods that it has been saved there. If you care.
One thing that I wish worked differently is that it splits its state between database (SQLite or Postgres) and disk. I kind of wish everything went into the database, so that can be backed up together with the rest of Postgres index, but beggars can't be choosers. I'll take it.
@readeck@mastodon.online disclaimer: what follows below is my particular form of insanity and doesn't claim to be a rational software design choice. You are under no obligation to share it 
Conceptually, I am very attracted to the idea that all the data I care about is neatly stored in one place, for example in a database, which just happened to be Postgres for me. Primarily because that makes backups trivial - I don't have to think about all the paths that need to be backed up or restored, just dump the whole database, and store it away. If I am looking at using Readeck (or any other software) in isolation, it doesn't apply, but when we are considering managing a collection of services, it becomes more of an inconvenience that each of them wants a different database.
Now, is it a bit deal? No, not really, SQLite would work just as well for me. And even if I have a dozen different apps each with its own SQLite database, it's still not too hard to write a script that backs them all up. I'll have to remember to update it every time I add something, but we aren't talking about thousands of them. The only victim is my sense of elegant 
Maybe a slightly more rational argument could be related to splitting the state between the database and file system: making an consistent backup becomes harder without resorting to custom mechanisms. Admittedly, it would only be a serious consideration for large multi-user instances where state changes happen multiple times a second. On my personal instance I can just copy all the files at 3am, and the odds of inconsistency are really slim.
I'm not sure that serving from the file system is necessarily such a performance win, https://www.sqlite.org/fasterthanfs.html suggests that storing blobs in the database might be just as viable, but the balance may change with networked databases like Postgres.
@me I actually tested this by implementing sqlar and, even though it's good, it doesn't beat opening a file and copying data from some position to a writer.
And the sqlite driver Readeck uses doesn't provide the functions to read directly from a blob (sadly) and you end up with your 30Mb image in RAM before you can send it :)
My point was: with sqlite, your whole dataset is one folder and that's it. Plus, having a collection of files gives you the benefit of deduplication.
@me That said, I get your point and I actually agree. Only, if I have to choose between performances and backup convenience (on the hottest path), it's an easy choice :)
PS: the import / export commands are mostly there when you need to move from pg to sqlite or the other way around (and for portability). You can still use pg_dump, it'll work the same
@me thanks :) If I may, unless you plan to have a lot of users or must store files on NFS or CIFS, just use SQLite and you'll get all your files in one place :)
I would be a big performance hit to store files in the database since everything is served directly from the zip files that Readeck creates.