Server outage - move to GitHub Pages?

[fschutt]

There's currently a server outage for https://divinumofficium.com so I am wondering if it would be good to move the project to GitHub Pages and migrate towards statically rendered HTML files.

I am hosting https://dubia.cc on GH Pages and it's working pretty well with static rendering. I could help with the migration process, if necessary - GH Pages doesn't cost anything, there's no database, no backend. I just deploy it from GitHub Actions, running a custom script / binary to generate the necessary files.

[APMarcello3]

@benyanke your thoughts?

[fiapps]

I think static hosting is impractical because the number of possible combinations of options to the script is high and keeps growing. For each supported day and for each hora or Mass of that day, you need to have the number of languages squared (lang and lang2) times the number of rubrics, doubled for two possible values of priest, doubled for two possible values of psalmvar, doubled for two possible values of nonumbers, doubled for two possible values of oldhymns, …

But what might work is to put divinumofficium.com behind a CDN, where the CDN caches the result of running the script and can both return that without hitting the server (reducing load) and return it when the server is down. This might require you to use HTTP GET and put all the options in the URL. If you use PUT or have options in a cookie, the CDN might not be able to cache reliably.

[fschutt]

I was thinking more of client-side rendering instead of server side (server side as a fallback?). I.e. server-side for common options and client-side for translations (as most people interested in the DO pray it in Latin, if I‘m not wrong).

It should be technically doable even without (365 prayers x 12? languages x maybe 10 options, so that‘s about 50k files, there is no limit that I know of that would prevent that (plus it‘s technically only run once, not on every request). Yeah, it‘s a lot of files, but it does take away all cost for running servers.

The other problem is that I can‘t read Perl. Maybe I‘m just too young but it would help with reusability if there was more documentation on how the Office actually works, what things were changed and edited, I know it‘s complex but a writeup would be nice for people unfamiliar with Perl.

[fiapps]

Caching is also problematic: I think it would delay error fixing or how would you determine to reload a cached page?

The CDN cache could be purged manually using the console for the CDN provider. In this case, you only purge the cache if an serious problem was fixed. Typo corrections and new translations could roll out gradually. I imagine you can tell the CDN how long it is allowed to cache, but I've never looked into this detail.

If the provider has an API, as Cloudflare does, then it could be used to purge the cache when a new revision is deployed from the Git repo to the server. However, if you purge the cache on every deployment, then if a deployment breaks the server, the CDN won't serve as a backup. So, if you automatically purge the cache when you deploy, you need better testing. In particular, it would be good to first deploy to a staging server, test whether the staging server is working, and only then deploy to production.

[fiapps]

I was thinking more of client-side rendering instead of server side (server side as a fallback?). I.e. server-side for common options and client-side for translations (as most people interested in the DO pray it in Latin, if I‘m not wrong).

If the rendering was client-side, then all the server would need is static files. But that would mean rewriting all the code in JavaScript, which does not seem practical. Because the data files are constantly changing, the one attempt to make major changes (the calcalc branch) became obsolete before it was finished. What seems practical are gradual improvements to the code, and this is the course currently being persued.

It should be technically doable even without (365 prayers x 12? languages x maybe 10 options, so that‘s about 50k files, there is no limit that I know of that would prevent that (plus it‘s technically only run once, not on every request).

The number is much higher than that, because every option that has two possibilities doubles the number of possible combinations, so 10 options doesn't mean 10 times as many files, but 2 to the tenth power (1024) times as many files. And regenerating 5 million files (which is an understimate) on every deployment is not practical.

[fschutt]

Alright I think you can close this discussion then and maybe convert it to a "we need better documentation of the code". I am mostly interested in the logic of the Breviary, if the texts are changing (i.e. with typos), that's not such a big issue.

Cloudflare has an "always online" toggle, which caches highly-requested URLs with archive.is and reroutes the URL to archive.is when the server returns a 500 error. Could be a fix.

But that would mean rewriting all the code in JavaScript, which does not seem practical.

I've had somewhat decent success rewriting code using ChatGPT, porting code from Python to Rust for example, with tests in place. I can at least add some automated documentation (doesn't break anything, after all). Then you can correct the documentation if it is wrong. And then I can take a look again as to what / how I could automatically rewrite it. o1 is pretty decent at adapting code from language A to language B, as long as it fits into the context.

[FAJ-Munich]

Alright I think you can close this discussion then and maybe convert it to a "we need better documentation of the code".

The complexity of the code is a consequence of the complexity of the breviary rubrics and the spirit of the project, making the changes between rubrical structures comparable. Compared to 3 – 4 years ago, there have already been substantial improvements and corrections, trying to improve documentation / coding style and reducing complexity: at the same time, it is a very delicate undertaking not breaking things while doing so. Unfortunately, the Missa code is still largely in its original state.

I am mostly interested in the logic of the Breviary, if the texts are changing (i.e. with typos), that's not such a big issue.

As per the above, please do not try to conceive the logic of the Breviary from looking at the code. It has caused me nightmares. As a starting point, I can recommend Gregory DiPippo's compendium of Breviary reforms published on newliturgicalmovement. Then, to really get a thorough understanding, one day you really have to dive into the rubrics. Many versions of the Breviary (also used to create the database for DO) are available on archive.org. If you do not understand the Latin rubrics, there is an English translation of the Tridentine and Divino Afflatu available at the Rubrics sections on the website as well.

Hope this helps you to get started.
Laudetur Jesus Christus!