It's mentioned in this post but lunr.js is a clever option if you don't have much content. The idea is that your search page has to create a json object with all your content and lunr will build an index out of it client-side. This sounds like terrible architecture but you could stuff about 100 blog posts into an object the size of one big jpeg. For a few dozen articles it's pretty snappy.
Yeah that's a pretty useful trick.
Sphinx, the Python documentation engine, does something like that - e.g. https://datasette.readthedocs.io/en/stable/search.html?q=fts... which runs off this generated JavaScript index file: https://datasette.readthedocs.io/en/stable/searchindex.js
A few dozen articles? I've seen examples with Fuse.js and Hugo searching over 10,000 articles and it is fast. No server-side components required.
Re:Static Sites with Elasticsearch
by contravariant on Saturday May 02, 2020 @09:46PM
(#23056257)
I think most people (me included) underestimate how ridiculously tiny raw text is compared to other common file types.
Great way to botch user experience since the user has to download the index.
There are ways to optimize this per section, alphabetically, etc. Otherwise Xapian is very easy to setup and would be my goto over Elasticsearch.
Re:Static Sites with Elasticsearch
by evandrofisico on Saturday May 02, 2020 @10:07PM
(#23056330)
You can also do the lunr index creation server side, with lib in php or python, generating a quite smaller file and also reducing processing time on the client side.
I've been developing a podcast hosting solution that parses the xml feed, generate static pages and prebuilds a lunr index, and for ~100 posts, it takes around 30 seconds to build server side and less than a second to download and and load on the client.
What's the file size of the index? Is it just encoded in JSON?
Re:Static Sites with Elasticsearch
by kevinastone on Sunday May 03, 2020 @12:08AM
(#23056797)
Yes, it's encoded json for lunr.js. Here's the index for my static-site blog: https://blog.kevinastone.com/search_index.json. It's 305kb un-compressed at the moment (38kb gzipped).
The big advantage of SQLite FTS is that it's really cheap to run. The index is a single static file on disk, then you add a Python process (I'm using https://github.com/simonw/datasette ) to run queries against it. Much less resource intensive than running Solr or Elasticsearch.
It also works surprisingly well - I've run FTS queries against tables that are up to around 10GB on disk and performance is great.
It's no way near as featureful as Lucene, but for small to medium sized projects it's easily good enough.
As for deployment: if the SQLite .db index file is small enough you can bundle it up as part of a static deployment, e.g. bundled in a Docker container. I've done this using Heroku, Google Cloud Run, https://fly.io/ and Zeit Now (aka Vercel).
If the content lives in a git repository you can hook up CI (or a GitHub Action) to build and publish a new copy of the SQLite index on every change.
I've started thinking of this pattern as a kind of static-dynamic site: there's dynamic server-side code but it's running in read-only containers, so you can scale it up by running more copies and if anything goes wrong you just restart the container.
https://til.simonwillison.net/ is my most recent site to use this pattern, see https://github.com/simonw/til for how it works.
I also wrote this tutorial describing the pattern a while ago: https://24ways.org/2018/fast-autocomplete-search-for-your-we...