4 ms·
Here's another approach: Make a templated JSON file that mimics a database-backend. When you generate the site (or just push to a GitHub Pages repo), the JSON f
by swanson 13y ago
Here's another approach: Make a templated JSON file that mimics a database-backend. When you generate the site (or just push to a GitHub Pages repo), the JSON file will be populated with the "search index" of your site. Something like this: https://github.com/swanson/lagom/blob/master/site.json https://github.com/swanson/lagom/blob/master/site.json
Then you can use whatever Javascript you'd like to search through your pages by pulling down the JSON file into memory and slicing and dicing to your heart's content.
- fjw 13y agoI like this approach a lot. If you have hundreds or thousands of posts, it would also be pretty easy to only append new posts to the JSON file instead of regenerating the entire thing.
- derefr 13y agoThis is really an approach that should get more attention. People know all about database-backed websites (with an AJAX/REST server), and static-generated sites (with no server at all.) But there's a middle-ground where you statically generate precomputed AJAX/REST responses to any query you could make, shove them in an S3 bucket and maybe put a CDN (e.g. Cloudflare) in front of it, and then treat that as your "server", building a traditional AJAXy frontend to talk to it. Scales nigh-on infinitely. The best part is, it's not necessarily read-only! You can write a "real" server, too, that just handles updates. When it receives a request, GET the old version of the object it's modifying from S3 (no need for a database!), patch it up with the AJAXed-in data, and PUT it back. (And follow it up with a CDN single-file-purge API call, if it's relevant.)
- comice 13y agopretty much the approach taken with lunr.js (or you can store the search index itself, which is also json. http://lunrjs.com/ http://lunrjs.com/