My solution to a search on Jekyll
When you decide for a static site, you have to make amends. You cannot simple log into an admin interface and write an article. You can’t just change the position of a widget to your heart’s desire. But you also gain a lot. For all that I don’t like when it comes to Jekyll , I highly appreciate what I gain and that is security, among other things. I can also make templates a lot easier than with e.g. WordPress. IMHO.
What you give up is simple and not really an epiphany: a searchable database.
Granted, my site isn’t that big right now, but I have to think ahead. And also about mobile. Mobile users won’t visit, if a simple visit costs too much data. I don’t want to bore you with the details, but one page load costs 1.78 Mb right now (before caching) and takes 17 requests to the server, while everything is zipped (I do have caching rules set up on apache, just to put your mind at ease). Putting the whole site without images into one file, increases the load by around 500 kb right now. And that number would grow with every article on this site. It would also take longer and longer to search it.
So, to me, this sounds like a bad deal.
I am almost sure, that a database is the best approach to the issue. Even though it means to give up some security, by having dynamic scripts again. However, the setup itself is fairly simple to automate with Jekyll and you don’t need any elaborated scripts.
Here is what I did:
You may notice the
DROP DATABASE directive. That is part of my automation process. I could make Jekyll to only update this file, with the latest entries, but that would require me keeping track of what is in the database and so on. So, to me, the easiest solution is to drop the table and recreate it. It takes a few seconds, MySQL is very efficient. When the site get’s bigger, I can still add more logic here.
When I push my site to git, it rebuilds it, pushes everything onto my server, feeds the SQL into the database and deletes it. So, stop searching for it :P.
I am not going into too much detail, but it is a simple database connection via PDO and searching it, with some simple logic. At the end, it puts out some JSON, resembling a REST API point. I am sure it does not really qualify as a REST service, but it comes close I guess. The gist of the whole thing is this:
The request itself is tricky in terms of Performance , from what you can read on the web, But for now, a full text search is really nice to have. I am certain that by limiting the amount of requests I can achieve the best result of performance versus usability. I have also added some code to look in titles first, then full text, hoping to improve the results.
All this is running in a separate area to improve security and is locked down as hard as I could do it. There are some
.htaccess rules to prevent accessing anything on there, except what you are supposed to.
save_keyword is simply added to the HTML form:
<form id="search-form" onsubmit="return save_keyword('search-input-footer');">
It saves the search keyword to the session storage, reloads it once it reaches the search page and then fires off a request to my RESTish service to get the search results. I think it is quite fast and elegant. I don’t have to do anything else than to commit my blog posts and other changes to git. Everything else is taken care of by my scripts. Just like on GitHub pages ;-).
If there is interest in my automation setup, please let me know on Twitter or by mail via firstname.lastname@example.org. I am also interested in hearing any flaws you may think about with this setup or any other questions and input you may have. Have fun.