Hacker News Reader

Comment by emptysea | Hacker News Reader

Search is really quick and a look under the covers shows it’s using algolia + s3 for images

To be fair, if you manage to make search slow for a database with ~10,000 entries, you're doing something very strange. Even allowing for egregious post-sizes of 100Kb/entry, that's less than 1 Gb. A raspberry pi could keep the database in RAM with room to spare.

Full text search is tricky no matter how small the dataset is. But yes the speed should be instantaneous as long as you use standard FTS solutions.

It really isn't. You could have implemented this site using a single MySQL LIKE query and it would have been equally performant. Or even download the full dataset to the client on page load and do the search locally in JavaScript. The problems all arise when you need to scale.

> Or even download the full dataset to the client on page load and do the search locally in JavaScript.

That's exactly what I did for a recent hobby project of mine[0]. In my case, I've a db of 30K entries with gzipped size of ~600kb. This serves well for the few hundred visitors I get every day.

[0] https://theshowgrid.com/

Using like operators isn’t full text search. It won’t find results where the words you typed are switched around for example. It wont even work if you accidentally put double spaces. This could work for a toy project but for any respectable app, using like as the search operator will suck. Not to mention it’s unscalable.

> Not to mention it’s unscalable

How does this affect anything in a discussion about an explicitly fixed scale problem?

It is quick, but it also looks faster than it is because of the way they're animating the rows as you type. At the end of the day it's still taking the full 300ms or whatever to load the images from S3, and without all the extra jitter it would look kind of janky.

Reply on news.ycombinator.com