Going into Orbit
So the last year or so (ahem, well, maybe a little more ..) has gone into a new framework I'm calling "Orbit". The general idea is to develop an end-to-end framework for reactive / real-time web based applications that look and feel as much like native desktop applications as possible while leveraging browser based technologies for the User Interface.
Does it work? Well, all the revisions thus far have worked, to varying degrees. The latest and greatest revision seems to solve all the problems my reference application has encountered to-date and performs pretty well even before I've started to optimise (indeed the user interface is quite usable in Chrome running on a raspberry Pi-400).
My reference application is essentially an email client, albeit there's a little more to it. We have multiple email accounts (IMAP simple and Google oAuth2), contacts, calendar (2-way share with Google), relative comprehensive mail filtering and full-text searching. What sets it apart is that it runs as a single page application such that every artefact on every screen should be automatically synchronised with the data-store (which runs locally). So for example if you open the application in two browser windows and change the spelling of a contact name in one Window, if that contact name is used any where on either screen, it should be updated on the screen in real-time.
In the same way conversations are threaded by default, so if a new message arrives and it's not part of a conversation, the screen will slide and a new envelope will appear. If on the other hand the new message is a part of a conversation and the conversation is already visible, the conversation will be re-threaded in-situ on the screen (in real time). The reason I emphasise the updates "in real time" is that they're automatically propagated by the Orbit framework. If I literally open up a database shell and manually, or with a few lines of code, update any bit of data in any table, if that data is shown on any connected display, it will update (in real time). If I manually change some data such that it should now, or should no longer appear on the screen, the screen will update accordingly. So if my view is of messages tagged as "New", and I remove the "New" tag from a message in the database shell, it will disappear from the screen .. automatically.
Architecture
The architecture is a two-stage affair, Javascript (with Vue.js) on the front-end, Python on the back-end, and Socket.io (websockets) in the middle. I'm actually using aiohttp as an interface on the backend (a Flask-like library that's async rather than sync) that allows connections to be upgraded to websockets, which provides for both websocket and HTTP style connections between the client and server.
When all's said and done I'm hoping to pare all this back to a re-usable framework that can be used to generate Single Page Applications with built-in / automatic data synchronisation. This can either work locally or in terms of performance, it seems quite happy to work over a reasonably low-latency Internet connection.
From a development perspective you need to implement your tables / associated data models on the server side in the ORM setup, then set up matching Pinia stores (minimal biolerplate) in Vue.js. Then implement the API calls you would like to make available, and again matching call setup boilerplate in Vue. Once this is done, the application can be written against the Pinia data store and data requests, real-time updates etc, should all be automatic and transparent to the developer.
But Why?
Well, if you've ever written a Single Page Application, you'll be aware that the more that you write, the more dynamic updates you'll need to cope with, and the more chance there is that you'll miss a dependency somewhere or indeed your data model won't let you update what you want to update without a complete refresh. (and a screen flash never looks good in any context) After spending a little time implementing iCal synchronisation with Google Calendars for example, it's somewhat disappointing the number of times one has to reload the page to make sure the display reflects the latest calendar changes.
The other aspect is privacy. Whereas over the last (n) years World + Dog seem to have gone head-over-heels into the Cloud and online services, it has become apparent that having all your information "in the cloud" can have a down-side. Targeted advertising aside, there is the very real possibility that someone could hack in then either steal, modify or indeed hold hostage what might to you be quite valuable information. To this end all data storage is designed to be local (and fast).
What's coming?
Connections are already running over SSL with public key authentication, the next security feature will be encrypted email, hopefully with PGP and Protonmail compatibility. Also text Chat, video Chat, file storage, file sharing, and from a back-end database storage perspective, real-time replication for backups and load-balancing.