Ein absoluter Trend unter Software Development auch im
Jahr 2024 oder gerade im Jahr 2024 ist das Thema offline First
und das ist auch bei mir tatsächlich immer der Nummer 1
Punkt, der mir auf die Nerven geht und für Frustration sorgt,
wenn es mal nicht funktioniert. Wenn ich nämlich in der
Deutschen Bahn oder in deutschen Funklöchern bin.
In dieser Folge reden wir über Frameworks, die Developern das
Leben ein bisschen leichter machen und womit das Thema noch
zusammenhängt, nämlich es geht auch viel um Datenhoheit und
Privacy, also insgesamt glaube ich ein sehr spannendes Thema,
viel Spaß mit dieser Folge. Wenn ihr diese Folge hört, dann
schlafen malte und ich wahrscheinlich noch.
Bist du wach? Nee, heute nicht, aber.
Keinen Tag länger. Mit dieser Folge warten.
Wir wollen ja, dass es am Montag pünktlich mit dem to do
Developer Podcast losgeht und ihr natürlich die erwünschten
Informationen bekommt, hoffentlich der üblichen
Qualität. Wir erleben hier quasi in der
Nacht zu Montag auf, weil wir es nicht gebacken bekommen haben,
irgendwie unsere Kalender anständig zu synchronisieren
und. Ich finde sie auch gerade eben
erst in München gelandet, jetzt an den Schreibtisch gedüst, um
noch diese Folge aufzunehmen. Also.
Rechnet direkt in den nächsten Wochen auf jeden Fall nicht mit
einer Folge zum Thema Zeitmanagement, aber.
Das sieht wohl noch gut aus. Und wenn du das jetzt hier
während der Aufnahme nicht dazwischen kommt, dann dann
schaffen wir das herzlich willkommen.
Und heute sprechen wir über ein super spannendes Thema.
Du sagst, das ist ein ganz aktueller Trend, aber das hat
sich etwas, was ja schon seit vielen Jahren irgendwie immer
wieder mal hochkommt, nämlich offline first.
Aber bevor wir ins Thema einsteigen, erstmal noch viel
Dank an dich, Kevin, für 3 Kaffee.
Wir haben uns natürlich. Sehr gefreut, oder?
Auch wenn ihr uns einen Kaffee ausgeben möchtet, findet ihr in
den Show Notes den Link zu bei mir coffee.com.
Genau da legen wir auch los mit dem Thema.
Also wir haben es gerade offline First auch oft irgendwie local
First genannt. Warum haben wir gesagt, das ist
ein Trend in 2024, weil das klingt ja eigentlich nach
irgendwie einer Sau, die schon ganz lange durchs Dorf gejagt
wird, aber es ist tatsächlich, dass am meisten requestete
Feature bei Superbase wer das nicht kennt, das ist so ein
mobile oder so ein Backend as a Service Plattform, Es ist seit
Jahren das am meisten gefragte Feature in Motion, was ja auch
so eine Datenbank und Projektplanung Management
Software ist, die ganz viele Bestimmungen.
Euch da draußen benutzen und auch mein Nummer 1 requestes
Feature in ganz vielen Apps und das liegt nicht nur daran, dass
wir hier in Deutschland, dass wir in Deutschland einfach oft
ne schlechte Abdeckung haben, sondern das kann ja einfach mal
dran liegen, dass man im im Flugzeug ist und kein Internet
hat, oder es gibt auch noch n paar andere.
Andere Benefits warum ist es n Trend?
Weil es gerade auch auf ganz vielen Konferenzen, also
eigentlich fast auf allen Developer Konferenzen,
mindestens einen Talk zu dem Thema gibt?
Es gibt mehrere Frameworks, die auch aus irgendwelchen Research
Labs im Moment raus purzeln. Es gibt, und dieses Thema wird
irgendwie gerade gefühlt wieder neu aufgerollt deswegen wir
dachten, dass da eigentlich ne gute Zeit, dass wir da auch mal
ne Folge zu machen, gerade weil das auch einfach insofern
spannendes Thema ist, dass es nicht nur technologisch
natürlich herausfordernd ist. Sondern auch wieder n bisschen n
Schritt zurück von alles muss in die Cloud, sondern wieder mehr
lokal hin und auch n. Spannendes Thema ist in Richtung
Datenhoheit, aber ich würd sagen wir fangen mal vorne an.
Was ich ganz spannend finde, ist, dass wir über das Thema
schon mal gesprochen haben, zumindest in Ansätzen, als wir
über progressive Web Apps gesprochen haben.
Und das ist ja ein Thema, was vor einigen Jahren, ich würd mal
sagen, 567 Jahren. Ganz frisch hochkam und irgendwo
in aller Munde war. Und jetzt kommt das Thema wieder
und das immer noch Leute dieses Feature nachfragen müssen, diese
Funktionalität, dass ich tatsächlich auch lokal arbeiten
kann und sichergestellt, dass meine Daten jederzeit dennoch
aktuell sind, das liegt auch einfach daran, dass viele.
Diese Adaption dieser Möglichkeiten, die mit solchen
Technologien gekommen sind, gar nicht mitgemacht haben.
Teilweise einfach weil es komplex ist, teilweise auch
einfach aus Convenience und vielleicht auch dem Gedanken,
dass mittlerweile Internet Konnektivität.
Jederzeit verfügbar ist, was aber natürlich faktisch nicht so
ist und vielleicht auch noch ein Thema, was wir in der Folge
damals angesprochen haben. Es muss ja nicht immer so sein,
dass man entweder online oder offline ist.
Sondern in einem schwierigen, Schwierigsten sind vor allen
Dingen die Situation, wo irgendwie das Gerät das Gefühl
hat, online zu sein. Und dann ist man wieder
irgendwie mobil unterwegs mit irgendeiner Edge Connection und
die Daten kommen einfach nicht über die Leitung und dann
befindet man sich in einem Zustand, wo die Anwendung
einfach nicht mehr nutzbar ist. Und ich glaube das wird auch für
die nächsten Jahre, wenn ich Jahrzehnte immer noch in vielen
Situationen vorkomme, selbst wenn man jetzt heutzutage selbst
im Flieger im Zug durchaus. Internet hat aber dieses
Internet hat natürlich nicht immer die Qualität, wie man es
vielleicht vom heimischen Schreibtisch oder vom Access
Point zuhause gewohnt ist. Genau, wenn das Spannende an dem
Thema ist. Es geht einfach darum, geile
Apps zu bauen, die schnell sind, die Responsive sind, die mir als
als User immer Zuruf auf meine Daten geben und vor allem super
schnell auf meine Daten geben. Du hast gerade schon erwähnt
progressive Web Apps, da ist es soweit.
Weiß sogar ein Requirement, dass die App offline fähig sein muss,
zumindest natürlich in der Art und Weise, dass sie, wenn es ne
Web App ist, die HTML, Java Script und CSS Dateien offline
ausliefert. Dazu gehört dann meistens auch
eine kleine lokale Datenbank. Ne, das können die meisten
Browser, also die meisten Browser heute haben die
Möglichkeit eine lokale Datenbank zu haben, kann man
auch mal irgendwie die was sind das die bei Chrome oder sowas
die Developer Tools aufmachen und dann sieht man auch, dass da
unter anderem neben irgendwie den den Sourcecode und den
Cookies und dem Local Storage ist auch Databases und Indexed
DB heißt das in den Developer Tools, dass es das gibt, das
heißt die Browser stellen so was eigentlich schon zur Verfügung
und bei progressive Web Apps ist es soweit ich weiß auch wirklich
eine Anforderung, jetzt brauchen das natürlich nicht alle Apps,
also gerade wenn ich was habe was einfach ganz klar nur im
Internet stattfindet also denke ich jetzt irgendwie das Portal
von meinem Cloud Provider nehme, da kann ich natürlich.
Offline wenig machen, weil da werde ich keine WM hochfahren
können, wenn ich da gerade keine Internetverbindung habe.
Aber sogar für das, was wir hier tun.
Also dieser Podcast entsteht ja an 2 komplett verschiedenen
Orten in Deutschland und wir nehmen über eine Software auf,
die im Browser läuft und auch die hat aber eine gewisse
Offline Funktionalität, dass sie zumindest meine Stimme.
Ihr gerade hört noch maltes Stimme lokal speichert und erst
am Ende des Recordings quasi hochlädt.
Das heißt, das, was malte und ich hier live hören, das kann
auch manchmal nen Hänger oder nen kleinen Hick haben, aber
wenn jetzt bei malte mal für ne Sekunde oder bei mir mal für ne
Sekunde das Internet wegbrechen würde, würde dieses Recording
trotzdem lokal weiterlaufen und am Ende dann zusammengefügt
werden, ist also auch schon mal ein ganz gutes Beispiel dafür,
dass eine App eigentlich auch immer beides sein kann und
deswegen reden wir auch nicht von irgendwie online oder
offline Apps, sondern wir reden wirklich von offline first.
Also dass das einfach quasi von von Tag 1 mitgedacht wird.
Und Verfechter davon, von diesem Thema, die sagen offline First,
das ist kein Feature, sondern das ist ein Design Pattern, das
heißt von vornherein in der Art und Weise, wie ich mein Software
Designer, wie ich meine Anwendung baue, habe ich direkt
im Hinterkopf, dass ich mich nicht einzig und allein auf der
Verbindung zu einem Server verlasse, auch wenn das
natürlich als Developer auf die, ja, sag ich mal, einfachere Art
und Weise ist. Gerade kollaborative Anwendungen
zu implementieren oder gerade irgendwelche Anwendungen mit
online Features zu implementieren.
Und das wahrscheinlich auch der Grund ist, warum wir so viele
Apps sehen, die keine offline First Funktionalität haben, weil
es einfach bequemer ist oder weil es einfach ein bisschen
einfacher ist. Und weil das Thema Komplex ist.
Und da tauchen wir gleich mal dran ein.
Ja, anstatt wir kennen das auch alle als User von Anwendungen,
wie frustrierend das einfach ist, wenn tatsächlich die
Anwendung einfach nur n Fehler wirft, wenn die
Internetverbindung mal nicht da ist oder unterbrochen ist und
vielleicht in dem Fall gar keine.
Echtzeitübertragung notwendig ist.
Klar, wenn du irgendwo ne Videokonferenz hast und die
Internetverbindung wegbricht, dann kannst du nicht mehr
kommunizieren, aber es gibt ja ganz viele Anwendungsfälle, wo
es völlig irrelevant ist. Und warum soll man den User da
aus seinem Flow reißen? Obwohl man die Möglichkeit
hätte, die ganzen Informationen lokal zu speichern, lokal zu
verarbeiten und dann zu einem späteren Zeitpunkt dann zu
synchronisieren. Da kommen wir ja gleich später
noch mal drauf, wie das Ganze dann auch zu implementieren ist.
Ja oder noch viel schlimmer, dass er sich keinen Fehler
bekomme, sondern das einfach unfassbar langsam ist irgendwie
gerade, dass ich vielleicht irgendwie gerade keinen Text in
Dokument eintippen kann, weil keine Ahnung die API für die
Autovervollständigung langsam ist oder einfach frustrierend
sein kann. Ne, ich hatte das gerade, also
ich. Im gerade im Flugzeug auf diese
Folge vorbereitet und hab ne n Konferenztalk dazu offline auf
Youtube gesehen und hab n hab n coolen Screenshot gefunden den
ich hier meine Notizen reinschreiben wollte und ich.
Also malte und ich, wir, wir pflegen die Vorbereitung und die
Notes in Motion und ich kann zwar meine Notes The offline
aufrufen, ich konnte aber den einen Screenshot den ich gemacht
habe nicht pasten in meine Notizen, weil da wahrscheinlich
irgendeine online API für befragt wird die was weiß ich
macht oder dieses Bild glaube ich hochlädt weil natürlich
Motion die die Dokumente auf den Motion Servern speichern und gar
nicht lokal. Und da habe ich mich tatsächlich
auch wieder mal gefragt ob das wirklich das richtige Tool ist.
Wenn ich hier nicht, wenn es quasi keine Internetverbindung
habe nicht auf meine Nodes zugreifen kann und das muss ja
nicht nur sein, dass ich keine Internetverbindung habe, sondern
ich verlasse mich ja auch darauf.
Dass Motion als Firma und als Server keine Fehlentscheidungen
insofern treffen, dass deren Server manchmal down sind oder
die ganze Firma vielleicht irgendwie den Bach runter geht.
Wir kennen das alle irgendwie, dann gibt es irgendwie keine
Ahnung, einen großen Blog Post. Hey we go und Incredible Journey
Blabla, was am Ende einfach nur heißt wir sind gekauft worden
von irgendeiner riesigen Firma und ich meine wir haben es ja
nicht selten gesehen, dass Tools dann auch einfach eingestellt
werden und. Und ich hab mir schon überlegt,
weil ich hab ja viele 1000 Notizen und ja, Mitschriften und
Sachen hier drin. Und deswegen meinte ich auch
vorhin so n bisschen, dass für mich das Thema offline First gar
nicht immer nur technologisch ist, sondern auch.
Komme ich an meine Daten ran, wenn die Firma Norton oder das
oder die die Server von Motion vielleicht mal nicht mehr sind?
Und klar ich kann das nicht irgendwie exportieren bei
manchen Apps wenn ich Glück habe kann ich noch was exportieren,
das müsste ich aber auch regelmäßig machen.
Reicht aber auch nur irgendwie n Jason und es gibt ja auch
durchaus Notiz Apps die lokal funktionieren oder die
vielleicht einfach nur auf Mark Down oder Textdokumenten
basieren. Und ich glaube, dass dieses
Owning dieses wem gehören, die Daten gehören mir weiterhin die
Daten und ich nutze nur ein Tool, was ist mir einfacher
macht darauf zuzugreifen sowie halt als Developer, dass er mit
Git schon eigentlich schon immer hatten.
Ich glaube, dass das ein Trend ist und dass deswegen auch ins
Jahr 2024 ist offline First wieder viel hochkommt, weil
dieses wem gehören die Daten, dass ich die meine wichtigsten
Sachen eigentlich selber Owen möchte, die Dateien dahinter,
ich glaube, dass das noch mal dieser Privacy Trend ist, der
jetzt das Thema nochmal hochkommen lässt.
Ja, ich glaube, gerade bei solchen Apps, die auf
Webtechnologien basieren, da ist es halt einfach noch nicht
leicht genug, diese Funktionalitäten zu
implementieren. Ich glaube, bei klassischen.
Desktop Apps zum Beispiel. Da ist dieser Gedanke immer noch
aus früheren Zeiten da, dass diese Anwendung völlig
internetfrei funktioniert, muss ich meine ich.
Zum im Vergleich zu Motion, auch wenn ich hundertprozentig
vergleichbar, aber wenn du die Notiz App von Apple verwendest,
natürlich funktioniert die und ich kann meine Notizen machen
wenn ich auf dem Mac keine Internetverbindung habe und
sobald ich wieder online bin werden die dann synchronisiert
mit den Daten auf meinen anderen Geräten oder?
Anderen Themen. Und wenn du da dann deinen
Screenshot einfügst wenn du gerade kein Internet hast, das
ist gar kein Problem. Die Anwendung beschwert sich ja
nicht mal und von daher ist es dann häufig auch eine Frage,
dessen will man dort diesen zusätzlichen Aufwand treffen,
weil heutzutage ist es ja sogar in Webanwendungen möglich, diese
ganze Verarbeitung der Dateien lokal zu machen, du musst es ja
gar nicht über irgendwelche Server Schnittstellen machen und
von daher ist es häufig nur eine Frage des Wollens, aber es macht
natürlich die Anwendung in der Entwicklung komplexer, es ist
kein triviales Thema, weil dann natürlich sobald ich solche
Mechanismen einfüge. Auch viele Gedanken machen muss.
Welche Strategie fahr ich ja bei den beiden Themen so Lesen,
schreiben, Daten synchronisieren, wie stelle ich
sicher, dass diese Daten. Jederzeit auch.
Die entsprechende Integrität haben und ich mir nicht
gegenseitig irgendwelche Datenbestände überschreibe von
vielleicht verschiedenen Quellen, aber da kommen wir ja
gleich noch ein bisschen im Detail zu, wenn es um die
konkreten. Wege geht, wie man so etwas
bauen kann. Ja, es sei einfach teuer, weil
aufwendig, das zu entwickeln, wie du gerade schon gesagt hast.
Ne, es fehlt so ein bisschen an der an der Einfachheit oder dass
es einfach in den Frameworks, die wir heute benutzen mit
Eingebacken ist. Und ich meine, es kommt
natürlich auf, weil was, was wollen wir, was man eine geile
Software aus, die ist immer verfügbar, also unabhängig
davon, ob ich gleich auch bei Grad nur ein Funkloch habe.
Ich möchte aber heutzutage ja trotzdem kollaborativ, privat,
kollaborativ, im Idealfall natürlich.
Damit arbeiten können, und das kann einmal sein, über
verschiedene Geräte, weil es war schon so.
Ich habe die Vorbereitung am Flughafen am Laptop gemacht, ich
saß im Flieger, dann an meinem I pad, das heißt, ich muss ja
nicht nur verschiedene Personen sein, sondern allein schon
zwischen meinen Geräten einfach so früher, so ein bisschen
früher kam auch mal so Peer to Peer Ideen auf und sowas allein
dazwischen möchte ich ja schon eine gewisse Synchronisation
haben und dann idealerweise was Motion ja so ein tolles Tool
auch macht ist, dass du dich da theoretisch auch gleichzeitig
drin arbeiten können und dass man dann wie man das.
Von von Word online oder von von Google Docs kennt wirklich so
gleichzeitig auch mit den Cursor und sowas sieht und das ist
natürlich. Unheimlich, ja aufwendig zu
entwickeln. Und das kann und will sich aber
auch vielleicht ja gar nicht jeder leisten, der jetzt gerade
irgendwie ne Anwendung baut. Ja, und ich mein, das ist
technisch möglich ist. Das sieht man ja in einigen
Anwendungen. Ich glaub, viele von uns werden
gelegentlich die die Office Tools von Microsoft verwenden,
wo ja sowohl das gleichzeitige Bearbeiten in den Desktop
Anwendungen als auch eine offline Funktionalität möglich
ist. Aber man läuft vielleicht hier
und da in irgendwelche Synchronisierungskonflikte, die
dann entsprechend nervig sind und diese ganzen Probleme spart
man sich natürlich, wenn man diese offline Arbeit gar nicht
erst erlaubt. Dann schauen wir doch mal rein,
oder? Also genug drumherum geredet,
wir haben uns ein bisschen angeschaut, was ist denn so
stand heute auf offline First, offline Funktionalität wie wie
macht man das denn und wir reden auch auf jeden Fall leicht
drüber, wie man mit so Konflikten umgeht, die dann ja
mehr oder weniger unvermeidbar sind.
Das eine Thema hatten wir gerade schon in Browserdatabaces, da
gibt es ne ganze Menge. Also SQ Lite kennen kennen glaub
ich viele, was so ne gleichgewichtige Version von der
klassischen SQL Datenbank ist. Es gibt auch Pouch DB, das ist
gerade relativ populär, das ist natürlich wie der Name schon
sagt inspiriert von Couch DB. Das ist eine No SQL Datenbank
und das ist eigentlich alles nur verschiedene Java Script Pakete
die man sich über npm runterlädt.
Also wir reden jetzt gerade, wir reden jetzt erstmal
hauptsächlich von Web Apps die auch gerade durch sowas wie
Elektro natürlich gerade auch viel den Desktop erobern, aber.
Die Konzepte und Technologien sind aber dieselben davon.
Wenn wir jetzt von der tiefen mobile Apps oder nativen Desktop
Apps reden, auch da habe ich in der Regel irgendwas wo ich eine
Datenbank ansprechen kann, aber alle modernen Browser
unterstützen das schon und dann kann die zum Beispiel einfach
lokal eine Datenbank so eine Kopie, das muss ja nicht von der
gesamten Datenbank sein, aber von derselben Struktur wie sie
die Datenbank ist, die ich in meinem auf meiner Server
Landschaft bei meinen Clouds stehen habe und.
Man dort die für den für den angemeldeten User relevanten
Informationen drin speichern und einen, ja eine Sync eine
Synchronisation mit der Cloud mir dann irgendwie bauen.
Das natürlich für sehr große Datasets problematisch, weil ich
begrenzten Speicher und natürlich auch.
Nur begrenzte begrenzten Durchsatz in der Internetleitung
habe aber technisch wäre es zumindest so, dass meine
Applikation dann erstmal immer die lokale Datenbank fragt und
dann im Hintergrund die Synchronisation mit dem Server
macht. Das hat den großen Vorteil, Ich
mache die App auf, ich habe sofort Daten, das mögen nicht
die aller aktuellsten Daten sein, aber ich habe sofort
welche und dann kann ich sagen Pass auf wann immer du einen
Datensatz veränderst oder einen neuen Datensatz erstellt, wird
er in die lokale Datenbank geschrieben und dann asynchron
möglichst zügig mit dem Server synchronisiert.
Und ich glaube, was viele als diese Technologien neu in den
Browser gekommen sind, abgeschreckt hat, ist das zu der
Zeit das ganze Halt noch nicht auf allen Plattformen verfügbar
war. Und wenn man jetzt halt schaut,
Index DB weiß nicht auf der Webseite wie Can I used.com geht
mal rein, welche Technologien sind in meinem Browser
unterstützt hat man eine Kompatibilität eigentlich?
Über alle Browser hinweg, die tatsächlich auf aktuellen
Betriebssystemen, egal ob jetzt Desktop oder Mobile, verfügbar
sind. Das war vor einigen Jahren noch
nicht so und ich vermute, dass das einer der Gründe war, warum
seinerzeit, als dieses PDA Thema Hochkam, viele sich damit
technologisch beschäftigt haben, haben aber gesagt, es ist
einfach nicht den Mehraufwand wert, weil wir sowieso nicht
alle User damit erreichen können, aber das ist natürlich
heutzutage anders und dementsprechend kann man sich
jetzt auch wieder Gedanken darüber machen.
Ist jetzt der Punkt gekommen, wo ich solche Technologien für die
offline Arbeit in meine Webanwendung auch reinbringen
kann? Genau.
Was kann ich sonst noch machen? Also ne wie gesagt es gibt die
Technologie für ne lokale Datenbank ist da.
Ich muss auf aber ich muss natürlich auch auf n paar Sachen
achten zum einen also zum Beispiel dass ich sowas wie IDS
nicht mehr auf dem Server generier so auf dem Client in
ganz vielen klassischen Anwendungen die auf irgendeiner
Rest API basieren, schicke ich Informationen über ein Dokument,
was ich neu erstellen will an den Server zum Beispiel und der
antwortet mir dann mit dem Dokument, vielleicht noch mit 23
Metadaten mit so einem Timestamp created ad und ne id, das
funktioniert offline nicht, sondern ich muss in der Lage
sein. Die id s wahrscheinlich
irgendwelche Guides, irgendwelche eindeutigen ids,
dass ich die lokal auf meinem auf meinem Device generiere,
damit ich sie eben schon die lokale Datenbank speichern und
dann. Ja, beim Synchron, beim Syncen
in die Cloud verwenden kann, damit der Server dein Akku mal
ist. Ein neues Dokument habe ich noch
nicht gesehen, ganz wichtig sind aber auch, dass ich neben den ID
s für meine, ich nenn es jetzt Dokumente, das können aber auch
Zeilen einfach in einer relationalen Datenbank sein, so
ein Revisionmarker. Meistens einfach nur ref oder
Unterschied ref. In den meisten Tabellen
abgekürzt, generiere für meine Updates und das mache ich, damit
mein Backend später weiß, wenn ich sage ich habe eine Änderung
an einer an einem, ich nenne es jetzt immer Dokumente an einem
Dokument gemacht, dass mein Backend nachher weiß an.
Welche Version dieses Dokuments sich denn meine Änderung
beziehen? Weil es kann ja sein, dass ich
offline war und sich im Hintergrund das Dokument schon
komplett verändert hat und in der Regel, was ich dann mache
ist, ich krieg dann vom Server eine Antwort, der mir irgendwie
Konflikt, du kannst auf die Revision 2 gerade kein Update
machen, weil die Revision 2 ist gar nicht mehr die aktuellste
und in den meisten Fällen reicht es dann sich die aktuellste
Version zu holen und dann darauf noch mal das Update zu machen.
Das ist aber jetzt natürlich sehr abhängig von der Anwendung,
aber in der Regel löst man das mit dem darüber, dass man sich
einfach die neue Version dann wenn man wieder online ist vom
Server zieht und dann diese Version updatet.
Das heißt aber schon, und das merkt man ja gerade schon bei
diesem Update, dass wir uns lösen müssen bei Offline First
von dem Gedanken, dass wir einfach Dokumente Datenbank
teilen, was auch immer einfach. Komplett replacen, sondern was
wir eigentlich speichern müssen, ist ja eigentlich ein Log an
Änderungen die gemacht wurden. Das heißt ich heiß nicht, wenn
ich jetzt den Titel dieser Folge von folge 90 auf folge 91
ändere, dann mache ich kein http put mehr und schicke da einfach
das komplette Dokument hin, sondern idealerweise schicke ich
einfach nur irgendwo die Information hin, hat den Titel
geändert von Folge 90. Auf Folge 91, und das heißt, ich
muss mir schon bei meiner Datenstruktur oder wie ich mit
meiner API auch am Ende arbeite, Gedanken machen, dass ich nicht
mehr, und das ist natürlich das, was einfacher für den Developer
war in der Vergangenheit, dass ich nicht mehr einfach nur
komplette Dokumente austausche, sondern eigentlich ja Befehle
sammeln und dass ich wieso ein wieso ein Activity log habe.
Den ich dann auch wieder abspielen kann.
Mein meine Architektur wird halt dadurch wesentlich komplexer und
ich muss mir halt über diese. Konfliktlösungsstrategien
Gedanken machen ich kann natürlich im einfachsten Fall
immer hingehen und. Die letzten Änderungen nehmen
immer das Neueste gewinnt, aber da habe ich natürlich dann was
die User Experience betrifft, relativ schnell irgendwelche
Situationen erreicht. Du hast gerade das Beispiel
genannt, Du arbeitest am Laptop, arbeitest dann irgendwie offline
an einem anderen Gerät, dein Gerät geht wieder online und
überschreibt alles Sachen, die du vorher vielleicht mit einem
anderen Gerät bearbeitet hast. Das sollte natürlich nicht sein,
du sollst. Im besten Fall sollte das Ganze
zusammengeführt werden, die Änderungen werden
zusammengeführt, wenn sie konfliktfrei sind.
Falls sie es nicht sind, sollte natürlich auch der User dort die
Möglichkeit bekommen, diese Konflikte halt zu lösen.
Ich meine, wir kennen es als Developer so ein bisschen auch
aus aus der Git Welt, wenn ich verteilt arbeite, offline first
und das dann irgendwie zusammenführe auf dem auf meinem
Remote Server, dann muss ich mich genau mit diesen Themen
beschäftigen und ich glaube daher kann man sich da so ein
bisschen in diese Thematik ganz gut reindenken, weil ich glaube.
Mittlerweile alle sehr vertraut sind damit, wie wie geht als
Protokoll funktioniert. Und da sind ja viele dieser
Themen adressiert, wie gehe ich damit um, dass sich Dateien
verändert haben, während ich offline ne Änderung gemacht habe
und wie kann ich dann diese Konflikte beseitigen und
Änderungen zusammenführen und gerade diese Stichpunkte, die du
gerade genannt hattest mit den verschiedenen Revisionen etc.
Kennt man ja aus dieser Welt, aber genau diese Probleme muss
ich dann jetzt auch in meinen eigenen Anwendungen lösen.
Ja, wir wissen doch alle, wie krampfhaft das auch schon
alleine in Word oder sowas gelöst ist.
Also da muss ich mich ja wirklich als developer, wie du
gerade gesagt hast, auch Gedanken machen, wie ich das
vielleicht auch dem User darstelle. 2 verschiedene
Versionen lege ich die nebeneinander oder gehe ich
wirklich jede einzelne Änderung durch?
Das können dich ja theoretisch, also genau wie bei Git, wenn
wenn sich nur eine Datei verändert hat, kann ich so ein
kann ich ein Rebase machen oder das irgendwie machen, aber wenn
sich beide Dateien also an der gleichen Datei von 2
verschiedenen Seiten Änderungen gab.
Dann kann ich das ja quasi nicht mehr auflösen.
Wie du dort richtig sagst, ne. Ich kann natürlich immer sagen,
Last right wins oder irgendwie sowas, aber eigentlich muss ich
dann auch wenn ich jetzt nicht von gitrille oder von Sourcecode
rede, variierende Revisionen. Oder die oder die Revision, die
jetzt verloren hat. Die muss ich trotzdem irgendwie
abspeichern, damit ich den User am Ende entscheiden lassen kann.
Und genau wie Git muss ich aber eigentlich auch jetzt in meinen
Applikationen commit Messages speichern und nicht die
geupdateten Dokumente. Und da gibt es 2 sehr populäre
Methoden für die eine ist schon Jason Patch, das gibt es
eigentlich schon sehr lange. Und Jason Petsch ist eigentlich
n Format, was ich an klassischer Weise, wenn ich ne rastapie
habe, den Patch endpunkt schicke.
Ne, es gibt ja get put pull delete.
Es gibt ja auch nen Patch Endpunkt und der nimmt nicht
immer, also muss er nicht, aber das ist eigentlich sehr gängig.
Diesen Patchdokument entgegen und ein Jason Patch Dokument
beschreibt im JSON Format, welche Änderungen gemacht
werden. Da kann ich zum Beispiel wenn
ich ein Array habe. Ja, ich hab n Dokument und.
List, Equels und dann NNNT Array.
Dann ist das Patchdokument was ich an den Server schicke
eigentlich nur, dass ich auf dem Feld.
Root Punkt List was im Moment ne leere Liste, also was n leeres
Array ist. Die Operation AD machen will und
zwar um den Wert weiß ich nicht. Hello World.
Ja, das heißt, ich schicke wirklich an den Server fast
schon so Events. Das erinnert sehr an Event
Sourcing. Ne schon so Events hin.
Was sind die Änderungen sind und die kann ich natürlich nicht nur
sammeln, sondern ich würde auch sagen, wenn ich das verwende
bringt mir das ja wir können eigentlich auch meine eigene
Folge zu Events Sourcing machen, das ist eigentlich super
spannend, dass das dem Thema so nah kommt, bringt mir ja sogar
ein Feature dazu, dass User theoretisch in der Zeit
zurückreisen können oder sich Änderungen nochmal auf einem
geupdated Dokument ja quasi dann abspielen kann, weil ich wieso
ein Feed an Änderungen bekomme. Ich schicke wirklich an den
Server die Änderung die gemacht werden soll oder beim Offline
First Fall schicke ich das an meine lokale Datenbank.
Speicher mir das dafür ab, wenn ich mal wieder eine Server
connection habe und schickt das dann auch an den Server, damit
die Dokumente lokal und auf dem Server wieder in Sync sind.
Zweite Variante ist allerdings, dass ich nicht diese Patch
Dokumente schicke, sondern dass ich es wirklich im Code
ausdrücke. Also dass ich wieso man nennt
das Delta Update funktioniert. Baue also anstatt zu sagen weiß
ich nicht. Hab jetzt irgendwie nen like
Counter irgendwo und wenn ich draufklicke der war auf 4
anstatt dass ich sage Like Counter ist jetzt 5 oder sogar
das Jason ne patchdokument schreibe setze den Like Counter
auf 5 kann ich auch die Funktion schreiben, zähle den Like
Counter um 1 hoch und dann kann ich da 3 mal drauf drücken und
jemand anders auf einem anderen auf einem anderen System was
auch offline war auch zweimal drauf drücken und wenn diese
Änderung aber alle an den Server gespielt werden führt ihr
einfach diese Funktion fünfmal aus weil es 5 Events waren dann
komme ich auch wieder auf die richtige Zahl und ich habe
keinen Konflikt beim Updaten sondern ich kann diese diese
Änderungen konfliktfreier zusammenspielen, das ist
natürlich sehr abhängig davon was man für eine Applikation
baut, aber beide sowohl die JSON Patch als auch diese Delta
Update Funktion. Sind eigentlich gerade sehr
relevant, wenn man offline First Anwendungen baut.
Euch geht es ja beim Thema Offline First um irgendwelche
Daten, die offline erstellt werden.
Von den Usern verwaltet werden und.
Solange das irgendwelche Daten sind, die sich.
In Textform. Irgendwie.
Gut ablegen lassen und auch dort die Änderungen sehr gut
dokumentieren lassen. Ich denke jetzt so ein bisschen
an meine Git Committee history wo ich sehen kann okay wie sind
die einzelnen Revisionen dann auf meinem Dokument wird das
natürlich schwieriger, wenn ich mit Binärdateien arbeite.
Du hast genau diese Situation beschrieben.
Packe ein Bild da rein und diese Grenzen sieht man ja auch im Git
Protokoll. Wenn ich jetzt anfange in meinem
Repository irgendwelche Binaries reinzulegen, dann wird mein
Repository sehr schnell sehr groß, weil ich dort halt nicht
die Deltas speichern kann, sondern immer die neuen
Dokumente ablegen muss, um halt diese Revisionen zu ermöglichen
und das ist natürlich etwas, über das man sich auch dann
Gedanken machen muss. Natürlich könnte jetzt Motion
hingehen und sagen okay wenn ich dieses Dokument in diesem
Dokument das Bild ersetze. Speichere ich einfach immer
wieder eine Kopie dieses Bildes und Referenzen.
Das aber dann wird natürlich der lokale Speicher immer größer und
ich muss natürlich das entsprechend dort
berücksichtigen, wie ich mit solchen Fällen umgehe.
Und deswegen ist es ja ganz häufig so, dass ich diese
Änderungen vielleicht nicht als Revision wirklich.
Speichern kann. Und da dann tatsächlich davon
ausgehen muss, dass die letzte Änderung vielleicht die ist, die
für alle übernommen werden muss und von daher ist es, glaube
ich, keine Entscheidung, wo ich sage, OK, ich implementiere es
für alle use Cases in der gleichen Art und Weise, sondern
ich muss es spezifisch entscheiden.
Was ist jetzt für eine bestimmte Art von Daten die beste
Herangehensweise im Kontext meiner Applikation?
Ja, aber was ich ja immer machen kann, ist Änderungen.
Also versuchen Deltas andere. Klar n Bild ist dann halt ne
große Änderung, aber die können dich ja theoretisch irgendwann
irgendwann wieder wegschmeißen oder zusammenfassen wenn du 5
mal den Like Counter geklickt hast und ich weiß du hast gerade
keine Verbindung und ich kannte die letzten 3 oder die letzten 4
Male wo du den Like Counter geklickt hast nicht an den
Server schicken könne ich das ja auch bündeln in ein Malte hat 5
mal auf den Button geklickt und das quasi versucht ein bisschen
kleiner zu machen, auch das kennt man so ein bisschen vom
Event Sourcing gehen am Ende glaube ich das offline First
auch ganz viel auf Messages am Ende wieder raus läuft, das
heißt wir haben irgendwie einen lokalen Messagestream.
Und bei Live Anwendungen ist es ja auch ohnehin so, dass das
Backend schickt mir auch wenn irgendwelche Updates sind,
irgendwelche live messages über Websockets zum Beispiel oder ich
synchronisiere 2 Anwendungen oder ich arbeite live mit
mehreren Personen einem Dokument, das passiert ja heute
schon alles über Messages, die in der Regel über Webstockets
geschickt werden und ich könnte dieses Message Konzept auch
einfach weiterhin lokal ausführen, so dass Änderungen
auf Dokumente über Messages passieren, die dann abgespielt
werden können und ich schicke die entweder sofort an den
Server. Wenn ich ne Verbindung habe oder
Staue die auf genauso wie der Server natürlich auch Messages
die an mich kommen sammelt bis ich wieder online bin ne wenn du
gleichzeitig im Dokument 5 Änderungen gemacht hast kann
können die auch aufgestaut werden.
Ich fahr aus dem Tunnel raus, bin wieder online und dann kann
er diese ganzen Messages zu mir schicken und die Spielen die
einfach in genau der Reihenfolge ab auf meinen lokalen Daten und
hab dann ja auch quasi wieder den gleichen Lifestand oder noch
cleverer vielleicht auch eher Schritt 2.
Ich spiel ich muss die Daten nicht 11 abspielen sondern der
Server war clever genug mir quasi so ein Snapshot nennt man
das in der Eventsourcing Welt zuschicken sagen Pass auf, da
musst du nicht 1 zu 1 abspielen hier du musst dich 5 mal den
Button den like Counter um 1 erhöhen, du kannst ihn auch um 5
erhöhen, das ist natürlich dann aber noch so ein bisschen extra.
Arbeit. Du hast gerade gesagt, dieses
Konzept von. Messages aufstauen, da hat man
dann irgendwie eine Art von Q, die halt befüllt wird mit allen
Operationen, die sich dann angesammelt haben und dann kommt
man natürlich auch dort in einen Bereich, wo man das auch im
Kontext. Ja, der Fachlichkeit der
Anwendung betrachten muss. Wo ist es sinnvoll, wo nicht?
Du hat es gerade dieses Beispiel dann dann drücke ich auf den
Like Button, wird das dann nachher abgespielt oder nicht?
Weil tatsächlich könnte es natürlich so sein, ich als user
Druck auf den Like Button hab gerade keine online Verbindung
ist passiert quasi nichts und drückt dann halt noch zweimal
drauf wie viele Likes wollte ich dann als User letzten Endes
abgeben wollte ich 1 abgeben oder wollte ich wirklich 3
abgeben? Da muss man natürlich dann auch
im Kontext der Fachlichkeit der eigenen Anwendung.
Schauen okay bei welchen Operationen ist es sinnvoll, die
zu sammeln und bei welchen gehe ich vielleicht dann doch hin und
gebe den Usern dort das Feedback, dass diese
Informationen. Nur einfach durchgeführt werden
dürfen. Das hat die Magie von offline
first. Also ich kann den User direkt
ein Feedback geben. Ich kann ihm sagen, Yo ist
angekommen, habe ich gespeichert, ist lokal auch
schon gespeichert, das heißt der User sieht ja direkt den
Countdown 1 hochfahren und das ist ja genau die Magie
eigentlich, wenn ich offline first mache, dass ich halt eben
nicht sagen, also ich will eigentlich im Jahr 2014.
Keine. Keine Drehrädchen mehr sehen
oder keine wie heißen die so so Loading Indicator mehr mehr wie
sie sehen sollen. Eigentlich könntest du mir
sagen, jo this like ist angekommen, sodass gar nicht die
Situation entsteht, dass der User 5 mal draufklickt, weil bei
der ersten 4 mal nichts passiert ist.
Wie baue ich das jetzt? Wie gesagt, Wir haben so ein
bisschen die die Arten und weisen beleuchtet, es gibt aber
natürlich Frameworks dafür, also wie gesagt Superbase wer das
benutzt, super populäres Backend as a Service System, die haben
es nicht, aber das ist das Most requested feature.
Automurch ist ziemlich cool, das stammt aus einem Research Lab
aus Kanada, soweit ich weiß, und die haben noch eine relativ
coolen Konferenz Talk dazu gemacht.
Den verlinken wir euch auf jeden Fall mal in den in den in den
Shownotes hier vom Podcast. Es gibt auch eine Technologie,
die nennt sich Power Sync, die sitzt zum Beispiel zwischen 2
Datenbanken, also da sage ich einfach wirklich pass auf, ich
lasse Power Sync im Hintergrund meine Datenbanken mit so ein
paar cleveren Regeln synchronisieren und rede
einfach. Quasi lokal mit der lokalen
Datenbank und Server mit der Serverdatenbank.
Das sind wir mal 2 Technologien Automurch und Power Sync, die
würden wir beide aber auch noch mal verlinken, da kann man drauf
zugreifen. Da kann er noch stark auch noch
zugreifen. Die vor allem auf euch zu
greifen. Aber da kann man, das kann man
sich mal anschauen. Und wer Lust auf das Thema
bekommen hat, der findet auch die Ressourcen, die wir zur
Vorbereitung benutzt haben und diese ne wir haben es erwähnt,
ganz viel ganze Konferenztalks und es passiert gerade irgendwie
viel in dieser developer Community, die verlinken wir
euch natürlich auch noch mal. Wer da Lust hat sich noch mal
ein bisschen über die 30 Minuten vom Podcast hier hinaus in das
Thema einzulesen. Ja, ich glaub n ganz wichtiger
erster Schritt ist, sich einfach Gedanken darüber zu machen.
Ist es im Kontext meiner Anwendung etwas, was sinnvoll
ist und bei ganz vielen Anwendungen ist es so.
Ich mein du hast gerade gesagt bei Motion ist es n Feature was
ganz viele Leute sich wünschen und ich glaube bei Anwendungen
die rein im Browser laufen ist das etwas wo vielleicht bei den
Usern gar nicht die Erwartung da ist.
Aber sobald ich irgendwie auf eine Plattform mit einer App
gehe, da ist wirklich auch die Erwartungshaltung der Anwender
da, dass diese Anwendung funktioniert und nicht wirklich.
Diesen Spinning Indicator mehr anzeigt, wenn gerade die
Internetverbindung schlecht oder nicht da ist.
Weil tatsächlich kann ich ja als Developer erkennen, ob das
Gerät, auf dem ich gerade laufe, eine Internetverbindung hat, das
relativ trivial, aber die Schwierigkeit ist häufig dann in
den Situationen, wo die Internetverbindung vom Gerät
zwar existiert, aber ich trotzdem nicht mit meinem
Backend kommunizieren kann. Und wie kann ich in diesen
Fällen eine gute User Experience?
Darstellen, und da ist man natürlich, wenn man tatsächlich
von diesem Offline Fall als Default ausgeht, immer schon in
der besten Situation, weil da hat man gar nicht mehr die die
Frage, wo ich checken muss, bin ich online, bin ich offline,
sondern der User arbeitet und ich arbeite im Hintergrund dabei
daran die Daten zu synchronisieren.
Aber genau, aber das ist doch eigentlich auch ein geiler
Schlusssatz, weil warum das glaube ich heute in der
Entwicklung so oft hinten hinten überfällt, ist, dass man
eigentlich sagt, in 99% der Fälle haben die User doch
eigentlich Internet und es ist teuer zu implementieren, das
Feature und. Es ist bestimmt nicht das
Allerwichtigste, auf der Prioritätsliste von einem
Product Manager. Aber genau wie du gerade
argumentiert hast mit okay es ist aber die geilere User
Experience und wir sind wir sind ultraschnell und wir sind
Resilien, das heißt, selbst wenn unser Backend mal ein Hick hat,
funktioniert die App für den User weiter, vielleicht merkt er
gar nicht, dass wir kurz mal irgendwie 5 Minuten lang offline
waren und sowas und. Und sich das also Performance
User Experience, eigene Resiliency in der Regel
wahrscheinlich auch günstigere Server, weil ich ganz viele Ping
Pong zwischen den Servern vielleicht gar nicht brauche.
Wenn ich ganz viel lokal mache und ich glaub, dass wir über
diese Seite argumentieren muss und das ist ne wie ich ehrlich
gesagt, das ist kein Feature ist, sondern also offline first
ist kein Feature, offline first ist ein Design patter.
Ich glaub, das war das perfekte Schlusswort für diese Folge
glaub ich. Sehr gut zusammengefasst.
Wie gesagt, alle Informationen findet ihr in den Shownotes und
wir hoffen ihr fandet das Thema auch so spannend wie wir.
Also ich fand es wirklich super interessant da nochmal
reinzugehen, nachdem ich mich vor einigen Jahren damit
beschäftigt hatte und ich hoffe euch interessieren.
Sich geworden. Ich habe mich auch gewundert bei
meinen. Und ich hoffe, es war für euch
genauso wertvoll und lasst uns gerne auch wie immer eine
positive Bewertung da, wenn euch diese Folge gefallen hat oder
wenn ihr noch nicht den Podcast abonniert habt, in eurer Podcast
App bitte den Podcast abonnieren.
Damit kriegt ihr dann auch jeden zweiten Montag automatisch die
neuste Folge auf euer Endgerät gespielt.
Wenn euch die Folgen unserer Arbeit hier gefallen hat, dann
freuen wir uns darüber wahnsinnig.
Wenn ihr Lust habt, uns einen Kaffee auszugeben.
Das ist quasi so bisschen unsere Entlohnung, dafür gibt es n bei
mir Coffee Link, dass er uns immer sehr bei den heißen
Temperaturen ist es auch bestimmt mal irgendwie n
spaghettieis, was wir uns. Von dem von dem von dem
Kaffeetaschengeld holen, obwohl da die Uhrzeit, die wir heute
ausnehmen, da brauchen wir auf jeden Fall morgen früh einen
Kaffee deswegen, da freuen wir uns auch immer, oder wenn ihr
die passende Nerd Tasse zu eurem Kaffee mit Toucas, Podcast
Branding und lustigen Sprüchen haben wollt.
Wir haben einen kleinen Mini Shop, auch da gibt es natürlich
die Links zu beidem in der Beschreibung.
Würden wir uns freuen, wenn ihr auch in 2 Wochen wieder mit
dabei seid. Beim to do Developer Podcast und
bis dahin wünsche ich euch alles Gute und.
Schreibt ganz viel Coach und habt eine gute Zeit.
Gute Nacht bis dahin.