The website now and then
The Waar is Frank? website was running happily in the cloud since 2010 without a major software upgrade. When in 2025 the service level offered by the hosting provider was reaching a new low and people started complaining about its appearance on phones, it was time to modernize the website. And to investigate how it should be designed given the available technology. The result: quite different than in 2010.
The original Waar Is Frank? website was created because there were no decent alternatives. The website was expected to be a low volume (of content and visitors) site. No extraordinary user interface or data processing backend was required. But when I was traveling it should be easy to add new content. Some orchestration is required: the pictures for a new story should eventually be sourced from a separate website (Flickr), but at the time of writing the story that may not yet be possible. More recently I've started to use external (weather) data as part of the content.
The 2005-2010 version of the website was built using .NET 1.1 with a SQL database as data storage for the textual content. Pictures could be uploaded via the website to an application data directory. The website was designed with a desktop browser in mind. The website and database where deployed (manually) to shared hosting: a server machine with a single webserver and database server that ran the websites and databases for multiple customers. New versions of the website were uploaded via ftp (or later a similar type of protocol). The database could be accessed externally, later an import/export mechanism was used for security reasons.
In 2025 three issues became more amd more pressing. The website was not adapted to be viewed on small screen form factors, and I was using the website more regularly on my phone to look up where I've travelled. It was hard to change any code and implement new features as the code had been migrated from .NET 1.1 to 4.8, but the code structure was not updated and the web pages lacked proper editing support. And finally the hosting provider was apparently having a bad time and its services were becoming more barebones every year.
The latter was probably the result of hosting prices going down, and from other projects I'd learned that hosting could even be free for static websites that do not need a web server or database. So perhaps it would be possible to host this website for free as well? That was indeed possible with an application architecture like:
As I already had created some desktop tools to help with the itinerary maps and weather data, a redesign with content creation on a desktop or phone and a publish-only website would not be a big step. So the new architecture for the Waar Is Frank? project became:
The 2025 version is a client-side application (MAUI Blazor web assembly) that lives in the browser and can be installed like an app (progressive web app). It is designed to be viewed on phones, tablets and desktops. The application and content is technically published as a website that acts as data storage, as a visitor interacts with the client-side application and not directly with the website. Pictures are always sourced from the photo archive. As a content writer or as software developer I do not interact with the website and photo archive. I use third-party editors on a desktop/tablet/phone to create and modify content. A mix of custom and third-party tools upload the content to the photo archive and to a content store. Similarly a new version of the software is uploaded to that store. After every upload a content aggregator job runs that publishes the content and software to the static website. The same job also runs regularly to obtain data from external sources (e.g., weather forecasts) that is integrated in the content.
At first sight the new architecture appears to have more complexity and moving parts than the original one. But the 2025 version uses a lot of third-party tools and platforms that do the heavy lifting. The custom coding of tools that implement the project-specific functionality turned out to be a lot less work than had been invested in the original website.
Another advantage of the new architecture is that it is relatively easy to add new features and maintain the current ones. The content creation tools (if not third party tools) are small and do one thing. The various tasks related to converting the bits of content into a website are also implemented in dedicated tools. Instead of a few big software projects (website, data access) that I can't touch without the risk of having no website at all, I now have multiple small tools. That should get me with much less effort through the next 15 years…