Architecture guide

You might come here for the nerdy details prepping for a deep integration with some other tool, or you might want to understand what bells and whistles really are ticking away behind that retro-like name Mortimer.

I'll try to satisfy you both!

There are a few architectural building blocks that are important but perhaps the most important one is perhaps not even architectural from an engineering view point: Ruby On Rails; anyways, I will cover most of the layers of software briefly and remember to add links to GitHub repos and product websites.

High-level overview

Basically Mortimer is an API to an advanced task managing engine that is able to handle anything from a short shopping list to a multi-site, many-levels deep project with thousands of assets/resources, spread across a large organization, that you can talk to. You don't have to - it's optional.

Mortimer has a set of advanced skills that will allow it to offer great assistance in your quest for a better overview over time spent, on personal issues as well as jobs completed that someone has to pay for.

You can use Mortimer if you are "on your own", if your partner decides to play along, if you have a few employees, or any size of business really.

Mortimer is a server backend engine running a myriad of jobs and the UI/UX to that engine:

• a PWA for your desktop/laptop/tablet/smartphone;
• a TUI for your terminal;
• a Chrome-, Firefox-, and Safari-extension

Mortimer has a detailed API purposed for when you integrate your own UI from some other tool.

Backend server components

Kamal proxy

Kamal-proxy is, like Thruster (see right below), a wrapper around Puma, albeit a somewhat heftier one at it, compared to Thruster. It does not do load-balancing, but does host- and path-based routing.

Thruster

Thruster is a thin wrapper around Puma and it helps running the TLS/SSL connections with clients, in particular offloading this

• HTTP/2 support
• HTTPS with Let’s Encrypt
• HTTP caching of public assets
• X-Sendfile support and compression

With Kamal-proxy in the mix you could argue that there be two cooks to the pot - and be right! But Thruster has that one ace up its sleeve: x-sendfile, which makes it more or less indispensable!

Puma

Puma is a traditional webserver concerned with processing your requests. It will process Ruby code (see below) written to do the processing and return the response.

Ruby

Ruby is an interpreted language meaning that every instruction is compiled then executed. IRL what happens when the webserver receives a request is that parts of the entire codebase has been compiled 'in advance' and as such is ready to process the request. There is a part of the entire stack called Zeitwerk orchestrating what has been compiled and what is required to process this particular request.

Rails

Going through all the layers of software in the Mortimer 'onion' we have arrived at what many describe as the heart: Rails is a 'framework', adheres to The Rails Doctrine, and is programmed in Ruby (parts distributed as gems may be programmed in other languages and then compiled into binaries when installed).

Core Principles relevant to this description are

• MVC
• RESTful
• Turbo (Frames and Streams)

MVC

Model-View-Control is one architecural way of arranging the processing of (HTTP) requests from a user. User in this context has to be considered very conceptually; users could be sensors, instruments of all sorts, servers, but real physical human users, too! In short anything capable of establishing a HTTP(S) connection to a web-server. There are plenty resources on the subject of MVC so I'll keep it short:

A user request uses a Controller{} to orchestrate and manipulate some Model that in turn will update a View

/** @type {import('@tailwindlabs/lorem').ipsum} */
export default {
  lorem: 'ipsum',
  dolor: ['sit', 'amet', 'consectetur'],
  adipiscing: {
    elit: true,
  },
}