Logic on static sites (and the advantages of failing catastrophically but knowably)
A while back Max helpfully summarised where logic can take place on Jamstack (as opposed to plain static) websites. We need logic if what your web page displays depends on when it’s requested. Max provides the example of events. You probably don’t want to display events that have passed, and you might express the logic like this:
// An example of logic // A decision needs to be made, and now! if the event takes place in the future display it else don’t display it
On the other hand, something like a blog post doesn’t normally need any logic because you’ll want to display it as is whenever it’s requested.
(Note: In the comments, Dustin identifies a better, fifth place to perform logic, namely the API. So instead of requesting all events and then performing some logic on them at the compilation stage or in the browser, the logic is performed wherever you store the events. This would presumably mean simply adjusting your endpoint query to something like
I’ve got some experience in this area having created a fairly complex events system for the last version of the Suffolk Libraries website. As I was running a “truly” static site, the logic took place in step two, when the site was compiled.
Max is right when he points out that running the logic before it’s actually required is not ideal. In the example of events, the further the compilation time is from the time the page is requested by a visitor, the more likely the logic will be wrong, and display an event that’s passed. The solution is to run lots of automated builds; and it’s at this point you might consider reaching for a non-static/non-Jamstack approach to perform the logic on the server.
In practice this problem was trivial. The Suffolk Libraries website would automatically compile and build early every morning, only displaying events which began after this time. If you visited the site at 4pm you would still see an event that had ended at 10am, but because most events followed a pattern, knowing the next one would occur at 10am next Monday could be useful. Besides, each edit pushed to Github would fire a site build, meaning the site was updated several times a day, apart from at weekends.
Of course, compilation can also fail, and when it does it fails for everyone. The page will load, but sans logic – so yesterday’s events would appear. While this is more catastrophic than, say, 5% of your pages not working fully due to problems on the device, it does have the advantage of being a clear failure in one place. We can manage our own servers and deployments, but have no control over our visitors’ devices, browsers or network connections.
Consider subscribing to the RSS feed. That way, you’ll get notified whenever I post anything new. If you’re not sure about RSS feeds, I wrote a guide to RSS.
A barebones Underscores WordPress child theme Previous post
Next post Make your website quicker and improve UX by not placing an image at the top of the home page