Towards the end of the year I’ll indulge in the dark arts, join the goblins and leave my white architect hat under the Christmas tree where it belongs.
I’m helping a friend (a technically minded, non-programmer) write his first mobile app . We wanted to keep everything simple: use technologies which can be googled easily, don’t bother with a CI/CD pipeline and keep costs close to zero. So we opted for progressive web apps, which behave both like web sites and mobile applications thanks to service workers served over Github pages.
Data without a backend
A big topic in “keeping it simple” is that the app doesn’t have a backend (apart from Github pages which serves the static HTML and Javascript). So where do data live?
There are three types of data:
Transient data are Javascript objects and variables (duh!) created during programme execution. There is other state too, e.g. pending HTTP requests, browser caches and browser state. Those are kind of obvious, just getting them out of the way 🙂
User data are data created by the user or through his/her interaction with the app. They are (more or less) unique to the user and, as there is no backend, stored locally on the device in cookies and the browser’s local storage. Example of user data would be a user email, a playlist or messages exchanged with other users.
Master data are specific to the domain, but are like constants and configuration shared with multiple users. Example of master data are city names, currency exchange rates or product catalogues. I’ll focus in this chapter of “Book of dark arts” on how we store master data in the app.
Storing master data in HTML
A “standard” way to encode master data without a backend would probably be inline JSON. JSON is a great serialisation format, but it cannot be used directly for anything. There is no browser-native way to query JSON (like xpath is to XML) and you have to write code to render it into the DOM.
Our master data is directly coded as tags into the app’s HTML which exposes them as DOM elements. We use custom elements for that and style them with CSS, e.g:
<cities>
<city code=1 label="New York" country="USA"/>
<city code=2 label="Paris" country="France"/>
...
</cities
Accessing and searching: CSS selectors make it easy to navigate even hierarchical structures – with Jquery that is as easy as
$("city")
Visualising: Whenever we need to visualise data, we copy a DOM element from master data, decorate it, and insert it into a different part of the DOM:
$("city[country='France']").each(function(i,e){
let eCountry = $(e).clone();
eCountry.append($("<input type=checkbox value="
+eCountry.attr("code")+"/>");
$("#countryList").append(eCountry);
})
Editing: Normal users don’t edit master data, only the app developers do – by editing HTML in the corresponding Github repository.
Updating: App users retrieve updated master data by reloading the app, obviously 🙂
George's Techblog 