The project architecture

The redesign of the Waar is Frank? website made me realize that the architecture of a publish-only website in 2025 can be quite different from the default website design template of webserver plus database. The redesign of the software for this project was combined with the migration/creation of a few other personal websites, all following the same template. But this project was the most complex one.

Other notes discuss details of the project, but that may be hard to understand out of context. The project architecture is:

From the end result as seem by the visitor back to the content creation by me:

Viewer application in the browser.

Because I wanted to show my travels on a special world map, a website without additional coded interactivity is not enough. There is a viewer application, a MAUI Blazor web assembly, that can show the map, the stories and other content. The data and stories are not part of the application but are part of the static website and downloaded to the browser.

Photos hosted on Flickr.

As all my photos and videos are on Flickr anyway, and as hosting photos requires a lot of storage, the viewer application gets most of its images from my Flickr photo archive. On Flickr it is possible to view collections of photos in albums, but that is not very easy to use. Expect that the viewer application will become the front end to browse through the photos on Flickr, with the Flickr website as user interface to look at the pictures in detail.

Static website with content and viewer application.

The components for the web assembly and the data and stories are published on a static website (for free), as Azure Static Web App. Actually there are two static websites: one for the public, with public photos and videos from Flickr, and one for me, with more stories and data and access to private Flickr images. The private one requires authentication for both the website and for Flickr.

Build pipelines.

The website is constructed from stories (in markdown) and other data sources. That can be done on a desktop, but it is also done in an Azure Pipeline using custom tools, like a markdown to HTML converter. The software is the same for the private and public website, the difference is what portion of the content and data is taken into account. There are also tools that run periodically in the website, e.g., to verify whether external resources are still available the website links to, to retrieve weather data, and maybe more in future.

Git repository with content and tools.

The content and pipeline tools are stored in a git repository. This is the best way to keep all data and content consistent, and to transfer the data from the device where content is edited to the cloud for publishing. Git also acts as content quality control, as it is very good at detecting inconsistencies (merge conflicts) if the same content is modified in incompatible ways.

Content editing using a suite of tools.

For content editing a suite of tools is used on a desktop or (for selected content) tablet/phone. If it is possible to use a third-party app, I'll do so. There are custom tools for creating and managing the itineraries of my travels, that take descriptions, scheduling and geo-data as input and produce stories for the websites, map data and instructions to get weather data. There are tools to edit/retouch the geo-data recorded on trips, to geo-tag the photos, to upload the photos to Flickr, organise them in albums and collections, and to create the stories/content to relate albums and photo collections on the website. The tools that create the websites are also available on the desktop to create a preview of the content as it will be viewable on the websites.