Static sites are the best. They are the most secure and fastest of sites. They
are perfect for anonymous users, where you would want content editors to
have a secure and hidden backend where they can administer the content – but
have the content served elsewhere.

Having search on top of that can be a bit more challenging. There are different
solutions for having a local search like lunr.js (and a
Drupal module to integrate with it), but
it’s quite limited. That is, it will create a local index where you could have
some JS to look into it, but that is no match to full-blown search engines such
as Elasticsearch.

In this blog post I will share a demo website we’ve built as a proof of concept
for a much larger site. I’m not going to dwell on the advantages of static
sites, instead I’m going to share the high-level concepts that guided us, along
with some technical tips. While the specific details have nothing to do with
Drupal – our client’s site is in Drupal, so it was convenient to build it
around it. But you can really do it with any language.

Here is the demo repo,
and that’s how it looks:

Concepts

With static sites, deploying and reverting deploys is easy. It’s not much more
than git push or git revert if something went wrong. But what about search?
As we’ve mentioned, we want to keep using Elasticsearch for things like
aggregations (a.k.a. facets), spell checks, etc. But how can we support, for
example, a rollback in the deploy – making sure that search is always searching
only through the content that exists in the deployed static site. Thankfully,
Elasticsearch supports index cloning, so we could have something like this: