[Autonomie] donnerstag...

[martin schitter]

liebe mitstreiter/innen!

es ist schon wieder fast donnerstag! :)

ich würde vorschlagen, dass wir diesmal endlich die mühen von jogi und 
djamil würdigen, und unseren eigenen jitsi-server bei mur.at für's 
konferieren nutzen.

also: ACHTUNG: GEÄNDERTER URL!

18:00 -- https://jitsi-dev.mur.at/autonomous-systems

wenn ich die zeichen richtig deute, scheint sich im laufe der letzten 
woche ja wieder einigest getan zu haben.

jedenfalls hab auch ich versucht, meine anderen arbeiten ein wenig zu 
unterbrechen, um ein wenig an dieser geschichte zu arbeiten, damit nicht 
der eindruck entsteht, ich würde nur große reden schwingen.

ganz konkret habe ich mich um das datenbank-backend gekümmert, und dafür 
jetzt eine lösung am laufen, die zumindest recht vielversprechend wirkt.

natürlich hab ich wieder einige verschiedene ansätze durchprobieren 
müssen, bevor ich letztlich bei "hasura" (https://hasura.io) gelandet 
bin. eine realtiv konservative lösung mit ganz traditioneller 
postgesql-datenbak im hintergrund, wie ich sie ansonsten eigentlich 
nicht wirklich mag, aber im gegensatz zu den meisten anderen lösungen 
scheint dieser ansatz "subscriptions" bzw. "live queries" -- also die 
synchronisation von änderungen im datenbestand auf den verteilten 
engeräten -- tatsächlich ausreichend schnell und zuverlässig abwickeln 
zu können (https://hasura.io/blog/1-million-active-graphql-subscriptions/).

man kann diese lösung auch durchaus gemeinsam mit RxDB verwenden 
(https://hasura.io/blog/building-an-offline-first-web-app-with-rxdb-hasura/), 
was durchaus seine vorzüge hat, weil es auch dann noch funktioniert, 
wenn die clients keine netzverbindung zur zentralen datenbank haben, 
trotzdem habe ich beim durchprobieren den eindruck gewonnen, dass 
vermutlich schlankere GraphQL-client-libraries, die weniger sperrige 
code-abhängigkeiten in sich bergen, in unserem fall vermutlich die 
idealere lösung darstellen dürften. nur mit derartiger reduktion auf das 
wirklich nötigste bzw. kompatible lösungen, scheint mir das ganze 
realistisch umsetzbar zu sein.

für unsere konkreten zwecke dürfte es relativ vorteilhaft sein, dass 
hasura ausgesprochen benutzerfreundlich zu bedienen ist. man kann also 
u.a. über ein webinterface, die datenbank sehr einfach modellieren und 
editieren etc. 
(https://hasura.io/blog/introducing-the-hasura-graphql-engine-8ea761efaa83/)

ich werde das ganze heute nacht noch auf den kubernetes cluster 
übersiedeln und euch beim treffen morgen die zugangsdaten zukommen 
lassen, so dass ihr euch dann selbst ein bild davon machen könnt.

vielleicht schaff ich es auch noch, irgendeine winzige demo zu basteln, 
um mit hilfe dieses werkzeugs wenigstens ein piepsen auf verschiedenen 
endgeräten bzw. webbrowsern in synchronisierter weise durchzuspielen.
die praktischen schritte dorthin sind aber dann letztlich doch immer mit 
derart vielen kleinen widrigkeiten und unerwarteten hürden verbunden, 
dass ich mich nicht zu viel zu versprechen trau...

ich hoff jedenfalls, dass wir uns damit ganz langsam einer praktischen 
arbeitsbasis nähern -- einem playground --, in dem man dann ein klein 
wenig kreativer die tatsächlichen möglichkeiten auch ganz praktisch 
durchspielen und gezielter ausbauen kann.

liebe grüße
martin