4 ms·

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

Alex3917 4y ago
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.
marginalia_nu 4y ago
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.
- ramraj07 4y ago
  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.
  - paxys 4y ago
    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.
    - maxwelldone 4y ago
      > 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/ https://theshowgrid.com/
    - ramraj07 4y ago
      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.
      - marginalia_nu 4y ago
        > 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.

marginalia_nu 4y ago

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.

ramraj07 4y ago
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.
- paxys 4y ago
  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.
  - maxwelldone 4y ago
    > 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/ https://theshowgrid.com/
  - ramraj07 4y ago
    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.
    - marginalia_nu 4y ago
      > Not to mention it’s unscalable How does this affect anything in a discussion about an explicitly fixed scale problem?