Flutter Storage Solutions

Hallo und herzlich willkommen zu einer neuen Deep Dive Folge der ProgrammierBar. Und heute gibt es eine Premiere, denn ihr hört hier nicht wie gewohnt Dennis als Moderator der Podcast Folge, sondern mich, den Jojo. Und der Grund dafür ist, dass der Dennis immer noch auf der Rückreise aus seinem Urlaub ist und auch Fabi diese Woche Urlaub hat. Und deswegen, ja, reden wir heute über das Thema, welche Storage Lösungen in Flutter Web Projekten oder Flutter Projekten gut einsetzbar sind. Und wir haben natürlich in unserem Projekt "Vier Bilder, 1 Wir haben da eben einige Erfahrungen damit gesammelt. Wir haben etliche Storage Lösungen wirklich evaluiert. Wir haben einige Prototypen mit unterschiedlichen Datenbanken implementiert, um uns das genauer anzuschauen. Und wir haben auch eben verschiedene Storage Lösungen über die Zeit auch in der Produktion genutzt. Und haben dabei einfach einige Erfahrungen und Erkenntnisse gesammelt, die wir mit euch teilen möchten. Und da versuchen wir euch vor allem da wirklich einen gesamten Überblick über alle bekannten Storagelösungen oder die meisten bekannten Storagelösungen von Flutter zu geben und euch dann für die Zukunft einfach eine Entscheidung Grundlage zu geben, wenn ihr genau die gleiche Fragestellung habt, welche Storage Lösung eben für euer Flutter Projekt das Richtige ist. Und ich bespreche das Thema nicht alleine, sondern ich habe mir einen Experten zu dem Thema eingeladen und das ist der Gabriel Terwesten. Und ihr kennt Gabriel vielleicht schon aus unserer Deep Dive Folge 101. Da haben wir auch schon mal zum Thema Couchbase und Couchbase Lite eben gesprochen. Eine Datenbanktechnologie, die wir inzwischen eben in Produktion einsetzen. Und zum damaligen Zeitpunkt warst du noch Freelancer. Hast aber eigentlich so gar nicht mit Flutter, sagen wir mal, auf deiner Arbeit gearbeitet, sondern da hast du eher mit ganz anderen Technologien gearbeitet, oder? Genau, das war vor allem Spring Boot und Angular, also Webentwicklung. Flutter ist aber so ein spannendes Thema, wo ich irgendwie darauf gestoßen bin, dass mich das da zu hingezogen hat, damit zu arbeiten und zu experimentieren und so auch irgendwie ich dann zu Datenbanken gekommen bin, weil die braucht man ja doch irgendwann mal, wenn man ein bisschen was komplexeres bauen möchte und irgendwie auch dann zu Couchbase Light gefunden darüber über dieses Thema. Also es war wirklich so ein intrinsisches Interesse von dir, dass einfach mal diese Technologie am Horizont aufgetaucht ist, du das interessant fandest und gesagt hast, hey, ich gucke da einfach mal ein bisschen genauer rein und das hat dich dann so begeistert, dass du dann auch wirklich private Apps damit entwickeln wolltest, oder? Ja, ich meine, wenn man irgendwas Neues lernt, also ein neues Framework oder sowas, versucht man ja mal irgendwie eine ToDo App zu bauen oder irgendwas in diese Richtung. Und braucht ja nicht irgendwann, musst du irgendwie mal Daten speichern. Einfach um was umzusetzen, auch was kleineres schon. Und beschäftigt sich dann damit, was gibt es da im Ökosystem an Lösungen an, die verfügbar sind. Und wenn man dann vielleicht versucht, etwas bisschen Aufwändigeres zu bauen, was auch in Richtung offline first geht, was ja so ein Thema ist, gerade was in der Mobilentwicklung wichtig ist, kommt man dann eben auch auf Anforderungen wie Volltextsuche, die nicht unbedingt so einfach zu finden sind. Also auch du warst mit dem Thema, hast konfrontiert, welche Storage Lösung ist irgendwie die passendste für Flutter. Und ich glaube, man merkt natürlich, dass das Ökosystem einfach da noch sehr jung ist. Es gibt einige gefühlt etabliertere Lösungen, die so angeboten werden. Aber es gibt natürlich auch sehr viel drumherum, was gerade auch im Entstehen ist, wo man ja manchmal wirklich die Schwierigkeiten hat, dann erst mal einzuschätzen, wie praktikabel ist das? Hat es nur so wenig Stars, weil es vielleicht einfach noch ein bisschen neuer ist? Und da braucht man schon eine gewisse Zeit, um sich da irgendwie reinzulesen, die verschiedenen Ansätze auch miteinander zu vergleichen, um das Richtige zu identifizieren. Und das wollen wir heute natürlich mit euch ein bisschen vereinfachen. Und ich glaube, wir können auch in dem Zuge noch eine weitere freudige Nachricht verkünden, weil wir hatten vor kurzem eine komplizierte Supportphase für unser Flutter Projekt, wo du uns unterstützt hast im Projekt. Und wir haben einfach gemerkt, dass es natürlich zwischen dir und Lothom sehr gut harmoniert und freuen uns sehr, dass wir dich jetzt für Lothom gewinnen könnten. Das heißt, super cool. Also du bist ab dem 1. Januar dann eben Teil des "4 Bilder 1 Wort Projektes. Und ja, ich glaube, wir können einfach extrem davon profitieren, natürlich über dein Wissen über Datenbanken, auch über Flutter allgemein. Und ich glaube, ich kann da auch persönlich noch sehr, sehr viel von dir lernen. Also ich freue mich einfach da super auf die Zusammenarbeit dann im nächsten Jahr und dass das so gut geklappt hat. Ja, ich mich auch. Cool. Also, genau. Wir geben euch jetzt mal irgendwie so den Überblick über die Datenbanken, die wir uns anschauen möchten. Und das sind insgesamt sogar neun Stück an der Zahl. Das ist also eine ganze Menge. Es gibt noch ein paar mehr da draußen, aber wir haben uns wirklich so die bekanntesten und größten eigentlich rausgenommen, um die zu vergleichen. Und das ist natürlich einiges, was wir vor uns haben. Also halten wir uns mal ran. Und wir haben auch gerade auf dem programmierbaren Meetup ein Talk über dieses Thema gehalten. Und wir packen letztendlich die Links zu den Präsentationen in den Show Notes. Also alle ausführlichen Informationen findet ihr dann auf den beiden Folien, auf den beiden Slides, die wir euch dann bereitstellen. Und da könnt ihr das auch so ein bisschen nachvollziehen. Und was wir uns heute anschauen werden als Technologien ist zum einen natürlich Shared Preference. Das ist, glaube ich, eine der etabliertesten Lösungen oder das, was man sehr häufig natürlich in der nativen Mobile Entwicklung nutzt. Wir gucken uns das Thema SQLite mit SQL Flight an, gucken uns dann auch, sagen wir mal, eine bisschen höhere Ebene von einem SQL Mapper an mit Drift. Und dann gibt es eben noch zwei weitere Datenbanken von Simon Leier, auch ein deutscher Entwickler, HiveDB und nicht sein Nachfolger, aber das aktuelle Programm. Projekt, an dem er eigentlich arbeitet, was super spannend ist, ISA. Wir gucken uns ganz kurz Objectbox an, was das vielleicht euch bieten kann und natürlich dann vielleicht auch die anderen drei großen Pendants, die es auch in der Data Storage Welt gibt, mit Google Firestore, MongoDB Atlas und Couchbase. Und ich glaube, was im Vorfeld vielleicht so ein bisschen wichtig ist, dass wir so auch mal definieren, was waren überhaupt Kriterien, nachdem wir uns Datenbanken angeschaut haben, nachdem wir die bewertet haben, weil wir versuchen, das alles so ein bisschen einzuordnen für euch. Was gibt es, sind die Vor und Nachteile? Und für uns war natürlich ein wichtiger Faktor eben, wie sieht das Lizenzmodell der Datenbanktechnologie aus? Also ist es irgendwie Open Source entwickelt, dass man auch sehen kann, was steckt da eigentlich unter der Haube, wenn es eine Lizenz ab einem gewissen Grad letztendlich der der Technologie gibt, also der Ausbaustiefel, welche Funktion man nutzen kann, wie ist das Lizenzmodell dann strukturiert, welche Kosten sind, kommen dann auch auf einen zu. Was wir auch mit berücksichtigt haben, ist natürlich, haben wir ein Schema in der Datenbank oder ist die Datenbank schemalos? Also das werden wir auch gleich noch ein bisschen genauer erklären, was vielleicht die Vorteile von Schema und Schema los sind, wenn man wirklich dann auch über die Zeit seine Daten erweitern möchte. Welche Abfrage Möglichkeiten habe ich? Das ist ja oft auch der Punkt, an den du gestoßen bist, Gabriel. Irgendwann willst du an eine Daten rankommen. Viele Datenbanken haben eher so einen Key Value Store Ansatz, wo du nur über den Key letztendlich auf deine Daten wieder zugreifen kannst. Aber es gibt natürlich sehr oft die Anforderung, dass du auch in irgendeiner Form Abfragen schreiben kannst, um nach bestimmten Kriterien dann Daten aus deiner Datenbank zu ziehen. Und das bieten natürlich nicht alle, deswegen ist das für uns natürlich auch ein Kriterium, wo wir so ein bisschen unterscheiden wollen, wie potent sind eigentlich, sagen wir mal, die Query Möglichkeiten, die uns die Datenbanktechnologie gibt. Was wir uns am Ende so ein bisschen anschauen werden, ist die Performance. Ja, ist, glaube ich, dann natürlich nur für große Datenmengen wirklich sehr aussagkräftig oder auf die Erkenntnisse gehen wir am Ende nochmal ein. Und was aber für uns natürlich speziell im Projekt wichtig war, ist die Möglichkeit, unsere Daten irgendwie zu einem zentralen Repo, zu einem zentralen Server oder einer zentralen Datenbank Datenbank eigentlich zu sünken. Wir nutzen das natürlich vor allem, um halt dem Benutzer das Spielen über mehrere Geräte zu ermöglichen oder dass er die Möglichkeit hat, seinen Spielstand auch eben auf ein neues Gerät zu übertragen. Und dafür sollte es natürlich möglich sein, dass auch da von der Datenbanktechnologie auf Flutter Seite irgendein Mechanismus schon angeboten wird, der es einem sehr einfach macht, letztendlich da ein System anzubinden, was letztendlich dann die Speicherung der Daten auf einem zentralen Platz in der Cloud vornehmen kann. Wir gucken uns ein bisschen an, wie ist der aktuelle Plattform Support, also für welche Plattformen die Flutter unterstützt, ist auch die Datenbanktechnologie unterstützt und was für uns natürlich auch wichtig ist, die Developer Experience. Wie gut kommt man in das Projekt rein, wie gut ist die Dokumentation, wie gut ist die API oder komplex ist die API, also wie einfach ist es letztendlich, das Produkt dann wirklich für sein Projekt einzusetzen? Was ich auch noch ein wichtiges Kriterium finde, ist wie gut ist oder wie ist das Unternehmen aufgestellt oder der Entwickler, der dahinter steht, kann man Support bekommen? Wird da regelmäßig, gibt es regelmäßige Updates? Wie ist da die Situation gerade bei Datenbanken, die ja auch so eine zentrale Komponente sind von der App und Daten wichtig sind, dass sie konsistent und sicher gespeichert werden können, ist es glaube ich, wichtig, dass da langfristig auch Support dahinter steht und man sich darauf verlassen kann, dass man die Daten weiter. Nutzen kann. Ja, definitiv guter Punkt, dass du es anführst. Das ist natürlich auch etwas, wo wir auch unterschiedliche Erfahrungen mitgemacht haben und das natürlich auch ein wichtiges Entscheidungskriterium für uns war, für welche Lösung wir uns dann entschieden haben. Deswegen greifen wir auch das ein bisschen auf. Ich denke, was interessant ist, vielleicht vorher irgendwie zwei Themen zu, also wir werden auch ein paar Themenkomplexe vielleicht während dem DEEP darf wir in der Folge auch dann aufgreifen, ein bisschen vertiefen und auch erklären. Aber was man vielleicht im Vorfeld nochmal irgendwie unterscheiden sollte, ist so der Begriff zwischen Schema und schemalosen Datenbank. Was ist eigentlich der Unterschied? Was sind die Vor und Nachteile? Schema Datenbank ist natürlich etwas, was gefühlt so ein bisschen älter ist. Also zumindest alles das, was man mit SQL eigentlich beschreibt, ist ja auch das, was man sehr nahe letztendlich mit einer schemabehafteten Datenbank in Verbindung bringt. Und was, sagen wir, der Aufbau von von der Schema Datenbank ist, dass man erstmal sozusagen die Struktur seiner Datenbank wirklich fest definiert und sagt, man hat da irgendwie sein Tabellenschema zum Beispiel in SQL und da schreibt ganz genau, okay, ich habe jetzt die und die Felder, die haben diese Datentypen, ich habe den Index, der auf jetzt in dem Bereich liegt. Und so werden die Daten natürlich auch sehr kompakt dann auch auf das Festplattenformat, also auf die Festplatte dann geschrieben. Das ist der große Vorteil, dass man natürlich genau weiß, wie groß ist jedes, jeder einzelne Eintrag meiner Tabelle. Und ich kann die natürlich sehr gut layouten. Und man hat auch eine sehr, sehr klare Struktur, also wie letztendlich die Daten irgendwie zusammenhängen. Man kann über entsprechende Keys natürlich auch die ganzen Relationen sehr gut modellieren. Ist etwas, was sehr zum Teil natürlich aufwendig ist, das im Vorfeld zu machen. Aber was einem nachher schon sehr gut einen Überblick darüber gibt, wenn man es nicht auf anderen Ebenen nochmal dokumentiert hat, wie sind eigentlich meine Daten organisiert und wie sieht mein Modell an der Stelle aus. Der große Nachteil, der natürlich dann immer, wenn man mit SQL gearbeitet hat, dann gleich zum früher oder späteren Zeitpunkt eigentlich eingetreten ist, dass man eben seine Daten irgendwie verändern musste. Also es ist ja eigentlich immer so, man startet mit einer gewissen Vorstellung, wie ein Modell auszusehen hat und dann stellt halt man fest im Laufe und Evolution eines Projektes und Produktes, da fehlen aber noch weitere Daten, die man weiterhin braucht oder die man noch hinzufügen muss. Und dann ist es natürlich bei diesem Schema behaftenden Datenbanken so, dass man eigentlich immer einen Migrationsschritt hat, wo man letztendlich dieses Schema erweitert. Und auch die ganzen Daten müssen natürlich dann eben in diesem neuen Layout, in diesem neuen Schema dann neu angeordnet werden auf der Platte. Und gerade bei älteren Systemen war es halt oftmals so, dass man das nicht on the fly machen konnte, sondern wirklich da entweder entsprechende Downtime, gewissen Green Blue Deployment irgendwie brauchte in der Datenbank, um sicherzustellen, dass sozusagen dieses neue Schema erstmal aufgebaut wird, die ganzen Daten aus dem alten Schema überführt werden, in die neue Struktur und neu abgelegt werden und dann final vielleicht erst das Switch auf dieses neue Schema passiert. Was teilweise wirklich auch Tage dauern kann. Und deswegen der große Vorteil, den man eigentlich bei schemalosen Datenbanken hat, ist ja, dass man dieses Schema nicht braucht. Also wie sieht so ein Schema dort eher aus? Es ist so, dass ich da völlig frei bin, welche Daten ich eigentlich in einem Dokument hinterlegen kann. Ich habe ja schon was gesprochen, was eigentlich damit so einhergeht. Also ist auch natürlich vor einigen Jahren unter NoSQL ein sehr großer Begriff gewesen. Und es gibt natürlich sehr viele Datenbanken, die in dem Bereich entstanden sind. Die bekannteste ist wahrscheinlich MongoDB. Aber wie kann ich mir da letztendlich so einen Aufbau von einem Dokument von einem Datensatz vorstellen? Gerade so das Thema geschachtelte Daten und Daten, die eigentlich eher so aus JSON APIs kommen, ist so der Treiber gewesen für diese Entwicklung von den NoSQL Datenbanken. Wo der Unterschied halt in Bezug auf bekannten SQL Datenbanken vor allem darin liegt, dass man halt auch in den Rows oder in den Zeilen nur so sehr flache Datenhierarchien hat und sonst immer nochmal eine neue Tabelle bräuchte für geschachtete Daten. Bei Realm oder auch bei ISA, die ja eigentlich NoSQL Datenbanken sind, sehen wir wieder ein Aufkommen von Schemas, weil sich auch Vorteile gezeigt haben davon, dass man diese Metadaten hat. Aber Also. Von der Struktur ist es so, dass eigentlich in der schemalosen Datenbank, wie du es ja beschrieben hast, man kann verschachtelte Daten, also ich habe einfach kein Schema vorgegeben. Ich kann jederzeit eigentlich sagen, es gibt jetzt ein neues Datenfeld und es fangen halt, sobald man anfängt sozusagen Daten, diese zusätzlichen Daten zu schreiben, enthalten alle meine Objekte dann einfach dieses zusätzliche Datenfeld. Und es gibt nicht dieses feste Schema, was dann auch so auf der Platte vorgehalten wird, sondern es gibt immer sozusagen ein gewisses Datenbereich und dann noch ein gewisses Padding, weil ein Datensatz könnte so kommen. Groß sein könnte, aber ein bisschen größer sein. Wenn aber neue Daten entstehen, kann es erst mal sozusagen bis zu dieser Größe des Paddings eben noch genutzt werden. Und danach muss ich halt schon gucken, dass die Sachen irgendwie neu layouten. Aber es ist eigentlich undefiniert, wie groß eigentlich jeder Datensatz ist. Sondern es gibt einfach nur, sagen wir mal, so eine gewisse Heuristik. Im Schnitt ist jedes Dokument so groß. Deswegen habe ich, sagen wir mal, diese Standardgröße und dann noch ein gewisses Padding, was ich einfach vorsehe für den Fall, dass einfach Daten erweitert werden müssen. Was das ja als gewissen Vorteil hat, wie Sie es eben gesagt haben, ich kann natürlich wirklich einfach mein Modell erweitern, während also mit den neuen Features, mit den neuen Informationen, die ich eben wie an meine Daten schreiben muss, kann ich das einfach hinzufügen, einfach erweitern. Aber ich muss natürlich auch sicherstellen, dass ich alle alten Schemas in dem Moment für alle Zukunft eigentlich noch unterstütze. Also ich verlagere so ein bisschen natürlich diese Notwendigkeit. Man verlagert die. Migration ins Modell. Wenn man Modelle hat, die irgendwie in den Klassen existieren, in der Sprache, mit der man arbeitet hat, muss man dort oft die Migration durchführen, was Vorteile haben kann und Nachteile haben kann, weil man eben parallel mehrere Schemas unterstützen muss, mehr oder weniger. Und man dann auch so Übergangszeiten hat, wo man erstmal von einem alten Feld auf ein neues Feld umsteigen muss. Und man letztendlich auch eine Form von Migration hat. Aber man hat viel Flexibilität, weil man nicht unbedingt alles auf einmal machen muss, eine Migration auf einmal durchführen muss. Und man nicht unbedingt an die Lösung gebunden ist, die die Datenbank vorsieht für eine Migration. Das ist so der Vorteil, würde ich sagen. Kann ein Vorteil sein, dass man wirklich alles auf einem Schlag macht und deswegen natürlich auch Relationen relativ einfach dann irgendwie umschreiben kann, also wirklich komplexere Modellstrukturen, sowas kann man natürlich bei schemalosen Datenbanken auch machen. Und das, was ich auch gemerkt habe oder wie die Erfahrung natürlich mitgemacht haben, dass natürlich so ein Vorhalten von alten Schemalosen was auch etwas sein kann, was du wirklich für alle Zeit eigentlich machen musst. Also gerade bei natürlich mobilen Clients, die auch dann irgendwie Daten erweitern. Du weißt nie ganz sicher, wann ist letztendlich die Migration für den Einzelnen, ist sie vielleicht irgendwann mal abgeschlossen, aber für das Gesamtmodell ist sie vielleicht nie abgeschlossen, weil manche Clients einfach nie aktualisiert werden oder ähnliches. Also da musst du schon sehr viel Code einfach sehr lange mitschleifen und hast vielleicht niemals den Zeitpunkt, wo du sicher sagen kannst, okay, ab dem Zeitpunkt kann ich sozusagen die Unterstützung des alten Codes, des alten Pfades eben wieder Abschneiden und dann mal raus aus dem Code nehmen. Das andere Thema, was ich glaube ich auch sehr spannend finde, wenn wir das vorher kurz beleuchten, ist das Thema oder der Begriff "Offline First", der glaube ich auch so um die 2013er Jahre sehr stark aufgekommen ist. Ich glaube auch mit dem Thema PWA ist natürlich sehr groß wurde, aber das ist natürlich auch etwas, wo Couchbase sehr stark wird. Deswegen kannst du uns glaube ich so ein bisschen besser beschreiben, was Offline First eigentlich bedeutet. Ich glaube Offline First wird so in erster Linie dadurch motiviert, dass man sich nicht wirklich hundertprozentig darauf verlassen kann, dass immer eine Netzwerkverbindung möglich ist. Aber wenn jetzt eine App so strukturiert ist, dass eigentlich alle Daten irgendwo in einem Backend liegen und immer erstmal von dort geladen werden müssen, dann bedeutet so eine Unterbrechung von Netzwerkverbindung halt, dass die App eigentlich nicht mehr wirklich nutzbar ist für den Zeitraum. Und was Offline First, das ist ja der Offline First Ansatz, versucht das eben, das ein bisschen umzukehren, den Ansatz nicht zu sagen, man ist in erster Linie immer online, sondern man denkt immer erstmal aus der Sichtweise, was kann ich alles umsetzen, komplett offline, so dass ich da resistent bin gegen den Fall, dass ich keine Verbindung aufbauen kann. Es kann nämlich auch sein, dass Verbindungen können auch dadurch verhindert werden, dass man in einem Unternehmensnetzwerk ist, wo bestimmte Verbindungen nicht erlaubt sind. Und auch da ist es dann sinnvoll, wenn man trotzdem noch eine App nutzen kann, mit den Daten, die vielleicht lokal schon vorhanden sind, dass man die weiter bearbeiten kann und so einfach dem Nutzer mehr Freiheit bietet in der Nutzung der App. Der Schluss ist natürlich der, dass man all die Funktionen oder viele Funktionen lokal umsetzen muss und dementsprechend auch Datenbanken braucht, die einem das ermöglichen. Und da gibt es so einen wichtigen Punkt für mich, eben welche Queries sind möglich, ist Volltextsuche möglich bei Apps, die relativ viele Inhalte haben, die auch irgendwie durchsuchbar gemacht werden müssen. Und der andere wichtige Punkt ist, wie regelt man eben, was du auch schon erwähnt hattest, das Synchronisieren von den lokalen Daten mit dem zentralen Server. Weil wenn jemand offline arbeitet, irgendwas verändert, kann es zu Konflikten kommen mit Änderungen, die auf anderen Geräten stattgefunden haben. Das ist so ein großes Thema, wie wird das umgesetzt in solchen Lösungen. Und wie funktioniert letztendlich die Synchronisierung mit einem zentralen Datenbank? Das ist wichtig. Also Begriff "Offline First" ist einfach so dieses Szenario, was man beschreibt, dass eigentlich die Baseline wirklich diese Offline Nutzung ist. Ich habe eigentlich die Möglichkeit oder ich will auf jeden Fall die Möglichkeit bereitstellen, meine App komplett offline zu nutzen. Offline mit natürlich den zuletzt mit dem letzten Datenstand, den ich irgendwie synchronisiert habe, zu nutzen. Und alles Weitere sind sozusagen diese Online Features, die sind Zusatzfunktionen, die eigentlich oben drauf kommen, die ich dann nutzen kann, wenn ich wirklich eine Verbindung dann habe. Ja. Genau. Okay. Das Wichtige ist, glaube ich, nur, wenn man sich wirklich darüber überlegt, dass Offline First für einen wichtig ist, dass man natürlich sowas von Anfang an eigentlich mitbedenkt, also dass man sein gesamtes System so konzipiert natürlich die Datenbank Technologie entsprechend auswählt, dass man das von der Seite unterstützt hat, aber dass man auch die gesamte App Struktur natürlich so ein bisschen daran anpasst, dass es möglich ist, Offline First zu arbeiten. Ja, es ist schwierig, glaube ich, da eine App komplett umzubauen von einem Ansatz auf den anderen. Es ist natürlich immer auch, kommt darauf an, wie komplex die App ist. Aber sinnvoll ist es von Anfang an, das eigentlich zu berücksichtigen, wenn man weiß, dass man diese Anforderungen hat, dass man letztendlich damit in seine Planung für die App geht und das eigentlich dann entsprechend berücksichtigt. Ja, es hat auch Vorteile, einfach dieser Ansatz über die Resilienz gegenüber Netzwerkausfällen hinaus, hast du auch die Möglichkeit, tendenziell eher die Möglichkeit, ein bisschen was einzusparen an Traffic und so etwas anzubieten, wie kein Signing Zwang zu haben, was einfach bei vielen Nutzern mitunter eine Hürde ist, die sie nicht nehmen wollen oder nicht können und auch generell ist es etwas, was vorgeschlagen wird von Apple in den Guidelines, dass man erstmal Apps möglich macht zu nutzen, ohne direkten Sign In zu verlangen, weil es einfach die. Hürde darstellt. Ja, das haben wir auch immer wieder festgestellt, also dass die Hürde einfach sehr groß ist, weil die Leute natürlich auch nicht wissen, was wir dann alles an Daten übertragen, wenn sie diesen Sign In machen. Also es ist einfach eine gewisse Zurückhaltung dann einfach da. Und deswegen ist es natürlich gut, die Systeme zu haben, die das einfach nicht benötigen, dass es zwar möglich ist, aber vielleicht ohne diesen Sign In Zwang wirklich zu haben. Ja, aber das war glaube ich schon eine sehr gute Einführung oder auch was wirklich Offline First bedeutet und warum es vielleicht für uns wichtig war. Darauf kommen wir später nochmal zu sprechen. Lasst uns mal mit den Datenbanktechnologien anfangen. Und vielleicht ist es keine richtige Datenbank Technologie. Also deswegen sprechen wir auch so ein bisschen von Storage lösen und parallel, weil Datenbank ist natürlich schon ein Begriff, der gefühlt so ein bisschen mehr machen kann, als vielleicht nur Daten zu speichern, sondern auch diese Zugriff Möglichkeiten bieten sollte. Und Shared Preference ist natürlich etwas, was glaube ich im mobilen Umfeld sehr häufig genutzt wird, weil es damals so auch eine Speicherlösung war, die sehr etabliert war und auch natürlich auf beiden Plattformen irgendwie ähnlich vom Konzept her implementiert ist. Und was Shared Preference ist ja eigentlich sind, ist ein Key Value Store. Key Value Store ist ja von einem Datenbankmodell etwas, wo ich eigentlich immer einen Datensatz zu einem bestimmten Key, zu einem uniken Key eigentlich hinterlege, wo aber, sagen wir mal, auch diese Key Value Stores oftmals gar nicht mehr Möglichkeiten geben, an meine Daten ranzukommen. Aber erstaunlicherweise kann man natürlich sehr viele Daten eigentlich schon mit diesem Grundschema eigentlich modellieren. Was sage ich habe für jedes Dokument, für jeden Datensatz ein eindeutiger ID, die ich mir auch wieder aufbauen kann. Ich kann auch über diese Dokumenten ID und im Prefix dann irgendwie Collections abbilden. Also da ist es eigentlich schon so, dass wir zum Beispiel auch alle unsere Funktionität eigentlich auf einem Key Value Store abbilden können und nur an wenigen Stellen vielleicht mal diese Query Möglichkeiten brauchen. So hat. Ja Firebase eigentlich auch angefangen. Einfach mit einem relativ simplen Store für JSON Daten eigentlich, so strukturierte JSON Bäume. Und war für viele Entwickler ausreichend, einfach die Möglichkeit, das zu haben, zu speichern, so die Daten zu speichern und zu synchronisieren. Ja, ist ja heutzutage auch immer noch so, dass jetzt in die Realtime Datenbank und auch natürlich auch der Firestore genau nach diesem Prinzip arbeitet. Ich habe immer eine DocID, die irgendwie einfach ein String ist, die ich irgendwie generiere, aber es gibt immer diese eindeutige Idee, die natürlich auch irgendwie vom System erzeugt werden kann. Und für die Shared Preferences gibt es natürlich im Flutter Umfeld das Shared Preferences Package. Das ist direkt vom Flutter Team entwickelt und auch maintained und hat mit Abstand die meisten Likes auf PubDev. Was einfach daran liegt, okay, es ist einfach eine Lösung, die natürlich direkt vom Flutter Team kommt, die auch so für sehr viele Anwendungsfälle vielleicht ausreichend ist, wenn man eine sehr kleine App hat und vielleicht nicht besonders viele Daten irgendwie speichern muss. Unterstützt erstmal nur skalare Datentypen. Also ich kann dort einfache Bools, Integerwerte, numerische Werte, also real Werte auch abspeichern und hab dann glaube ich, noch irgendwie die Unterstützung für Strings und Stringlisten, aber das war es dann auch schon. Also alle anderen komplexen Daten kann ich natürlich selber wieder zu einem String serialisieren, indem ich JSON nehme. Aber es ist nicht etwas, was out of the box mit sich kommt, dass ich dort auch komplexere Daten ablegen kann. Und was eigentlich Shared Preferences unter der Haube macht, ist, dass es eigentlich die Implementierung der entsprechenden Plattform dann einfach kapselt. Also ich nutze dann zum Beispiel auf iOS einfach eines User Defaults, Android die Shared Preferences und auch für das Web nutzt es dann eine Local Storage, sodass es einfach eine Kapselung ist, die dann über Message Channels eben aus der Dart Ebene in die nativen Ebene kommuniziert. Ich glaube, Message Channels muss man vielleicht noch kurz erklären. Das kannst du vielleicht sogar auch besser. Ich habe mein Verständnis, das ist einfach so, das ist einfach der Kommunikationsmechanismus von Flutter. Ich weiß gar nicht, ob es unter der Haube dann wirklich Datenbereiche sind, die gemappt werden, aber es erlaubt einen letztendlich mit entsprechenden Marshalling der Daten aus der Dart Ebene eben Daten in die native Ebene zu geben, wo ich dann so einen einfachen Dispatcher habe, um Nachrichten eben entgegenzunehmen, darauf entsprechende Methoden dann auszuführen und Daten wieder zurückzugeben. Genau, es ist halt immer synchron. Es gibt eine asynchrone Kommunikation zwischen dem nativen und dem Flutter Teil, was ein bisschen ein Overhead hat. Aber wie du gesagt hast, es ist einfach eine Art Serialisierung von Daten, also ähnlich wie JSON gibt es da einen Codec, der genutzt wird. Der Gegenpart dazu oder eine Lösung, die jetzt im Kommen ist, ist Dart FFI, um ein bisschen eine performantere Kommunikation zu ermöglichen zwischen Flutter und Native oder Dart und Native. Und FFI steht in dem Fall für? Wolltest du gerade erklären? Genau, es. Steht für Foreign Function Interface. Und das ist das Interface, mit dem Dart Programme C Funktionen aufrufen können. Und auf den unteren Ebene ist eben viele Kommunikation über C Schnittstellen, die einfach sehr performant ist und da viele Plugins mittlerweile drauf umsteigen, weil wegen der Performance in erster Linie. Also es geht eben nicht diesen Weg, dass ich sage, hey, ich habe auf der Dart Seite meinen Client oder den Message Creator, dann habe ich auf der nativen Seite den Dispatcher und habe eben diese Kommunikation auf diesem binären Kanal dazwischen, muss dann wieder vielleicht auch eine C API auf der nativen Seite ansprechen oder eben natürlich ein Java oder ein Zwift SDK, sondern ich gehe eigentlich direkt aus Dart auf diese, spreche diese C Bibliotheken an, die jetzt mit in meinem Flutter Package liegen oder in meinem Bundle liegen. Ja, genau das ist der große Unterschied und das ist vielleicht auch so ein bisschen das, was vielleicht gleich in die Bewertung mit rein spielt, weswegen vielleicht Chat Preference für euch nicht immer der sinnvollste Ansatz ist, gerade wenn ihr euch Performance anguckt. Der große Vorteil ist es erstmal natürlich Open Source und einfach eine Nutzung sehr etablierte Standards, die einfach in der mobilen Welt natürlich schon seit, ich will nicht sagen Jahrzehnten, aber einem Jahrzehnt oder bisschen länger irgendwie genutzt werden. Was hier so ein bisschen der Nachteil ist, ich habe irgendwie nicht die Möglichkeit, meine Daten gut zu segmentieren, das heißt so unterschiedliche Datenbereiche irgendwie über meinen Key Values so aufzuspannen. Das kann ich mir natürlich selber bauen, indem ich sage, okay, ich mache wirklich so ein Prefix Handling. Es gibt jetzt irgendwie einen Daily Daten Bereich, wo halt einzelne Daten geschrieben werden. Ich generiere dann einfach einen Suffix für jeden einzelnen Datensatz. Und so kann ich natürlich auch die Daten so ein bisschen irgendwie klustern, aber an sich hätte ich wirklich nur die Möglichkeit, einfache Keys zu verwenden und habe natürlich auch nur die sehr einfachen Datentypen, wo ich dann doch sehr schnell letztendlich eine eigene Serialisierung der Daten brauche. Ich habe überhaupt keine Abfragen. Also es ist wirklich nur dieser reine Keys Zugriff, den ich eigentlich auf die Daten bekomme. Und es werden auch alle Daten auf einmal geladen. Was mitunter ein Problem ist, wenn viele Daten gespeichert werden, was einige Zeit. Brauchen kann. Genau, also die Daten werden eigentlich alle direkt sozusagen beim ersten, also das Aufmachen, das Instanzieren von Shared Preference ist eine asynchrone Methode, aber in dem Moment werden eigentlich alle Daten aus dem nativen Teil in die DATEbene geholt. Danach sind natürlich alle GET Aufrufe sehr schnell, aber gerade wenn natürlich die Daten größer werden, ist es natürlich das Problem, dass ich da keine Möglichkeit habe, das EMI so ein bisschen aufzusplitten. Also es ist für einen kleinen Funktionsumfang wirklich geeignet, einen kleinen Umfang von Daten sehr geeignet, aber sobald das Immi dann ein bisschen größer wird, sollte man wahrscheinlich schleunigst davon Abstand nehmen, dann die Shared Preferences zu nehmen. Und ich habe natürlich keine Synchronisation und auch die Unterstützung von Plattformen, das ist der positive Teil, da gibt es eigentlich einen recht großen Support, dass ich eigentlich das komplett durch diese Flutter Plattform Welt eigentlich nutzen kann und jegliche Ausprägung unterstützt wird. Okay, cool. Ja, also Shared Preferences nur für kleine Datenmengen. Für Einstellungen am besten. Genau, für die. Preferences. Auch. Dann die nächste Technologie, die natürlich auch sehr etabliert ist im mobilen Bereich, SQLite. Und da gibt es ja sozusagen als Kapselung dieses SQL Flight Package und das ist sehr ähnlich von dem Aufbau her, wie wir es vorher eigentlich bei Shared Preferences haben. Also nutzt auch die Message Channels, um dann mit dem nativen Teil als Flutter Plugins zu kommunizieren und ruft dann sozusagen in dem Background Thread, in dem nativen Teil eben dann SQLite einfach auf. Und SQLite muss man natürlich sagen, ist erstmal eine sehr etablierte Technologie. Also da hatte ich auch nur Aussagen jetzt zuletzt gelesen, dass sie sagen, sie werden dediziert Support bis zum Jahre 2050 dann machen und geben. Und das ist natürlich einfach eine Hausnummer, die glaube ich, keine andere Datenbank so von sich vorgibt und sich so festlegt. Und es ist ja. Glaube ich auch eine der wenigen Datenbanken, die zertifiziert ist für den Einsatz in der Raumfahrt oder in der Luftfahrt, was so ein bisschen die Qualität zeigt von dem Code. Die Tests in dem Repository sind irgendwie zehnmal so viele Zeilen auf Code wie der Code an sich. Es ist wirklich eine sehr robuste. Technologie, würde ich sagen. Ja, und ist ja auch, sagen wir mal, auch im gesamten Mobile Umfeld oftmals ja wirklich die Technologie hinter anderen Datenbanktechnologien. Also, dass andere Datenbanken ja wirklich SQLite ja auch als Storage Backend dann nutzen. Ja, IndexDB zum Beispiel wird von den Browsern hauptsächlich oder so gut wie nur über SQLite. Letztendlich abgebildet. Zu handhaben. Also im Hintergrund ist das eigentlich SQLite, was als Schema... Zumindest bei Chrome bin ich mir ziemlich sicher. Ja. Ich meine auch bei anderen Browsern. Ja. Ich hatte jetzt gerade auch bei AWS Datastore gesehen, dass sie auch sagen, sie haben normalerweise selber so ein Async Database Format das Sollte man aber persönlich tunlichst nicht nutzen, wenn man auf Performance achtet. Dann gibt es hier noch entsprechenden SQLite Adapter. Also auch da scheint SQLite von der Performance etwas sein, was jetzt nicht unbedingt schlecht ist. Weil das war immer so, dass, was ich eigentlich aus der nativen Entwicklung vorher mitgenommen habe, SQLite ist immer etwas, was irgendwie langsam ist, wo man gucken muss, dass man irgendwie andere Technologien nutzt, wie RAM zum Beispiel war uns immer so ein Thema, ob wir da irgendwann mal zu beschwenken sollten. Aber so nach den Zahlen, die wir uns am Ende auch schon ein bisschen anschauen werden, ist es ja gar nicht so gegeben. Also SQLite ist an sich an Technologie erstmal auch sehr schnell und kann sehr schnell sein. Also Couchbase zum Beispiel, Couchbase Lite nutzt SQLite unter der Haube als Storage Engine. Und Couchbase Lite kann in den meisten Benchmarks, die wir so gemacht haben, mithalten mit anderen Lösungen wie Realm oder sowas. Das heißt, es lässt sich SQLite auf jeden Fall nutzen auf eine sehr effiziente und performante Art und Weise. Es hängt wahrscheinlich davon ab, von dem konkreten Anwendungsfall und wie SQLite genutzt wird. Aber es ist grundsätzlich keine langsame Technologie, würde ich sagen. Ja, auch so in den Zahlen, die ich dann gesehen habe oder in deinen Benchmarks gesehen habe, bin ich auch inzwischen sehr überzeugt davon, dass es keine langsame Technologie an sich ist. Das ist, glaube ich, auch so ein bisschen die Frage, was man obendrauf dann aufbaut. An sich, klar, SQLite ist natürlich ähnlich wie SQL einfach schemabehaftet. Das heißt, ich muss letztendlich meine Datenbankschemas irgendwie anlegen, die natürlich auch entsprechend migrieren. Das ist eigentlich so ganz schön gekapselt und sehr ähnlich zu der SQLite Ebene, die man auch der nativen Seite hatte, wie man dort Migration zum Beispiel ausführt. Was ich nicht habe, ist jetzt irgendwie Support für ein Mapping von komplexeren Objekten. Also da ist es eigentlich so, also ich habe natürlich mein Schema, was dort erstmal rauskommt, ist irgendeine Map, also einfach auch ein Key Value Objekt und ich muss mir dann selber eigentlich meine Mapper schreiben, um meine Datenmodelle in diese Map Struktur irgendwie zu überführen. Was ich aber dafür habe, ich habe natürlich Indizes, also kann grundsätzlich alles eben in Indice belegen und ich habe auch Queries, also dass ich wirklich auch alles, dass mir SQLite bietet, ist es glaube ich ein bisschen beschränkter im Funktionsumfang im Vergleich zu SQL, welche Operationen man hat, aber das ist ja auch so, dass jede Datenbank Technologie da ein bisschen eigene, aber an sich erstmal schon sehr performant, also nicht performant, sondern sehr, ist erstmal sehr sehr viel möglich eigentlich mit SQLite. Man kann sich alle möglichen Queries da konstruieren. Ich habe auch die Möglichkeit eben Transaktionen zu machen und mit einer Extension auch die Möglichkeit von Volltextsuche oder ist das irgendwie ein weiteres Plugin, was ich dann für SQLite brauche? Das ist sowieso interessant an SQLite, dass es sehr flexibel ist. Es lässt sich alles Mögliche ausbauen. Man kann Funktionen hinzufügen, die dann in Queries aufgerufen werden können. Und es gibt eben einige Module, die zum Beispiel für JSON gibt es ein Modul und eben auch für Volltextsuche gibt es sogar zwei Module, die es ermöglichen wirklich eine echte Volltextsuche, also mit Stemming, mit Unterstützung von verschiedenen Sprachen und allen möglichen Queries bauen. Schlechte Performance ist letztendlich beim SQL Flight Package kommt nur daher, dass sie halt auch wieder nicht, sagen wir, Dart FFI nutzen, sondern eben über die Message Channel Kommunikation gehen. Das haben wir so auch die Erfahrung gemacht. Also gerade unsere ganzen alten Apps vor dem Flutter Projekt liefen auf SQLite und dann haben wir sozusagen initial dann erstmal auch SQLite, die alten SQLite Daten importieren müssen. Und da hat man schon gesehen, also da konnte man sehr viel letztendlich optimieren. Aber trotzdem ist letztendlich dieser Migrationsschritt der alten SQLite Daten etwas, was eine Zeit lang dauern kann, einfach das auszulesen und zu überführen. Ich habe hier natürlich erstmal an sich überhaupt keine Unterstützung für Synchronisation. Also ich kann mir auf Basis von Escrowflight was eigenes bauen, aber die Datenbank bringt das nicht mit. Und ich habe momentan auch noch wenig Support für Web und Desktop, oder? Da ist es noch nicht so, dass zumindest dieses Package noch nicht so gut unterstützt wird. Also gibt es, glaube ich, experimentelle Ansätze. Dieses unterstützen möchten. Aber ich auch glaube, es wird auch da letztendlich eine Bibliothek genutzt, die vielleicht bei der nächsten Technologie, bei der nächsten Datenbank, die wir vorstellen, auch im Hintergrund arbeitet und deswegen auch interessant ist. Genau, deswegen lassen wir uns gleich mal zur nächsten Datenbank übergehen. Und die nennt sich Drift und viele kennen vielleicht Drift auch unter dem Begriff "Mur". Also darunter war es mir zumindest bekannt. Und ich hatte dann auch so einen gewissen Zeit dann den Blick auf die Datenbank, Veränderungen der Datenbankwelt verloren und war dann so ein bisschen erstaunt, als ich dann zurückkam. Auf einmal gab es die neue Datenbank Drift und habe mich dann so die Konzepte angeschaut und erst nach einer Zeit lang gemerkt, hey, das kenne ich alles schon mal. Ah ja, ich hätte diesen zweiten Satz lesen sollen, dass es ehemals das Moor Projekt war. Moor kommt von Room. Und Ruum ist vielleicht auch ein Begriff aus der Android Welt, weil dort dieses Framework existiert, was auf SQLite aufbaut, um es leichter zu machen, mit SQLite zu arbeiten in Android und eben einem viel über Code Generation auch ermöglicht in Bezug auf Data Mapping und Queries und sowas. Aber davon ist es halt stark inspiriert. Also ja, also das ist natürlich etwas, was euch wahrscheinlich als Android Entwickler auf jeden Fall noch ein größerer Begriff sein wird, eben Room und auch etwas, das natürlich wirklich schöner ist, wenn man dort auf dieser Ebene wirklich mit so einem ODM eigentlich, also Object Document Mapper oder ORM eben arbeiten kann, der ein bisschen die Arbeit, diese Überführung gerade der Daten auf der Datenbank in die entsprechenden Data Transfer Objects oder sein Modell einfach zu übernehmen. Und du sagtest eben bereits, es ist sehr stark davon inspiriert, das heißt man findet auch sehr viele Konzepte, die so in Room implementiert sind, in Drift jetzt wieder und nutzt, glaube ich, auch für die Kommunikation eben nicht Message Channels. Das ist, glaube ich, ein großer Vorteil, den eben da Drift hat, dass es da deutlich schneller ist eben darin, wenn es darum geht, eben dann die SQLite Daten in die Datebene zu holen und dort zu verarbeiten. Ja, als Teil von dem Drift Projekt hat der Autor, ich weiß gerade nicht wie er heißt. Er heißt Simon Binder. Ja, genau. Praktisch FFI Bindings erstellt, also den nötigen Code, der notwendig ist, um eben auf die nativen SQLite Bibliotheken zuzugreifen. Kann man auch nutzen direkt, wenn man möchte, aber es macht wahrscheinlich eher Sinn, für die meisten durch Drift zu nutzen und das ist nutzt, da hat FFI, wodurch es eben um einiges schneller ist, nochmal als. Sgf Live. Also da hatten wir auch mal so einen einfachen Prototypen gebaut, um das bisschen zu überlegen und waren auch wirklich erstaunt, was wirklich der Unterschied war. Für mich war halt der Zugang erstmal zu Drift bisschen schwieriger, weil ich so gerade so diese ganze API gefühlt gibt es sehr viele Klassen. Es gibt diese Companion Objekte, die halt eigentlich dafür da sind, dann wirklich Daten zu verändern. Ich glaube, der große Vorteil von den Companions ist, man kann wirklich einzelne Felder der Daten das Modell eigentlich auch dann nur anpassen und eben überschreiben in dem Moment, was natürlich als Datenbank Operation immer performanter oftmals ist, als wirklich den gesamten Datensatz zu aktualisieren zu müssen. Und das ist natürlich das, was viele andere Systeme so machen, dass sie halt wirklich sagen, okay, ich habe lokal im Dart Code ein Objekt verändert, vielleicht auch nur ein Feld verändert, aber ich speichere eigentlich immer, sagen wir mal, diese gesamte Repräsentation des Objektes dann wieder in die Datenbank zurück. Das ist natürlich ein gewisser Vorteil, schafft aber auch natürlich dann eine gewisse Komplexität. Ja, Komplexität eben auch, dass die ARP einfach größer ist und so, dass man gefühlt eben sich ein bisschen tiefer eben in dieses Thema einarbeiten muss und der Zugang minimal eben wie aufwendiger ist, um halt irgendwie zu verstehen, wie arbeite ich mit meinen Daten, wie arbeite ich mit Drift, um halt an die SQL Daten dann ranzukommen oder auch die Sachen zu schreiben. Was ganz interessant ist, es gibt natürlich dann, ja, der Code kann komplett generiert werden. Also ich arbeite entweder, glaube ich, mit Annotationen oder mit einfach mit Schema Definitionen. Ich habe sozusagen so eine Schema Definition, eine Tabellendefinition und daraus wird mir letztendlich zum einen natürlich wirklich die Datenbank auf der SQLite Seite erzeugt, aber zum anderen auch eben das Datenmodell eben in Dart. Genau. Und du kannst auch Queries da drin schreiben, die dann verfügbar sind als generierte Methoden auf der Datenbank, Klasse D generiert wird, was einfach vielleicht so SQL Queries schöner zu schreiben macht. Das ist nämlich diese zweite Möglichkeit. Es gibt auch diese Drift Dateien, da hast du die Möglichkeit, diese SQL Queries einfach zu schreiben und er generiert der Code daraus. Also genau diese beiden Optionen gibt es eben entweder wirklich als Tabellen Schema Definition in Dart oder eben als Drift Datei Definition, wo man dann auch erweitert die Möglichkeit hat, eben solche Queries mitzuerlegen, die man dann nicht von Hand eben erzeugen muss im erzeugten Code, sondern was dann einfach dann Drift für einen erledigt. Was ich super fand eben in dem Einstieg war wirklich die gute Dokumentation. Es hat eine gewisse höhere Lernkurve als das andere Key Value Stores, aber es ist an sich wirklich sehr ausführlich und gut dokumentiert. Also wenn man das für einen interessanten Ansatz findet, dann findet man da die entsprechenden Referenzen und Hilfestellungen, was auch ein großer Vorteil natürlich ist, dass man wirklich ein Schema hat, aber diese Code Generierung eben durch für das Mapping bekommt, eben über die Drift Dateien oder über die, ja, Dart Basis Tabellendefinition. Ich habe natürlich dann auch die gesamten Möglichkeiten, die ich von SQLite nutzen kann. Also ich habe Indizes wahrscheinlich oder Queries, Transaktionen, komplett Asset konform. Das ist natürlich sehr cool. Und was ich auch ganz cool finde, es gibt auch die Unterstützung für, wir nennen es entweder Streams oder Realtime Updates. Was ist darunter zu verstehen eigentlich, was das anbietet? Ich glaube, so wie ich das verstanden habe, weiß Drift ja immer, wenn du eine Änderung an der Datenbank durchführst. Du kannst von dem her ein Query die du gerade beobachten möchtest, immer neu ausführen, wenn irgendwelche Änderungen durchgeführt werden, wodurch du dann so eine Art reaktive Queries bekommst, die sich immer ändern mit den Änderungen in der Datenbank und aktuell gehalten werden. Was dir dann ermöglicht, so ein Single Source of Truth über die Datenbank abzubilden, was auch ein Thema ist, was in vielen anderen Datenbanken mittlerweile verfügbar ist, was wir auch noch sehen werden. Das ist auf jeden Fall super spannend natürlich, das zu sagen, hey, das kann ich eigentlich so weit runter verlagen, dass eigentlich meine Datenbankebene dafür zuständig ist. Wir haben es in unserer Architektur noch so, dass wir eigentlich noch mal so eine Ebene oben drüber haben, die natürlich vielleicht auch eine gewisse Reaktivität dann irgendwie in die oberen Ebenen gibt. Aber an sich, dass man halt der Datenbank letztendlich überlässt, jeden, der sich für bestimmte Änderungen interessiert, diese Information weiterzureichen, weil wie du es eben beschrieben hast, das ist genau richtig. Er ist letztendlich die Schnittstelle und alle Veränderungen letztendlich an den Daten müssen eigentlich über diese Schnittstelle erfolgen. Deswegen kann natürlich auch diese Ebene ganz gut eben diese Funktionalität erfüllen, dass halt Veränderungen in bestimmten Bereichen dann auch entsprechend Reaktionen auf einer anderen Ebene auslösen können. Deswegen super spannend, dass es das gibt, diese Streams. An sich hatten wir schon über die Performance gesprochen. Dadurch, dass es über die Data FFI Schicht gibt, hat man da wirklich eine deutlich bessere Performance als bei SQL Flight. Aber auch hier haben wir natürlich jetzt erst mal Synchronisation von der Datenbankseite aus. Also müssten wir uns auch wieder irgendwas on top dieser von dieser Lösung dann bauen. Und ich glaube auch der Support für Web und Desktop ist auch nur experimentell oder das ist noch nichts, dass eben was Etabliertes gibt. Einfach vielleicht. Liegt vor allem daran, dass SQLite, der Web Support dafür, noch am wachsen ist oder noch in einer frühen. Phase ist. Ja, deswegen spannend für euch, wenn ihr wirklich SQLite irgendwie als Datenbank Technologie unter der Haube oder ganz unten nutzen möchtet, aber trotzdem sozusagen nicht auf diese Ebene gehen möchtet, wo ihr die Queries selber schreibt, wo ihr auch die Daten selber mappt, dann kann euch Drift sehr viel dieser Funktionalität abnehmen. Auch wenn ihr natürlich sagt, ihr habt eine bestehende App und wollt die zu Flutter migrieren, um dann auf die Daten zuzugreifen, ist es wahrscheinlich auch sinnvoll, den ganzen initialen Migrationsprozess daraus zu machen oder natürlich auch zu sagen, ich arbeite weiterhin auf dem bestehenden Datenmodell, was ich habe. Das kann natürlich auch mal ein guter Ansatz sein, weil viele andere Technologien, die wir uns jetzt angucken, leben halt alleine im Flutter oder Dart Umfeld. Das sind sozusagen neue Datenbankformate. Und das Erste, was wir uns da angucken, ist HiveDB. Und HiveDB ist, glaube ich, auch etwas, was, wenn man sich die offizielle Dokumentationsseite von Flutter anguckt, welche Storagelösungen sollte ich irgendwie verwenden? Gibt es ja, glaube ich, zwei Technologien, die aufgeführt werden. Das eine ist Drift, was wir eben uns angeschaut haben, und das zweite ist eben HiveDB. Und ist ja eigentlich so als, ich weiß nicht, wie es Simon Leier ist der Entwickler davon, so als Testprojekt eigentlich entstanden, hat dann einfach enormen Anklang gefunden, weil es einfach so einfach war, es von der API zu benutzen. Weißt du da mehr? Und auch sehr performant. Ja, genau. Das ist auch so die Erfahrung, die wir gemacht haben. Es war einfach eine der Technologien, die damals schon sehr präsent auf PubDev waren. Es hat inzwischen glaube ich, 4.157 Likes. Das ist die Zahl von vor zwei Wochen, aber ist auf jeden Fall die zweitbeliebteste. Das Package eigentlich auf PubDev zu Storage Lösungen und ist von der Funktionität erst mal auch ein reiner Key Value Store und eben dort auch wirklich speziell nur für Datenflatter. Und ich glaube, das Besondere ist eben, dass Simon da eben auch für diesen Ansatz keine etablierte Datenbanktechnologie drunter verwendet hat, sondern einfach gesagt, er schreibt sein eigenes Format, definiert sein eigenes Format, wie die Daten eigentlich geschrieben werden. Und Hive nutzt dann eigentlich aus der Dart Ebene einfach die File API, um Daten eben auf dem Dateisystem des entsprechenden Gerätes dann zu schreiben und zu lesen. Ja, das ist auch interessant, dass das komplett in Dart implementiert ist, keinen nativen Teil hat und dadurch halt auch erstmal ohne Probleme überall funktioniert. Man braucht keine extra Binarys für jede Plattform, sondern überall, wo Dart Dateien schreiben kann, funktioniert es. Im Store Bereich. Also ich kann sozusagen mehrere Boxen mit verschiedenen Namen anlegen. Das sind eigentlich dann natürlich immer Dateien, eben wie auf dem Dateisystem einzelne Dateien. Aber dann gibt es eben dann einfach ein proprietäres Datenformat, wie die Daten in diesen Boxes dann abgelegt werden. Der große Vorteil, den man da sieht, dass einfach halt da für alle Plattformen eigentlich der Support gegeben ist. Ich glaube, auf Web nutzt er dann einfach so einen IndexDB Engine oder so ein Backend, wie er das nennt. Ich glaube auch. Das ist ein Faktor, den ich so ein bisschen gesehen habe, auch initial. Also wir haben HiveDB auch lange Zeit eben als Produktionssystem, als Produktionsdatenbank in Vorbilder verwendet, dass dort halt der komplette Generierung von Datamappern als Konzept hinterlegt ist. Also ich habe dann die Möglichkeit, über Annotationen meine entsprechenden Datenklassen zu annotieren und dann wird daraus letztendlich so ein Datamapper einfach erzeugt, den ich nur noch bei Hive einmal global registrieren muss und dann kann sozusagen jeder Datentyp, der unter einer bestimmten ID gefunden wird, dass es das wie Hive Also es gibt sozusagen vor jedem Datenbereich auf der Datenbank so ein kleines, ich glaube das ist ein Shortfeld oder ein Bytefeld. Das ist ein Bytefeld. Das kann ich ja. Ja, ich glaube das ist nämlich begrenzt. Du kannst maximal dann. 265. Ja, 56. Datenbereich, Daten ablegen. Oder Felder pro? Nee, das ist auch von den Datentypen so beschränkt, dass er gesagt hat, er möchte es möglichst kompakt halten, deswegen ist sozusagen dieses Flag für den Datentyp auch dort beschränkt. Aber kann auch sein, dass es ein Short ist. Also ich hatte es nur so in Erinnerung. Für die Felder ist es auf jeden Fall so, dass es einfach nur ein einzelnes Byte ist. Genau, aber das wird alles letztendlich generiert, wie diese Daten abgelegt werden, was man so ein bisschen nur denken muss. Wobei es. Gibt, glaube ich keine Verpflichtung, es ist schemalos, es lassen sich auch beliebige JSON ähnliche Daten speichern. Aber es ist effizienter, wenn man so einen Datamapper hat. Ja, genau. Man könnte natürlich auch dann eben die JSON Daten reinschreiben, dann muss man aber den Mapper wahrscheinlich selber schreiben, oder? Also es kommt dann kein JSON Objekt daraus oder eine Map dort raus oder wird auch das schon unterstützt? Doch, ich meine schon, soweit ich das weiß, bekommen einfach dann so simple JSON Objekte, äh, simple Data Objekte raus, die JSON repräsentieren. Ja, was man. Sehr einfach letztendlich damit auch implementieren kann, sind einfach wirklich so Collection Konstrukte, dadurch, was Sie gesagt haben. Man kann einfach die Daten, also für jede Box wird dann eigentlich eine eigene Datei aufgemacht, dass man dann sagt, zum Beispiel alles, was meine User betreffen, liegt dann einfach in einer Box und ich habe sozusagen für jede Box eine eigene Datei aufgemacht. Jeden Key dann einfach die User ID hinterlegt und kann so natürlich dann auch mir sehr einfach Strukturen schaffen, wo halt Daten abgelegt werden. Es gibt neben den Boxen, wo alles in eine große Datei geschrieben wird, auch die Lazy Boxen, die es ermöglichen, weil was ich bei einem Key Value Studer immer habe, ist ja eigentlich so der Index, wo ich die Referenz zwischen dem Key und dem eigentlichen Datenbereich für den Wert eigentlich hinterlegt habe. Und ich habe natürlich dann noch wirklich den einzelnen Eintrag. Und da ist es bei den Lazy Boxen so, da habe ich einfach eine Trennung. Der Index wird sozusagen in einer separaten Datei einfach vorgehalten. Und jeder einzelne Datensatz ist eine einzelne Datei, was einfach natürlich dann ermöglicht, wenn ich wirklich größere Daten habe, das nicht jedes Mal in einer Datei zu schreiben und auch diese gesamte Datei wieder auslesen zu müssen, sondern dass ich sagen kann, okay, ich muss jedes Mal eigentlich natürlich, wenn ich Daten hinzufüge, den Index aktualisieren. Aber das ist wirklich nur ein kleiner Eintrag, den ich hinzufüge. Aber der größere Datenblock entsteht dann als separater Datei auf dem Dateisystem. Da hat man einfach mit diesen beiden Konzepten eine sehr große Flexibilität, wie man seine Daten organisiert und je nach Komplexität der Daten natürlich auch die Unterteilung eben dort in zusammenhängender Datenbereich in einer Datei oder eben getrennte Index und Datendateien auf dem Dateisystem eben anzunehmen. Ja, das war glaube ich schon auch ein sehr kurzer Einstieg von dem, was uns Hive bietet. Es bietet einfach eine super Dokumentation natürlich so, wenn man sich damit beschäftigt und auch von den Konzepten ist es natürlich super simpel gehalten. Deswegen ist gerade, wenn man halt die Notwendigkeit hat, eher solche Sachen wie Einstellungen hast du vorher gesagt, hey, dafür sind die Shared Preference gedacht. Aber natürlich ist HiveDB auch für diesen Anwendungsfall super geeignet und bietet einem die Möglichkeit, sehr flexibel natürlich auch komplexere Datenstrukturen abzubilden. Was es eben nicht bietet, sind in irgendeiner Form eben Queries. Das heißt, es ist ein reiner Key Value Store. Ich habe keine Relation oder ganz einfache Relation, gar keine Relation, die dort unterstützt werden. Ja, wenn man das eben braucht, ist vielleicht Hive eben nicht die richtige Datenbank. Aber ich glaube, es ist für sehr viele Anwendungsfälle eben auch so, dass es halt das Modell von einem abbilden kann. Und es bietet auch eine sehr, sehr gute Performance. Oder das ist das, was du auch rausgefunden hast. Also Hive ist da schon in vielen Anwendungsfällen wirklich sehr schnell. Ja, genau. Einfach dadurch, dass es halt direkt eben auf dieser Pfeilebene arbeitet und alles in Dart geschrieben ist, führt einfach dazu, dass wir auch gemerkt haben. Also es war wirklich ein Faktor von 10 oder 20, was wir im Vergleich dann zu diesem SQL Flight Ansatz eben gesehen haben. Deswegen war ein einfach da HFDB für uns damals auch die erste Wahl. Wir haben aber an sich auch erstmal hier keinen Support für Synchronisation. Aber was wir haben, was du vorhin schon erwähnt hast, wir haben Support für alle Plattformen. Also kann man wirklich sehr breit einsetzen, ohne dass man auch viel adaptieren muss, sondern es ist einfach nur dieses immer der gleiche Mechanismus, der auf allen Plattformen einfach zu tragen kommt. Dann ist es glaube ich, spannender, jetzt uns die nächste Technologie anzugucken. Und das ist ICER. Und ICER ist von dem gleichen Entwickler, nämlich auch von 7.0. Ist noch eine recht neue Technologie, aber super spannend und ich glaube, da wird auch noch viel in Zukunft passieren und könnte sich vielleicht auch zu der beliebtesten Storage Lösung in Zukunft entwickeln. Ich glaube, die Besonderheit, du hast dir die Technologie irgendwie deutlich genauer angeguckt, ist die unglaubliche Performance, die irgendwie bei Schreiben erzeugt werden kann. So generell bei allen Operationen, die ich mir angeschaut habe, ist ISA unglaublich schnell. Ich glaube, unter der Haube benutzt ISA MDBX, was eben eine Datenbank ist, die einfach sehr schnell ist. Oder ich glaube, es ist ein Key Value Store in erster Linie, sehr gute Grundlage für schnelle Datenbanken, bietet auch viele Möglichkeiten für Querying an, ist insgesamt schemabasiert allerdings. Man muss ein Schema definieren oder deklarieren über Annotationen. Das funktioniert super, ist aber eben nicht so flexibel wie eine komplett schemalose Datenbank wie Hive oder. Share Preferences. Ja, was du eben schon gesagt hast, dass es auch diesen Query Support gibt, es gibt die Möglichkeit für Cogenerierung und was ich auch ganz cool finde, es gibt diesen Browser basierten Data Inspektor. Also ich kann mir jederzeit eigentlich angucken über die DevTools, welche Daten habe ich gerade auf meinem Gerät, welche sind dann live, in welchem Zustand. Das sieht schon an. Das ist eben. Auch der Vorteil von einem Schema, dass man dann in so einem Inspektor einfach sehr präzise die Daten darstellen kann und das Schema nutzen kann, um die Daten aufzubereiten und editierbar zu machen. Man hat das Gefühl, EISDA ist natürlich noch so ein bisschen neu. Also ich glaube, das ist erst vor ein paar Wochen eigentlich so gewesen, dass es nicht mehr diesen Warnhinweis gab, hey, das ist noch Beta Version und bitte noch nicht in Produktion nutzen. Also das heißt, jetzt ist es eigentlich offiziell freigeben. Anhand der Anzahl der Issues wäre ich noch so ein bisschen vorsichtig, ob ich es direkt in Produktion einsetze. Aber klar könnt ihr da, glaube ich, auch Simon gut unterstützen, wenn ihr daran mitarbeitet, das immer ausprobiert, daran weiterentwickelt. Ich finde, es hat eine super gute Dokumentation, also auch ähnlich wie bei Hive ist es, dass man super viele Informationen dort drin findet. Und ich glaube, auch inzwischen eine recht große Community hat, die das Ganze Projekt eben vorantreibt und unterstützt. Also er macht natürlich noch sehr viel federführend, aber ich glaube, da kommen immer mehr Leute dazu, die das eben mit unterstützen. Was es ja auch hat, es unterstützt auch komplett Transaktionen, also es ist irgendwie ACID konform. Ich habe auch hier die Möglichkeiten, Daten irgendwie mir pushen zu lassen über sogenannte Streams, also wirklich Queries zu schreiben, die dann aktualisiert werden. Ja, es ist reaktiv, genau. Und nicht nur Queries lassen sich beobachten, sondern einfach auch Änderungen an Dokumenten. An beliebigen Dokumenten. Ja, cool. Über die ID oder alle Änderungen lassen sich beobachten. Ja, die Performance haben wir angesprochen. Hier als Nachteil, okay, wir haben auch keine Synchronisation, aber trotzdem, wenn ihr vielleicht einen reinen Offline Support braucht für eure Datenbank, ist das glaube ich, etwas, was auf jeden Fall sehr spannend für euch ist. Da jetzt dann in Zukunft vielleicht mit den Entwicklungen mit zu begleiten, zu beobachten und dann zu sehen, ob es wirklich ein passender Anwendungsfall für euch ist. Ich glaube, ich auch Support für alle Plattformen. Also das ist so, dass dort sehr breit eigentlich geguckt wird, dass ja irgendwie alle Plattformen versucht zu unterstützen, was natürlich auch super ist, wenn man dort in die verschiedenen Plattformen gehen möchte. Ich glaube, ich glaube, Web ist im Moment im letzten oder wurde aus der 3.0 Version entfernt und kommt aber wieder. Ist aber glaube ich im Moment. Nicht verfügbar. Auf jeden Fall super spannendes Thema. Die nächste Technologie, die gucken wir uns glaube ich nur ganz oberflächlich an. Die nannte sich oder nennt sich Object Box und Object Box ist eigentlich auch so ein reiner Key Value Store, der von einem Unternehmen eigentlich entwickelt wurde. Und das ist so ein bisschen auch der Punkt, wo ich gleich am Ende nochmal draufgehe, ist recht beliebt. Also es gibt schon, ist schon so, dass die 796 Likes auf PubDev haben, dass es auch einige Stack Overflow Beiträge eben dazu gibt, wo Leute sagen, sie haben sehr gute Erfahrungen mit dieser Lösung gemacht. Und an sich war es für uns interessant, uns die Technologie eben näher anzugucken, weil sie auch die Synchronisation unterstützen, also auch diesen Offline First Ansatz explizit. Das ist aber eben nur so vom Modell, dass letztendlich, sagen wir, die Client basierte Storage Lösung komplett kostenfrei ist. Sobald man letztendlich aber diesen Server Sync, wie es bei Object Box sich nennt, eben haben möchte, muss man dann eben eine Lizenz erwerben. Und da war es so in der Kommunikation. Wir haben dort, ich glaube, wir haben eine Vertriebsmitarbeiterin, die haben wir angeschrieben. Es kamen über Wochen letztendlich keine Reaktionen. Die kamen dann irgendwie zwei oder drei Monate später, so dass wir gemerkt haben und da steckt kein großes Team hinter Objectbox. Also es ist, glaube ich, ein Entwickler, der das irgendwie so federführend betreibt. Auch von der Entwicklungsgeschwindigkeit hatte man so den Eindruck, es dauert lange, bis irgendwelche nützliche Funktionalitäten mal Einzug gehalten hat, vielleicht auch die in anderen Plattformen schon vorhanden war. Es gibt auch da für Java ein SDK, für IS ein SDK. Also dass man da so das Gefühl hatte, okay, das ist einfach nicht zu stemmen und deswegen vielleicht auch kein Produkt, keine Datenbank, wo man wirklich ein etabliertes Produkt drauf aufbauen möchte. Aber es gibt auch viele, die nicht zufrieden sind. Also es ist nicht so, dass es nicht unbedingt funktioniert, aber die Erfahrung bei euch war nicht unbedingt so perfekt. Ja, genau. Das ist das, was man wirklich durch die Bank eigentlich liest, dass viele sagen, hey, funktioniert irgendwie super gut, auch im Apps, wenn man nicht diesen Sync, Server Sync Support braucht, aber wenn eben diese Synchronisation ein Feature ist, eine, dann sollte man gucken, ist es vielleicht nicht die richtige Technologie, um darauf aufzubauen. Ich glaube, das, was man natürlich am häufigsten eigentlich nutzt, letztendlich, wenn man irgendwelche Daten eben zentral speichern möchte, ist mit Flutter natürlich Google Firestore und liegt vielleicht auch natürlich daran, dass Flutter ein Google Produkt oder Projekt ist, die natürlich sehr aktiv in der Entwicklung sind, dadurch natürlich auch sehr präsent und natürlich auch auf den entsprechenden Konferenzen, die immer an sehr großen Stellen werden, eine große Sicherheit einfach damit haben. Deswegen ist es, glaube ich, auch für Google natürlich einfach interessant, in Flutter zu investieren, weil sie halt sagen, okay, wir haben auch gleich die entsprechenden Bibliotheken, die entsprechende Cloud Infrastruktur dafür, um eure mobilen Apps mit Flutter oder jegliche Apps mit Flutter ebenso betreiben zu können. Und ja, es klingt erstmal natürlich sehr, sehr vielversprechend. Wir haben auch Firestore schon in etlichen Produkten eigentlich ausprobiert und ist an sich ja eine Prioritären Daten, NoSQL Datenbank. Du hast es vorhin gesagt. Also früher war es einfach so, dass es einfach JSON Daten abgebildet hat. Das ist jetzt immer noch so? Naja, es gibt halt deutlich mehr Funktionen mittlerweile. Auch so Queries. Nicht so ausgebaut wie bei SQL, aber man kann auch die Index definieren mittlerweile. Da hat sich auch einiges getan. Ja, es gibt auch diese Streams Unterstützung. Das heißt, ich kriege auch reaktiv Updates und diese Streams sind eben nicht nur bei lokalen Veränderungen, dass ich die mitbekomme, sondern wirklich, wenn sich auch Daten auf dem Server verändern. Also ist es so, dass wir da einfach eine Websocket Verbindung haben, wenn wir uns auf so eine Subscription aufmachen, auf eine Veränderung an einer Collection subscriben, können wir auch mal sagen, okay, soll das nur lokal sein, soll das auch gegen den Server gehen? Und dann würde ich auch mitbekommen, zu fast Echtzeit ist die Aussage, wie Echtzeit das jetzt ist. Wir haben das, für uns war es immer ausreichend Echtzeit genug. Es gibt ja noch die Realtime Datenbank dort als Google Produkt, die man natürlich auch nutzen könnte, die einfach bessere Echtzeitkriterien noch irgendwie anbietet. Aber es ist schon so, dass es für den Endnutzer oftmals gar nicht wirklich merklich ist und instantan eigentlich ist, wie diese Veränderungen kommen. Das heißt, wir haben da diesen Synchronisationssupport, das ist natürlich super schön. Ein gewisser Nachteil ist eigentlich natürlich, dass Firestore eigentlich nicht offline first ist, sondern das Schema Paradigma nennt sich online first. Also eigentlich erwarten sie, dass sie jederzeit eigentlich eine Verbindung zu dem Server haben, um sozusagen eine Änderung dann auch zentral abzulegen. Es gibt. Für so kurze Aussetzer von Netzwerkverbindungen auch die Möglichkeit, in Firestore weiterhin Operationen durchzulegen, die dann gequeued werden und später an den Server geschickt werden, wenn wieder eine Kommunikation möglich ist. Aber es gibt nicht so viel Kontrolle darüber, welche Daten lokal vorgehalten werden. Es gibt Cache, da kann man aber nur die Cachegröße definieren. Man kann jetzt nicht genau kontrollieren, welche Daten dort letztendlich drin sind. Und es ist halt eher eine darauf ausgelegte, in SDN offline online zu sein und so kürzere offline Zustände. Zu überbrücken. Die ganzen Änderungen, die in diesem Zustand entstehen, wenn ich offline bin, werden in diese Queue geschrieben. Das heißt aber, ich muss eigentlich immer den letzten synchronisierten Datenstand mit den genannten Änderungen dieser Queue verarbeiten, um auf meinen letztendlichen Datenstand zu kommen, den ich lokal habe. Das kann mit der Zeit einfach imperformant werden. Deswegen ist auch die Aussage, es funktioniert gut, wenn du kurze Netzwerkaussätze hast. Wenn du vielleicht auch mal einen Tag oder zwei offline bist, kommt natürlich auch darauf an, wie viel Daten du in der Zeit veränderst. Aber irgendwann ist es einfach so, es nicht mehr performant ist und deswegen auch für so einen reinen Offline Betrieb einfach nicht sinnvoll ist. Oder das sollte man einfach berücksichtigen, wenn man letztendlich Firebase sich anguckt. Was auch natürlich ein bisschen eingeschränkt möglich ist, wie man Queries gegen die Datenbank schreibt. Also es gibt inzwischen Support für bestimmte Abfragen, aber gerade von Operatoren ist das, glaube ich, sehr, sehr eingeschränkt. Ja, das ist auch so ein bisschen ein Kostenpunkt bei Firestore, die Queries, weil jede Abfrage halt dann irgendwie Kosten berechnet werden dafür, je nachdem wie viele Dokumente dadurch gelesen werden, dass die Abfrage gemacht wird und das mitunter relativ teuer werden kann bei größerer Installationsbasis von Nutzern und vielen Daten darin. Also die Erfahrung haben wir auch sehr schnell gemacht, also gerade bei vielen Mutationen, wenn halt Dokumente sehr oft verändert werden, kann es schnell wirklich Kostenrahmen einnehmen und vielleicht auch sprengen, die man sich vorher gar nicht so vorgestellt hatte. Also wir haben schon einige Firestore Lösungen, die wir gebaut haben, auf andere Technologien umgebaut, weil wir einfach gesagt haben, das ist nicht in einem Bereich, den wir dafür bereit sind auszugeben und haben teilweise danach eben ein Zehntel oder sogar noch weniger der Kosten gehabt. Also es war eher so schon ein Riesenunterschied. Aber es liegt natürlich auch ein bisschen daran, wie ihr mit den anderen Arten arbeitet. Wenn ihr wirklich nur einzelne Dokumente in einem Zustand ablegen wollt, denen ihr die selten vielleicht eine Veränderung bekommen, werdet ihr überhaupt keine Probleme damit haben. Ist natürlich auch ein großer Vorteil, dass es gerade für Startups halt immer, da Google sehr, sehr kulant ist und einem sehr viele Credits eigentlich bietet, auch der freie Plan von Firestore kann schon sehr viel eurer Grundlast eigentlich abnehmen, sodass wir vielleicht gar nicht für so eine Projektidee überhaupt in den Bereich kommt, wo überhaupt was zahlt. Aber darüber hinaus sollte man immer ein bisschen vorsichtig sein, wie langfristig das eine Lösung sein kann. Ja, und wie man das Datenmodell strukturiert, nicht zu viele kleine Dokumente baut, sondern eher ein bisschen größere Aggregate hat, damit es nicht explodiert irgendwann die Kosten. Was ihr natürlich auch habt, ihr müsst bedenken, es ist natürlich eine Google Technologie, also ihr habt dort ein Vendor Login, wo ihr euch eigentlich an Google bindet mit dieser Technologie, mit dem Einsatz dieser Datenbank, ist nicht so einfach, dann letztendlich auf ein anderes Modell umzuschwenken. Da braucht man auf jeden Fall eine Migration über verschiedene Datenbanklösungen hinweg. Also ja, das ist glaube ich das, was man bedenken sollte, aber für alles andere und das merkt man natürlich auch immer wieder in Gesprächen, dass es halt immer so die Frage ist, warum denn nicht Firestore? Firestore ist irgendwie so präsent und so eben die Ready to go Lösung, die die Flutter Entwickler in dem Bereich können und ja, für die meisten Anwendungsfälle vielleicht auch wirklich passend. Eine Datenbanktechnologie, die gerade glaube ich dabei ist, jetzt irgendwie ihre Produktionsreife zu erreichen, ist Realm. Und Realm ist euch vielleicht, wenn ihr in der mobilen und aktiven Entwicklung schon lange unterwegs seid, vielen wahrscheinlich ein Begriff. Realm war ja lange Zeit wirklich so eine reine Offline Datenbank, hat aber irgendwann, als sie von MongoDB akquiriert wurden, dann ja auch die Möglichkeit gefunden, dass man auch seinen Datenstandort sinken kann. Genau, ich glaube, das war so die Entwicklung von Realm. Ja, also das ist dann im Zuge davon passiert. Also gibt es eben das MongoDB Atlas System. Das ist einfach etwas wie so ein Synchronisationsendpunkt über MongoDB, den ihr irgendwo on premise oder in der Cloud irgendwie hostet. Und der stellt einfach die Kommunikation eben mit dem Client her und stellt halt sicher, dass die Daten ausgetauscht werden. Ja, momentan ist RAM eben noch in der Version 0.8.0 Release Candidate. Wir waren schon relativ lange daran, das zu entwickeln. Also es war eine Datenbanktechnologie, die wir, als wir so diese verschiedenen Ansätze und Möglichkeiten, die Packages evaluiert haben, die es damals schon gab in den ersten Versionen und wir immer nur gesehen, hey, da passiert aber relativ wenig in der Entwicklung. Das war so. Vor zwei Jahren, oder? Ja, vor zwei Jahren gab es schon die ersten, war das Package schon online, aber es gab wirklich nur so einen rudimentären Zugang. Es war sehr kompliziert, das einzurichten. Und dadurch, dass wir halt zu dem Zeitpunkt schon starten mussten an sich, Wir hatten auch schon Produkte in der Vergangenheit, die RAM als Datenbank genutzt haben, noch nie in der Verbindung mit MongoDB Atlas. Aber wir waren immer sehr zufrieden von der Ausfallsicherheit von RAM. Also dass es sehr interessant für uns gewesen wäre, wenn es damals zu einem anderen Entwicklungsstand eine Lösung für Flutter gegeben hätte. Aber gab es damals leider noch nicht. Und momentan sind sie, glaube ich, immer noch dabei, das alles so ein bisschen zusammenzuziehen, die finalen Release Candidates zu stricken. Aber an sich hat erstmal eine Unterstützung für sehr viel, was MongoDB natürlich auch bietet. Also ich kann Collections damit anlegen, ich kann Queries schreiben. Auch das mit deutlich mehr Operatoren, als ich das bei Firestore kann. Bisschen weniger vielleicht als bei NoSQL, aber sehr ähnlich zu dem, was wir wirklich von MongoDB gewöhnt seid. Ich habe auch dort eben die reaktiven Streams aus der Datenbankebene heraus. Zu dem. Query wollte ich noch kurz sagen, dass es halt textbasiert ist, also ähnlich wie SQL. Es ist so eine eigene kleine Suchsprache. Und bei MongoDB ist es ja eigentlich eher so eine Syntax, die nochmal ganz anders ist, um Suchabfragen zu schreiben. Die kommt glaube ich aus Realm, bevor Realm aufgekauft wurde von MongoDB. Deswegen gibt es da noch so ein bisschen Unterschiede zwischen MongoDB und Realm. Genau, wir haben die Synchronisation, wir haben den Support eben für Offline First, also da haben wir auch keine Einschränkung, wie lange wir das Gerät offline betreiben können, ohne dass wir den Server synchronisieren. Eben durchgeführt haben. Da arbeitet Realm eben komplett eigenständig. Erstmal auf dem Gerät. Von der Datenmodellierung fand ich es aber so, den ganzen Ansatz, den jetzt Realm auf der Dart Ebene bietet, so ein bisschen eingeschränkt. Also, wie man Sachen dort definiert, was daraus erzeugt wird. Ich meine, erstmal sind die Objekte sehr groß, was nicht ein Nachteil sein muss. Ich glaube, wenn wir nachher nochmal über Performance reden, sieht man, dass Realm da auf jeden Fall bei manchen Tests, auch bei gewissen Batch Sizes, einfach die Nase fort. An sich ist es natürlich ein großer Vorteil. Es ist irgendwie schemalos. Ich kann komplett verschachtelte Daten irgendwie daran strukturieren und ablegen. Es lassen sich auch Relationen abbilden, was nicht immer möglich ist. Ja, genau, stimmt. Es gibt diesen Support für Relationen. Auch Transaktionen sind genauso möglich. Streams und Queries hat man schon angesprochen und auch die sehr gute Performance. Und was wir natürlich haben, wir haben diesen Offline First Ansatz. Wenn wir einen Server Sync haben, ist es eigentlich dann wieder nur als Paid Service möglich. Also weit wie ich weiß, ist es so, dass es natürlich MongoDB Atlas eigentlich nicht als Lösung, Open Source Lösung gibt, die du dann einfach irgendwie ausrollen kannst, sondern dass du eigentlich immer gucken musst, okay, entweder installierst du es via On Premise und brauchst halt die entsprechenden Lizenzen. Es gibt natürlich viele Cloud Anbieter wie Google, die direkt auf dem Marketplace entsprechende Lösungen haben, wo die dann über Nets Cluster mit Atlas hochgefahren wird. Aber an der Stelle hast du eigentlich immer die Notwendigkeit, dann MongoDB als Lizenzmodell zu nutzen. Und das kann natürlich für euch so ein Punkt sein, wo ihr sagt, nee, also da wollen wir vielleicht einfach nicht die entsprechenden Lizenzkosten haben, dass es für euch keine Lösung sein kann. An sich ist es aber so, es soll auf jeden Fall, es gibt Support für iOS, Android und für Desktop. Ich glaube, für Web gibt es das nicht. Aktuell nicht, wird es wahrscheinlich auch lange Zeit nicht geben. Wüsste ich jetzt auch nichts dazu. Weiter leider. Ja, da kann man eigentlich davon ausgehen, dass das wahrscheinlich erstmal nicht unterstützt wird. Und wie gesagt, der große Nachteil, der momentan vielleicht noch steht, es ist noch nicht ganz final. Und die API ist vielleicht relativ stabil, aber es ist vielleicht nicht etwas, wo ihr jetzt schon eine Produktionsapp drauf planen oder umsetzen solltet. Planen vielleicht schon, aber aus der Vergangenheit weiß ich nicht, wie lange jetzt noch mal die letzten Versionsschritte noch brauchen, bis wir wirklich da einen final Release sehen, der dann auch stabil ist. Ja, jetzt haben wir uns da sehr viele Technologien angeguckt. Ich denke, was noch interessant ist, ist natürlich auch Couchbase im Vergleich zu sehen. So von dem, was Couchbase bietet. Ihr könnt natürlich auch noch detaillierter auch wirklich in unsere Folge 101, den Deep Dive 101 reinhören. Da sind wir sehr ausführlich natürlich auf die Backend Seite eingegangen. Ich glaube, im Vergleich dazu kann man natürlich erst mal erwähnen, du bist der Maintainer von CWL und bist daraus eben beim Schreiben deiner privaten App darauf gekommen, dass einfach Couchbase für dich die besten, das beste Feature Set geboten hat. Vielleicht ist das nochmal ganz gut, irgendwie zu rekapitulieren, was dich dazu bewogen hat zu sagen, hey, ich nehme keine der etablierten Lösungen, sondern ich baue darauf letztendlich etwas auf. Ich war am Experimentieren mit einem kleinen Projekt und wollte da so ein Offline First Ansatz umsetzen und wollte aber speziell eben Data Sync haben als Funktion und Volltextsuche. Und Data Sync Da gibt es eben einige Lösungen mittlerweile auch im Flutter Ökosystem wie Realm oder Objectbox. Volltextsuche gibt es nur gut implementiert in SQLite und keine Datenbank, die das so kombiniert wie Couchbase Lite. Couchbase Lite hat eben den Vorteil, dass es auf SQLite aufbaut und von dem her die Volltextsuche dort nutzen kann, die halt auch einfach schon ausgereift ist. Von dem her war es interessant, Couchbase Lite zu nutzen, aber es gab zu dem Zeitpunkt im Flutter Ökosystem noch kein Paket, was so ausgereift war, wie ich es gerne gehabt hätte, von der Funktionalität her und von der Umsetzung her. Aber Couchbase Lite war da gerade dabei, ein C SDK zu entwickeln und zu Ende zu entwickeln für die erste Version. Und gleichzeitig war auch Dart FFI soweit, dass es stable wurde und nutzbar wurde allgemein. Und diese Kombination aus Dart FFI und Couchbase Lite, dem Couchbase Lite C SDK sah sehr interessant aus, um ein SDK für Dart und Flutter für Couchbase Lite umzusetzen. Also das ist sozusagen der große Unterschied zwischen deinem CBL Package oder auch CBL Flutter Package, was da alles mit dran hängt und dem, was es vorher gab, dass vorher eigentlich die nativen SDKs dann über ein Plugin eigentlich, über ein Flutter Plugin angesprochen wurde. Genau, über Method Channels. Genau, und du jetzt direkt über die Dart FFI Schicht dann eben mit dieser C Library von Couchbase Lite kommunizierst. Genau. Genau, für uns war es nämlich auch damals so, dass wir gefühlt so auf dieser Suche waren und dann uns wirklich alle Bibliotheken angeguckt, auch sehr tief in den Source Code reinguckten. Als ich dann über deine CBL Bibliothek gestolpert bin, hab ich gedacht, boah, ist das gut implementiert. Da hat sich jemand wirklich Gedanken gemacht. Man hat auch die Möglichkeiten, die jetzt gerade aufkommen mit Dart FFI genutzt, um das zu bauen. Dass wir gesagt haben, allein aus der Qualität des Codes sehen wir das als unsere Lösung an. Und es hat natürlich auch wirklich dieses Feature Set, was wir eigentlich gesucht haben. Aber war halt echt super spannend. Natürlich hatten wir jetzt einen gewissen Weg damit, das mit zu begleiten. Da war auf Couchbase Seite, auf Couchbase Lite Seite von Couchbase, so ein paar Sachen noch zu erweitern oder Dinge, die vielleicht noch nicht so optimal funktioniert haben. Couchbase Lite C, das C SDK, ist halt auch noch nicht so lange im produktiven Betrieb. Hatte noch einige Bugs, die wir so entdeckt haben und mit denen wir ein bisschen gekämpft haben oder blicksweise ihr gekämpft habt. Ja, und du uns unterstützt hast dabei. Genau. Und da sind wir auf einem ganz guten Weg, die so mittlerweile alle behoben zu haben. Ja, und natürlich ist auch das coole, dass du natürlich jetzt sehr nah an dieser Technologie in Zukunft arbeiten kannst und deswegen auch da zukünftige Entwicklungen und Probleme, die irgendwie auftauchen, auch an einem sehr guten, großen Produkt natürlich mitbekommst und wir daran arbeiten können. Ja, das ist super spannend an 4pix, dass da so eine große Nutzerbasis existiert und man dementsprechend auch Fehler findet, die sonst nicht auftauchen so ohne weiteres bei kleinen Experimenten oder bei Tests. Von den Funktionen und zu der Bewertung muss man sagen, an sich ist ja auch irgendwie Couch, wär's erstmal schemalos. Also ich habe ja keine Schema, was ich definiere. Das heißt, ich habe so einen gewissen Migrationsaufwand vielleicht immer in den Modellen, habe aber die Möglichkeit dadurch natürlich komplex verschachtelte Daten irgendwie in meinen Modellen abzulegen. Von der Datenmodellierung gibt es ja zum einen letztendlich die Ebene, dass du sagst, okay, ich mache dieses Mapping irgendwie händisch. Also ich kann mir natürlich irgendwas schaffen, aber du glaube ich arbeitest auch an der Möglichkeit, das zu generieren oder gibt es auch schon komplett? Genau, also es ist grundsätzlich so, dass du Dokumente verwalten kannst in Couchbase Lite. Und diese Dokumente können halt ein Superset von JSON abspeichern. Also alle JSON Datentypen hat man und man kann auch Blobs abspeichern, was ich auch interessant finde an Couchbase Lite. Blobs sind einfach beliebige Binärdaten, die nicht in der Datenbank direkt abgelegt werden, also nicht in der SQLite Datenbank, sondern auf dem Dateisystem, aber innerhalb von einer Couchbase Light Datenbank immer mitgeführt werden, was einfach die performantere Lösung ist. Es ist aber sehr leicht macht eben auch größere Daten mit in CouchVS Lite zu speichern. Genau, aber es gibt eben die Möglichkeit, Dokumente zu nutzen, die schemalos sind, weil einfach viele andere Datenbanken diese Nutzung von Schemas anbieten und der Vorteil einfach existiert, damit mehr Typsicherheit zu haben, mehr Umgang mit den Daten, da auch einfach Sinn macht, sowas anzubieten, habe ich angefangen, die Möglichkeit anzubieten, Klassen zu annotieren, um so ein Datamapping zu erzeugen, was dann automatisch die Dokumente nutzt, um die Daten typsicher auszulesen oder auch wieder zurückzuspeichern. Ist aber noch ein bisschen früh in der Entwicklung. Ist aber was, was ich auf jeden Fall sinnvoll finde zu unterstützen. Und das ist halt der Vorteil von so einer schemalosen Datenbank, dass du eigentlich beides machen kannst, beides anbieten kannst. Und genau da bin ich auf dem Weg dahin. Ja, cool. Wir haben jetzt natürlich so eine eigene Abstraktionsschicht irgendwie im Projekt geschaffen, aber für alles andere ist das natürlich super spannend, irgendwie sowas dann zu haben und das unterstützt zu haben. Und ja, an sich Ich glaube, also wodurch letztendlich die Datenbank so interessant für uns war, war ja die Möglichkeit, auch unsere Daten zu synchronisieren. Also da nutzen wir letztendlich Couchbase in Kombination mit den sogenannten Sync Gateways oder das heißt neuerdings App Services, um dann auch unseren Datenstand lokal abzulegen und auch dann eben gegen die Remote Server zu synchen. Und ja, das ist auch etwas, was gefühlt natürlich auch recht gut funktioniert, also dass man da entweder sagen kann, ich möchte halt wirklich so einen expliziten Sync haben. Also ich habe einen Zeitpunkt, wo ich meine Daten synch dann anstatt einer Replikation, nennt sich das bei Couchbase, dann anstoße. Ich habe ja aber auch die Möglichkeit zu sagen, einen permanenten Sync zu machen und dann dort vielleicht wirklich auch fast Echtzeit Szenarien abzubilden. Genau. Also auf dem Sync Gateway nennt sich das. Das ist die Komponente, die zwischen den Couchbase Lite Datenbanken steht und dem Couchbase Server, der diese ganze Synchronisierung organisiert und koordiniert. Es kann Chainstreams anbieten an die Couchbase Lite Clients, um eben so eine Echtzeit Synchronisierung anzubieten, die im Millisekundenbereich oder schneller ist. Millisekundenbereich auf jeden Fall, um eigentlich so Echtzeitszenarien abzubilden und funktioniert relativ gut, was ich so bisher ausprobiert habe damit. Das ist auch ein Use Case, der für uns irgendwann recht spannend wird, das einfach mal auszuprobieren, weil wir bisher immer eigene Lösungen mit Websocket Servern gebaut haben, die genau das eben unterstützt haben. Aber da einfach jetzt von der Datenbank genau dieses Mechanismus zu haben, wird auf jeden Fall noch sehr spannend. Und an sich glaube ich, ich glaube, wir gehen gleich zu dem Performance Thema nochmal ein, kann man sagen, auch bei Couchbase sehen wir da wirklich eine sehr gute Performance eben in vielen Bereichen, bei vielen Operationen. Wir haben eben diesen kompletten Offline First Support. Hier ist es natürlich so, dass eben der Server Sync nicht ein Paid Service ist. Also es gibt immer ja sozusagen diese Open Source Version von Couchbase, die ist ja auch möglich, sozusagen Sync Gateway on Premise selber zu betreiben und auch Couchbase on Premise zu betreiben. Da ist ja nur der Funktionsumfang eigentlich ein bisschen eingeschränkt im Vergleich zu dem, was mir dann eine lizenzierte Version von Couchbase Es. Gibt die Community Edition und die Enterprise Edition bei Couchbase bei eigentlich allen Produkten. Und die Community Edition ist halt einfach vom Funktionsumfang reduziert. Aber so für viele Anwendungsfälle wird glaube ich die Community Edition auf jeden Fall ausreichen am Anfang oder vielleicht sogar längerfristig, wenn man nicht unbedingt angewiesen ist auf den Support, der halt mit der Lizenz einhergeht. Vielleicht noch ein anderes Thema in der Hinsicht ist insgesamt, dass mittlerweile auch ein Software oder Database as a Service Angebot existiert, was einem den ganzen Betrieb abnimmt von so einem Couchbase Cluster und dem Sync Gateway. Das nennt sich Couchbase Capella. Man über Online Portal dann einfach sich so am Cluster zusammen klicken kann. Ist auch möglich, dass man da 30 Tage lang kostenlos mal was ausprobiert, wenn man da dran. Interessiert ist. Aber es gibt keinen komplett kostenfreien Plan, der für ein gewisses Kontingent Also so man hat diese 30 Tage Trial, soweit ich weiß. Ja, genau. Aber da kann man auf jeden Fall damit mal rumspielen. Ist gerade etwas, wo wir unser System gerade hin migriert haben, weil wir dadurch natürlich wenige operative Aufwände haben, jetzt unsere Kubernetes Cluster zu maintainen. Und ja, auf jeden Fall ein guter Service, den man in dem Bereich dann nutzen kann. Vom Support für die Plattform haben wir momentan eben hier iOS und Android Support und Desktop unterstützt du auch schon. Was noch fehlt ist so ein bisschen der Web Support, aber wo wir einfach gucken müssen, dass dann letztendlich so diese File APIs auch im Web dann verfügbar sind, um SQLite direkt im Web benutzen zu können. Genau, da wird dran entwickelt. Wird dran entwickelt, wird immer bei den Browsern Einzug erhalten. Es ist ja so, dass alle großen Browser Herstellungen da sehr aktiv dran arbeiten und das ja auch jetzt offiziell etwas ist. Was SQLite eben jetzt vom Kernteam aus unterstützt. Also da wird sich auf jeden Fall etwas tun, sodass wir irgendwann hoffentlich auch Cloudflares Lite dann wirklich im Web nutzen können. Und. Ja, auf jeden Fall auch super spannend, die Technologie. Dann lasst uns nochmal abschließen, so ein bisschen uns die Performance anschauen und was wir da so rausgefunden haben, wie sich die Daten unterscheiden. Ja, also so ein Trend, der sich herausgestellt hat für mich, ist, dass es große Unterschiede gibt darin, wie schnell Transaktionen aufgemacht werden können zum Schreiben von Dateien oder von Daten. Aus irgendeinem Grund es geleiht ziemlich gut ist, diese Zeiten kurz zu halten, um so eine Transaktion aufzumachen und von dem her auch bei geringen Batch Sizes schon sehr gute Performance hat. Wenn man sich dann größere Batch Sizes anschaut, also zum Beispiel 100 oder 1000 Dokumente auf einmal in einer Transaktion schreibt, dann verändert sich das Bild stark und dort sind dann auch Datenbanken wie Object, Box, Realm deutlich schneller und effizienter. Ease hat eigentlich immer eine gute Performance, was interessant ist. Auch steigt mit der Effizienz von der Effizienz her bei größeren Batchsizes. Wobei das eben auch so ein bisschen wie bei anderen Benchmarks aufgefallen ist, dass oft nur so 50.000 große Batch Sizes angezeigt werden, was nicht wirklich realistisch ist für die alltägliche Nutzung von so einer Datenbank, weil man in der Regel nur ein oder zwei oder vielleicht zehn Dokumente schreibt. Deswegen habe ich in meinem Benchmark auch versucht, eben über verschiedene Batch Sizes ein bisschen die Performance zu vergleichen. Ja, das ist super spannend, weil wie du es richtig sagst, weißt du, das Szenario, was man eigentlich täglich hat, ist, dass du irgendwie eins bis zehn Dokumente eigentlich abspeichert. Also eigentlich ist es auch nur interessant, sich diese beiden Zahlen für die normale Nutzung eigentlich in der Datenbank anzuschauen. Genau. Was ein anderes interessantes Thema sind Async oder Synchrone APIs. Da gibt es einen ziemlich großen Unterschied, woran man eben sieht, dass da doch ein Overhead mit einhergeht. Generell würde ich sagen, dass es immer sicherer ist, Asynchrone APIs zu nutzen von dem UI Thread aus. Da wird man nicht in die Gefahr läuft, dass man den blockiert für eine längere Zeit und dann ein Stottern anfängt oder Stottern bekommt. Bewerkstelligen muss, wenn man da sicherstellen will, dass irgendwelche Lese oder Schreib Operationen irgendwie nicht die UI blockieren. Ich glaube, sie haben immer mal ein asynchrones Put eingeführt, aber bei den anderen, bei Realm ist es glaube ich auch so, oder? Hattest du nicht erwähnt, dass es... Ja, bei Realm ist es so, soweit ich das nachvollziehen kann, kann man lesen, sind alle Lese Operationen synchron. Das ist nicht so ein großes Problem, weil die halt extrem schnell sind. Und für eine bisher oder in den letzten, in den ersten Versionen gab es auch keine Möglichkeit, Daten asynchron zu schreiben. Mittlerweile gibt es aber die Möglichkeit auch für eine asynchrone, für asynchrone Transaktionen, die dieses Problem dann nicht haben. Also bei Realm gibt es, ist das Problem eigentlich gelöst mittlerweile. Ich habe gesehen, du sagst gerade in deinen Grafiken, dass bei Read Document, wie bei Realm, es gar nicht so gut ist. Also vielleicht haben sie doch ein größeres Problem, dass es nicht im Hintergrund passiert. Sie sind beim Schreiben sehr gut, beim Updaten von Dokumenten, aber bei Realm... Ja, das ist die Sache, ist die... Ja, das ist so ein anderer Punkt. Es gibt riesige Unterschiede zwischen zum Beispiel zwischen dem iPhone 12 oder dem Macbook oder Android und bei Realm ist es auch so, dass da, ich glaube, die Version, die aktuell die neuste ist, nicht die ist, die ich gebenchmarkt habe, jetzt speziell in dem, was in den Folien drin ist. Das heißt, da kann auch sicher noch mal einiges verbessert haben. Also die letzten Benchmarks, die ich jetzt mal, also vor letzter Woche gelaufen habe, laufen lassen, da war die Read Performance bei RAM eigentlich sehr gut. Es. Ist grundsätzlich so, es gibt einfach Riesenunterschiede von Betriebssystemen zu Betriebssystemen zwischen den verschiedenen Geräten, so dass eigentlich die Benchmarks, die man oft so sieht, nur mit sehr viel Vorsicht interpretiert werden können oder sollten. Und wenn wirklich Performance wichtig ist, eigentlich immer selber noch mal Benchmarks gemacht werden müssen, um zu validieren, dass die Performance, die anscheinend notwendig ist oder vielleicht notwendig ist, tatsächlich eingehalten wird. Aber ansonsten sind eigentlich alle Lösungen so für die einfachen CRUD Applications ausreichend. Also sind da wirklich, sagen wir mal, auch gerade in dem Bereich vergleichbar. Man sieht auf jeden Fall, was interessanter ist, dass man sich halt, wie du es in deinem Test auch in den Folien zu sehen hat, auf dem HTC Gerät gemacht hast, auf dem älteren Android Gerät einfach mal auszuführen, weil sich die Zahlen völlig unterscheiden von dem, was man auf modernen iOS Geräten sieht. Und dass man wirklich sicherstellen sollte, dass man das nochmal selber evaluiert, dass unsere Benchmarks da eigentlich nur einen Hinweis darauf geben können. Ich meine, wir können natürlich auch sagen, vielleicht schaffen wir das, das regelmäßigen Abständen zu veröffentlichen, eben mal bereitzustellen, wie da so die Sachen aussehen, dass man da einen gewissen Vergleich hat. Jede Plattform von sich behauptet natürlich, sie ist die schnellste Storagelösung. Das hieß da bei Hive, das hieß bei Objectbox. Vielleicht braucht man da nochmal einen dritten, der das vielleicht nochmal ein bisschen anders bewertet und da versucht irgendwie für mehr Plattformen, für mehr Datenbanken wirklich diese Benchmarks bereitzustellen und durchzuführen und regelmäßig zu aktualisieren. Ja und regelmäßig wäre. Interessant, wie du sagst. Ja, okay. Wir haben euch natürlich jetzt sehr viel Input geboten. Uns war es aber auch wichtig, dass wir euch dann möglichst breiten Überblick darüber geben, was es so an Storage Lösungen da draußen gibt. Also ihr habt da wirklich eine große Auswahl. Die euch da anschauen könnt. Ich glaube, für die Zukunft ist natürlich immer noch Hive einfach ein Thema, wenn es darum geht, einfache Daten oder Daten einfach zu speichern. Wir hatten lange Zeit das Problem, dass es dort Daten kaputt gegangen sind. Das haben sie zum Glück inzwischen gefixt, sodass es auch wirklich für einen Produktionsbetrieb, glaube ich, jetzt sehr, sehr gut zum Einsatz kommen kann. Isa wird natürlich, glaube ich, in Zukunft ein super spannendes Thema, wie da die Entwicklung weitergeht. Und natürlich auch diese alternativen großen Technologien, Firestore, Realm oder auch Couchbase, können natürlich sehr gute Einsatzfelder für euch sein oder zum Einsatz kommen können, wenn ihr die entsprechenden Anforderungen habt, dass ihr dort auch noch einen zusätzlichen Data Sync aus out of the box eben von der Datenbanktechnologie eben unterstützen müsst. Eine Datenbank, die wir noch gar nicht angesprochen haben, ist AWS Amplify. Das war uns noch nicht so ganz auf dem Schirm, aber das ist auf jeden Fall auch was, was man sich mal anschauen kann, wenn. Man auf der Suche ist. Sehr interessant. Genau. Ist natürlich im Backend so ein bisschen schwieriger, das irgendwie zu mappen. Du musst ja irgendwie sozusagen diese GraphQL Resolver gegen deine Datenbank schreiben. Vieles wird da automatisch aufgebaut, aber auf jeden Fall auch spannend. Ist da mal von den Synchronisationskonzepten irgendwie auch ein bisschen schwieriger. Könnte aber auch etwas sein, was für euch interessant ist. Also deswegen auch für euch. Wenn es eben diesen Swing Support geben muss oder eine Anforderung einfach bei euch ist, dann ist AWS Datastore etwas, was auf jeden Fall auch ein passender Kandidat für euch sein könnte. Gerade wenn ihr natürlich sowieso AWS für eure für eure Hosting benutzt. Okay, dann danke ich euch vielmals fürs Zuhören. Gebt uns bitte auch gerne Feedback, wie ihr die Folge fandet, ob ihr in Zukunft vielleicht auch mehr über Flutter, tiefe Flutter Themen hören möchtet. Dann können wir natürlich auch mehr solche Informationen für euch aufbereiten und zur Verfügung stellen. Allen Hörern dann vielen Dank. Tschüss. Macht's gut.Musik.