Hacker News Reader

Comment by l0b0 | Hacker News Reader

Great idea! Some feedback:

- The 24 hour horizon means you could get away without namespace functionality like categories entirely, especially when self-hosting for a small-to-medium-sized group.

- It's tiring to read sites with all monospace fonts. I can see how it might be useful if most posts contain a lot of code, though.

- Do you expect this to be open sourced?

View on HN

As I said below, after several returns I've updated the site and removed the automatic deletion feature after 24h but I'm thinking of adding an option when creating a post. Thanks for your feedback, and I don't think it will be open source for the time being! If the site is doing well and there's a lot of demand for it, why not rethink!

Wow, been thinking about creating the same thing for a while now. What did you build it with? I'd definitely love to see some of the code!

Tbh the 24 hour horizon also means that you can do without a persistent db and store everything in memory (as managed db are typically the most complex / expensive part of the stack)

Only if you’re ok with an empty page after server restart.

If it'a controlled restart, you can dump your memory onto a file when shutting down, then reload the dump when you restart. If it's a crash, yes, you will lose everything. Or you can do Append Only File persistence like Redis, in which case you won't lose anything in each case.

> dump your memory onto a file when shutting down, then reload the dump when you restart

To me this sounds like building your own db but worse.

Agree for the dump idea, but AOF persistence is quite easy to do (literally open a file and append).

Of course you'll have to choose the right data structures in memory, but that can be ad hoc to your app, so considerably less complex than a general purpose database.

The only problem is when you go out of memory, but if you have an eviction strategy (i.e. a 24 hours life per post), you don't need to scale for a long time.

We’d still need code to load the data back, also to continously test that code (or debug in production), plus handle data migrations. There might be more use cases. Using a regular db might be simpler at this point, depending on the project’s setup.

Loading the data back is just reading the log file and applying every record one after the other (ignoring records outside the time horizon). Sure you will need to maintain the code, but it's not as complex as writing a database from scratch, as you suggested.

Reply on news.ycombinator.com