13 · Offline without a server

Offline mode forced a distinction that turned out to be clarifying for the whole architecture: what is content and what is data.

Originally the entry listings were fetched by a call to the server. Convenient and correct — as long as there is a network. Without one the call does not go through and the page has nothing to display, even though the content is physically present in the browser's memory, because it is compiled into the code bundle.

The solution was to replace server calls with a local read wherever content is concerned. Entries are files compiled into the application, so the browser already has them and does not need to ask. The server stays necessary only for things that by nature live on its side: counters, ratings, comments.

That boundary coincides exactly with the files–database boundary from the second entry. This is not a coincidence. The split we introduced because there is no file system at the edge turned out to be precisely the split that correct offline behaviour requires. Two entirely different forces pointed at the same line — which usually means the line is in the right place.

There is a performance side effect. Since the listings require no conversation with the server, moving between subpages is instant when online too.