Florian
Hallo und herzlich willkommen zu einer neuen Folge des Sandpapiers. Das ist unser Podcast, der alle zwei Wochen stattfindet und in dem wir uns über Themen unterhalten, die uns als Firma so beschäftigen. Heute wollen wir über das Thema Exply Technologie Stack sprechen, nachdem wir ja in der letzten Folge schon darüber gesprochen haben, wie Exply entstanden ist und genau welche Sachen wir auf diesem Weg gelernt haben, soll es heute um die Technologien gehen. Heute sind bei mir einmal die Katharina.
Katharina
Hallo!
Florian
und der Chris.
Christoph
Ich freue mich hier zu sein. Hallo.
Florian
Beide sind aktuell auch maßgeblich an der Entwicklung von Exply beteiligt. Und deswegen denke ich, dass das heute eine sehr spannende Runde wird, weil die beiden halt auch sehr tiefe Einblicke in den aktuellen Technologie Stack haben. Und deswegen folgt jetzt eigentlich die Gretchen Frage, welche Technologien verwenden wir denn in Exply?
Christoph
Katharina, willst du darauf vielleicht antworten?
Katharina
Ja, kann ich machen. Also im Frontend haben wir eine React-Anwendung. Ursprünglich mit TypeScript, äh, JavaScript im Moment. Versuchen wir so ein bisschen auf TypeScript umzubauen. Also das ist nach gerade so in der Mache. Außerdem haben wir so was wie Sass drin. Äh, haben wir eine REST-API zum Backend. Dort verwenden wir Groovy und Java, Spring Boot, Ballistic Search. Ja, sowas alles. Ähm.
Florian
Gibt es da auch Technologien, die jetzt für dich irgendwie besonders sind oder mit denen du dich besonders auseinandersetzt?
Katharina
Dadurch, dass wir Elasticsearch zur Datenhaltung haben, anstatt irgendeiner normalen Datenbank, spielt das schon eine große Rolle. Also viel von der Entwicklung gerade im Backend hat mit Elasticsearch zu tun.
Florian
Kannst du vielleicht noch mal sagen, was das ist, Elastic Surge?
Katharina
Also der 6th Search ist gleich ursprünglich zur Volltextsuche, also da kann man so seine Daten indexieren, wie das bei Google auch passiert, und dann kann man da drinnen Volltextsuchen und sowas machen, die haben aber auch sehr viel mit Datenaggregationen und so, wo man dann Auswertungen machen kann, sehr umfangreiche Aggregationen nennt sich das und dann eine Query DSL dafür und das machen wir uns zunutze und machen eine Datenauswertung praktisch damit.
Florian
Das heißt Exply ist auch so ein bisschen die Primärdatenhaltung, wenn ich das jetzt richtig verstanden habe.
Katharina
Ja, also Exply versteht sicher alles.
Florian
Ach so, sorry, Elasticsearch, nicht X-Files.
Katharina
Ich glaube, du hast Elasticsearch gesagt, ja. Also, Elasticsearch versteht sich ja so als Datenhub so ein bisschen. Da kann man alle möglichen Daten reinschmeißen, von CSV, über irgendwelche generischen Datenbanken, also Postgres, MariaDB, was immer man möchte. Wir haben auch Importer für Chira-Systeme zum Beispiel oder für verschiedene Zeitbuchungsanwendungen. Und die Idee ist, dass man halt alle möglichen Daten da reinschmeißen kann. Die werden alle in Elasticsearch indexiert und man kann die Daten alle miteinander vergleichen.
Florian
Warum nutzen wir jetzt keine relationalen Datenbanken?
Katharina
Die Frage würde ich gerne an Chris weitergeben, weil er dabei war, als es entschieden wurde.
Christoph
Genau, das hat mehrere Gründe tatsächlich. Man muss natürlich ganz fairerweise sagen, würde das mit einer SQL-Datenbank auch gehen? Ja, natürlich würde das mit einer SQL-Datenbank auch gehen. Es ist nicht so, dass die nicht mögen oder damit nie arbeiten. Wir haben uns sehr, sehr früh für Elasticsearch entschieden, als das in dem Explore-Projekt losging sogar schon. Damals war auch die Ausrichtung von dem Tour selbst noch ein bisschen anders und die Volltextsuche hatte einen größeren Teil, was natürlich stark dazu beigetragen hat. Ich glaube, das war damals Elasticsearch 0.9, als wir angefangen haben. Es gab aber damals schon eine frühe Form von den heutigen Aggregationen, die hießen damals noch Facetten, womit man auch rechnen konnte mit den Daten, wo man numerische Werte auf irgendeine Art und Weise zusammenfassen konnte, zum Beispiel im einfachsten Fall durch die Summe. Da hatten wir uns damals entschieden, wir wollen ja in das System fremde Daten reinladen und deshalb brauchen wir eigentlich keine Datenbank, wo wir Daten jetzt lange speichern, sondern wir brauchen eher so eine Art Such-Cache, weil wir ja bei der Datenauswertung per Form an drauf zugreifen wollen. Da hat Elasticsearch uns ein gutes Tour an die Hand gegeben und wir haben viel ausgetauscht in dem Projekt an Technologie über die Zeit, aber Elasticsearch hat immer seine Aufgabe gut erfüllt, die wir dort hatten.
Florian
Das ist sozusagen Datenhaltung, wenn ich das jetzt richtig verstanden habe. Gibt es jetzt noch andere Technologien? Also ich könnte mir jetzt vorstellen, wir nutzen jetzt irgendeine Programmiersprache im Backend. Also es wird wahrscheinlich irgendein Backend geben oder sagen wir es mal so, ich weiß, dass es ein Backend gibt, aber ich stelle es einfach mal ein paar Fragen. Genau, könnt ihr da vielleicht noch ein bisschen drauf eingehen, was wir im Backend noch so für, also vielleicht für eine Programmiersprache, für Konzepte nutzen?
Katharina
Hauptsache Programmesprache im Backend ist Movie. Da würden wir uns heute, würden wir das jetzt mal neu schreiben, wahrscheinlich auch für was anderes entscheiden, wahrscheinlich eher in Richtung Kotlin oder so, aber damals war das jetzt mal Movie der Shit. Und soweit ich weiß, ich war damals nicht dabei, aber würde Movie damals auch genommen, weil man die Möglichkeit hatte da diese DSLs zu schreiben und zu definieren, aber da kann Chris bestimmt mehr dazu erzählen.
Christoph
Ja, das hat eine große Rolle gespielt am Anfang. Also, nach meinem heutigen Geschmack würde ich wahrscheinlich auch sagen, na ja, eine JVM-Sprache wäre schon ganz gut, auch wegen dem Deployment, aber Kotlin ist im Moment meine Sprache der Wahl, wenn ich von vorne anfange für dieses Projekt. Und wir hatten damals Groovy genommen, weil Java, also Java Plane, der nächste Mal wird relativ ausführlich. Ich glaube, jeder Java-Entwickler kennt es. Man schreibt ein paar Zeilen und dann wirft man noch den Code-Generator an und dann ist die Datei voll, also im übertragenen Sinne. Und was Groovy auch kann und auch damals schon konnte sind, Groovy bietet einen ganz interessanten Weg zu einer Spracherweiterung, dass man quasi Methoden schreibt, die man dann später als so eine Art Schlüsselworte benutzen kann. Und da kann man eigenen Code schreiben in so einer DSL, also einer Domainspecific Language, die auf einen ganz bestimmten Use-Case zugeschnitten ist. Die kann man mitkompilieren und man kann sie sogar zur Laufzeit noch aus Dateien nachladen. Und wir haben das benutzt, um Exply sehr flexibel zu halten. Wir haben am Anfang so eine Art Backbone geschrieben, wo man beliebige Daten reinladen kann und die auswerten. Das ist auch immer noch da und haben diese DSL benutzt, um das zu konfigurieren, was natürlich extrem anspruchsvoll ist. Also man darf sich das jetzt nicht vorstellen, wie eine Konfiguration für einen Endnutzer. Das war selbst für einen Entwickler anspruchsvoll, aber es hat uns die Möglichkeit gegeben, den X-By-Kern sehr abstrakt zu entwickeln und trotzdem viel damit zu experimentieren und schnell damit zu experimentieren.
Florian
Aber wenn ich es richtig verstanden habe, haben wir uns doch eigentlich von diesem DSL-Konzept, hatten wir uns davon nicht verabschiedet oder ist das nicht wieder, ich sag mal, rausgeeitert, auf gut Deutsch?
Christoph
Ja, ja, absolut. Also, das ist halt zu abstrakt. Also, ich würde mal ein bisschen den Vergleich zu Datenbanken... Ich versuche, eine Brücke zu schlagen zu Datenbanken, weil das vielen Leuten doch ein Begriff ist. In einer Datenbank kann man ja auch, sage ich mal, alle möglichen Daten speichern. Aber man muss natürlich die Datenbanken konfigurieren, man muss die Daten typisieren und Tabellen anlegen, die haben ein bestimmtes Schema. Und wenn man die Daten laden will, dann braucht man dieses SQL. Ja, das ist ja für manche schon fast eine Programmiersprache. Das ist auch sehr komplex, das ist sehr mächtig. Und das ist natürlich nichts für einen Endnutzer. Der kann damit überhaupt nichts anfangen. Das ist an... Also, je nachdem, was die Zielgruppe ist, ist das das falsche Abstraktionsniveau. Ich sage ja auch nicht, hier hast du einen Texteditor, da kannst du dir alles programmieren, was du willst. Die meisten Leute sind damit nicht zufrieden. Und dieser DSL für Endnutzer ist extrem anspruchsvoll gewesen.
Katharina
Also, habe ich das gerade richtig verstanden, dass damals der Nutzer von Exply sich per DSL seine eigenen Konfigurationen schreiben sollte?
Christoph
Also, es war halt nicht so, wir haben es den Nutzern versucht nicht zuzumuten, wir haben schon nochmal eine vereinfachte Konfiguration gemacht, die war aber auch sehr, sehr schwer, das war eher so eine Art JSON-Konfiguration und wenn du dann Komma vergessen hast, hast es halt eine Anwendung gekriegt, also das war wirklich, wirklich in der frühen Phase anspruchsvoll, weil wir...
Katharina
Wir haben es den Nutzen versucht.
Florian
Ich glaube, wir hatten noch einen Nutzer, einen einzigen Nutzer, der das wirklich zuverlässig benutzen konnte, der das richtig cool fand. Das war hier der Jürgen von Punkt.de.
Christoph
Ja, da war ich ja, also sag ich mal, man braucht aber schon technisch sehr, sehr versioniert und auch frustolerante Nutzer, sag ich mal, das, aber das war auch die Geschichte von, also die Entwicklung von dem Projekt, wir haben ja am Anfang viel mit der Funktionität im Experkern experimentiert, wir haben viel mit verschiedenen Visualisierungen experimentiert und die, sag ich mal, die Nutzerfreundlichkeit in der Konfiguration des Systems, was ja noch ganz stark im Wandel war, haben wir an dem Punkt hinten angestellt und wir haben es vor allem intern eingesetzt und bei Sandstorm waren damals alle Entwickler und jetzt sind es immer noch fast alle und da sind die Anforderungen halt andere.
Florian
Das heißt eigentlich brauchen wir dieses DSL, also diese DSL nicht wirklich, weil wir ja in der Lage sind, auch echten Code zu schreiben. Also wir müssen das nicht abstrahieren, wir müssen eine Programmiersprache nicht abstrahieren, damit das für uns sozusagen nutzbar wird. Wenn ich das jetzt mal übersetzen soll, oder?
Christoph
mal übersetzen soll, oder? Ja, also was ich nicht machen würde ist oder als Entwickler jetzt nicht mehr machen würde oder nicht in so großem Maße, wenn ich eine kleine DSL habe als Konfiguration und sollte die Teil von dem Projekt sein, wenn ich sie auch mit dem Projekt ausliefe und ich würde jetzt sagen, so eine DSL-Konfiguration sollte man behandeln wie Quellcode und man muss nicht unbedingt eine DSL schreiben, wenn man so eine Art von flexiblen Systemen dann konfigurieren will. Am Ende ist der Weg sehr kurz zu Factory-Methoden, die vor allem die Groovy Syntax und die Integration hat das halt sehr stark aussehen lassen wie eine eigene Sprache, aber letztlich war natürlich hier das Schlüsselwort ist in Groovy oder man kann die Schlüsselworte als Funktion implementieren, die dann wieder einen Codeblock übergeben bekommen und dieser Codeblock ist mit, in Groovy heißt es Closure, das ist ein Lambda letztlich, der dann ausgewertet wird in einem bestimmten Kontext und das heißt, wenn man jetzt sagt, ich will diese DSL nicht, ich will das in Java machen, ich will das in Kotlin machen, dann sieht es trotzdem sehr sehr ähnlich aus.
Florian
Na gut, aber wenn es sehr, sehr ähnlich aussieht, dann braucht man ja eine DSL dann eigentlich. Also wozu brauche ich die dann noch? Gibt es da Anwendungsfälle, wo wir halt sagen würden, okay, in dem Fall macht das Sinn. Also ich meine, das war so damals die Zeit, wo man ziemlich häufig DSLs geschrieben hat. Ich kann mich auch erinnern, dass wir das in sehr vielen Kundenprojekten auch oder in einigen Kundenprojekten auch gemacht haben. Aber wir sind da ja auch ein bisschen also nicht von weggekommen, aber wir entscheiden jetzt, glaube ich, ein bisschen. Also wir versuchen da irgendwie Kriterien zu finden, wann machen wir das und wann machen wir das nicht. Also hast du da ein Gefühl, wann man jetzt eine DSL schreiben sollte und wann man es eher lassen sollte, kurz und knackig?
Christoph
Kurz und knackig ist es letztlich eine Abwägung zwischen Flexibilität von einem Erweiterungspunkt letztlich. Wenn ich ein System konfigurieren möchte, möchte ich ja das Verhalten von einem System ändern. Das kann was ganz Einfaches sein, dass ich sage, okay, das ist jetzt halt grün statt rot oder das kann was sehr, sehr Komplexes sein, dass ich sage, ja mein Datenmodell hat eine ganz andere Struktur, als vielleicht die Entwickler das vorher gesehen haben und dann das ist die eine Frage, die ich am Anfang stellen würde, wie komplex sind die Änderungen und sind das Werte, die ich setze, das ist das Verhalten, was ich ändern möchte.
Florian
Ich würde Zittern eher eine DSL nehmen, wenn es komplexer wird, also das habe ich jetzt noch nicht verstanden. Ist das jetzt für oder ein Argument für oder also wer kann das sagen?
Christoph
Wenn ich Verhalten sehr flexibel ändern will, dann ist es schwierig, das mit an Ausschalten oder mit Werten zu machen, weil ich ja dann das Verhalten, wenn ich ein Verhalten nur einschalten möchte, muss es ja schon implementiert sein. Das heißt, wenn ich ein Verhalten einbauen möchte in der Applikation, was nicht vorgesehen ist, dann muss ich auf irgendeine Art und Weise Skripten oder zumindest so eine, wenn der Wert größer Null ist, dann linkslang, sonst rechtslang Logik unterbringen können und das ist in der Oberfläche, ohne dass man eine kleine Skriptsprache hat, dann schon wieder sehr, sehr schwer umzusetzen. Okay. Also das ist die eine Frage, die ich stellen würde, muss der Kunde, also muss der Endkunde wirklich irgendeine Art von Kontrollfluss oder von Ablauf konfigurieren müssen, können müssen? Und dann die zweite Frage, kann ich dem das zumuten? Ich meine, ist der Endkunde, ja, da ist der Endkunde vielleicht im Level 3 Support und der macht sowieso die Konfiguration und Installation von den Betriebssystemen und für den ist das, sag ich mal, okay, für den ist das vielleicht sogar eine Hilfe, dass der das über so Skripte oder eine Quell-Linguage machen kann oder ist mein Endnutzer jemand, der eine Oberfläche mitten in der Maus bedienen möchte und dem sowas total fremd ist und der diese Konzepte sonst überhaupt nicht braucht in seiner Arbeit und auch nicht benutzt und auch wahrscheinlich nicht lernen möchte.
Katharina
Also wir haben uns ja dann irgendwann dafür entschieden, dass unser Nutzer jemand ist, der die Oberfläche gerne mit einer Maus bedienen möchte. Ja. Kann noch mal jemand von euch kurz erklären, wie das dazu gekommen ist? Also war die erste Version des Frontends schon reakt, oder? Dann machen wir jetzt auch das Strom experimentieren.
Christoph
Naja, sowas wie RE-ECK gab es ja damals noch gar nicht, also es wäre, es kann gut sein, dass das RE-ECK gewesen wäre, die erste, wenn es zu der Zeit schon zur Verfügung gestanden hätte. Wir haben die erste, ich glaube, das war schon die erste Oberfläche, war glaube ich schon in Ember. Naja, sowas wie RE-ECK gab es ja damals noch gar nicht, also es kann gut sein, dass
Florian
recht erinnere. Das war der erste, genau, das war der erste Prototyp und dann die erste Version. Wir hatten ja in diesem Exply-Kontext irgendwie das Gefühl, dass die Software viermal komplett neu geschrieben und auch sehr viel gelernt und Version 1 war eine Empire JS Anwendung, soweit ich weiß.
Christoph
Version 1 war insofern nochmal speziell, wir haben damals in der Oberfläche mit Ola-Pubes gearbeitet. Der Hauptpunkt ist, dass wir das damals in der Oberfläche gemacht haben. Wir haben wirklich so eine endimensionale Datenmatrix, sorry für alle Zuhörer, die sich das jetzt nicht vorstellen können. Also wir haben im Prinzip die Rohdaten mehr oder weniger in die Oberfläche geladen und dann wurden die Ergebnisse in einer UI berechnet.
Florian
Bist du dir das sicher? Da hatten wir ja schon in der Vorbesprechung zum Podcast uns schon ein bisschen gestritten. Also ich sicher, dass wir das in der UI gemacht haben.
Christoph
Es gab zumindest Komponenten, die das gemacht haben. Ich glaube, in der ersten Version war das so. Die Daten waren schon ein bisschen vorbereitet, aber diese letzten Aggregationen, wenn ich jetzt gesagt habe, ich möchte jetzt die Summe über alles, dann wurde die Summe im JavaScript gebildet. Und wenn ich gesagt habe, ich möchte die Summe pro Ding, pro Projekt zum Beispiel, dann wurde das auch in der Oberfläche gemacht. Und die Kommunikation zum Server war relativ sparsam. Und die Perfom...
Katharina
Gab es damals noch keine Elasticsearch auf dem Server oder konnte Elasticsearch das noch nicht?
Florian
Elasticsearch gab es eigentlich von Anfang an, also ich glaube, wir haben das Projekt ja sofort mit Elasticsearch gestartet. Ganz, also jetzt gut, vielleicht... Ja, ich hole da jetzt nicht aus, sonst schweife ich mal gleich ins nächste Thema ab zu diesem ganz, wie ist Exply wirklich entstanden, ganz am Arge, mach ich da noch mal in der Ecke, kann ich ja noch mal kurz dann was sagen, wenn man es aber ratet, ja. Also Elasticsearch war eigentlich von Anfang an mit dran, als wir angefangen haben zu programmieren, es war nicht von Anfang an in unseren Köpfen. Na, vielleicht drehe ich die Runde jetzt doch erst mal ganz am Anfang, ganz, ganz am Anfang, haben wir eigentlich, wollten wir eigentlich eine Grafdatenbank verwenden, das rührt so ein bisschen daher, dass Sebastian, wir haben ja am Anfang die Firma hochgefahren nach Gründung und Sebastian hatte in seiner Diplomarbeit sich mit Semantik, hier also mit Erkennung von Entitäten in Texten beschäftigt und wie stehen die miteinander in Zusammenhang, also dass man im natürlichen Text natürlicher Sprache Personen erkennt, Firmen waren das und Orte und die dann nach diesem Semantik-Webkonzept Subjekt-Predikat-Objekt dann miteinander in Verbindung bringt und da entsteht dann halt ein Graf mit Knoten und Kanten und den kann man als RDF darstellen, also über das Format RDF und ich hatte eine ähnliche Diplomarbeit, ich habe mich mit dem UI-Teil beschäftigt, also ich habe mich sozusagen damit beschäftigt, wie kann ich semantische Datenbasen explodieren, da gibt es ja eine Abfragesprache ähnlich wie SQL, wo man halt sagen kann, ich möchte gerne bestimmte Patterns sozusagen, also bestimmte Muster definieren, die ich dann auf meinen Grafen lege und die Sachen, die in dieses Muster reinpassen, die kriege ich dann als Ergebnis zurück und da habe ich meine Diplomarbeit drüber geschrieben und wir waren halt etwas vorgeprägt auf dieses Thema Grafen sind irgendwie cool und haben halt gedacht, naja, jetzt haben wir hier die Firma, wir haben verschiedene Tools und wir haben die Datensilos, das hatten wir im letzten Podcast ja schon angesprochen, dass wir halt, uns das immer geärgert hat, dass wir jetzt nicht an die Daten rankommen aus dem Zeitbuchungstool und die zum Beispiel verknüpfen können mit Projektmanagement, Daten aus dem Redmine war das damals sogar noch und haben halt gedacht, gut, dann bauen wir jetzt so einen Grafen auf, speichern in der Grafdatenbank und dann können wir da drüber irgendwie suchen, das war so die naive Idee und ich glaube, es ist nie zur Implementierung gekommen, weil wir sind ziemlich schnell an den Punkt gekommen, dass zum Beispiel Updates in so einem Grafen ziemlich schwierig sind oder wenn die Kanten fehlen, die dann nachträglich hinzuzufügen und wir wollten dann auch suchen können über diese Daten und dann haben wir so, ja gut, jetzt haben wir eine Grafdatenbank, jetzt brauchen wir aber noch Elasticsearch um da drüber gut suchen zu können, also müssen aus dem Grafen einen Suchindex ableiten und ich kann mich noch erinnern, ich war mit Sebastian Bohl da und wir haben da noch ein Bierchen getrunken und uns hat das dann halt so ein bisschen getriggert, dass wir da nicht, also das hat sich irgendwie komisch angefühlt als Primärdatenhaltung Grafdatenbank zu verwenden und dann haben wir gesagt, ok, wir drehen das einfach um, Primärdatenhaltung wird ein Suchindex und wir formulieren sozusagen diese Kanten, die ja in dem Grafen drin sind als Queries irgendwie und das war so ein bisschen die Geburtsstunde von dem Technologie-Stack und ganz konkret von Elasticsearch als primäre Technologie in diesem Projekt So, jetzt bin ich wieder da, jetzt bin ich wieder da, wo ich abgewogen bin, also so viel zum geschichtlichen
Christoph
Genau, genau. Und es ist auch Teil der Antwort von der Frage von Katharina. Auch ich habe damals in diesen Grafen gedacht und ich hatte ja am Anfang schon gesagt, der Schwerpunkt lag auf der Suche. Und das lag vor allem daran, wir haben gesagt, wir haben verschiedene Dinge und die stehen in Beziehung zueinander. Aber diese Beziehung speichern wir nicht als Kranken in einer Grafdatenbank, weil wir diese Beziehung noch flexibler erarbeiten müssen, sondern wenn wir diese Relation laden wollen, dann formulieren wir das als Suchtquery. Also jetzt, so abstrakt, wie kann man sich das vorstellen? Also mal angenommen, ich habe jetzt E-Mails in meinem Suchindex und dann haben die E-Mails miteinander zu tun. Zum Beispiel gehören manche E-Mails zu einem Gesprächsstrang. Die werden ja auch in den E-Mail-Programmen gruppiert dann. Und das kann ich natürlich suchen. Ich kann dann natürlich nach bestimmten ID suchen. Oder ich kann sagen, ich möchte Kommunikationsnetze erfassen. Redet denn jeder mit jedem? Oder gibt es so zwei Leute, die sich immer melen, gibt es zwei andere Leute, die sich immer melen? Dann stehen die beiden Absender in Beziehung zueinander. Und ich muss diese Beziehung nicht explizit speichern, sondern ich kann, wenn ich die Daten auf die richtige Art und Weise query und auf die richtige Art und Weise durchsuche, kann ich diese Beziehung in der Abfrage berechnen lassen. Dann ist das System sehr flexibel.
Florian
Ich glaub, Katharina hat eher was zur Frontend-Technologie hingefahren. Ach so, ja, und? Wo wir abgeboten sind. Und diese... Einfach TS, oder? Waren wir doch...
Christoph
Ach so, ja. Und die ist so...
Katharina
Nee, ich hatte gefragt, warum wir die Daten, das Aufsummen und so weiter, damals im Frontend gemacht hatten, warum wir das noch nicht in der Lustig Search gemacht hatten.
Christoph
Genau, und also Elasticsearch hatten wir damals eher so im Kopf behalten für eine Suche, nicht für eine Aufsummierung, nenn ich es mal. Und in der Oberfläche haben wir am Anfang Libraries benutzt, die mit diesen Olab-Cubes rechnen konnten. Und haben das in die UI geschoben. Das hat sich bei kleineren Datenmengen richtig, richtig gut gemacht. Deshalb war super performante Kommunikation mit dem Server sparsam. Und auch die Reaktionsgeschwindigkeit der Anwendung war richtig, richtig angenehm, schnell. Wenn dieser Datenwürfel dann allerdings sehr, sehr groß wurde, hat sich das dann geändert. Und da hatten wir dann großes Performanceproblem.
Florian
Dieser Urlaubcube ist ja eigentlich nur ein Konzept, wie man auf so einen Datenraum blicken kann mit diesen mehreren Dimensionen und man schneidet sich da einen Teil aus. Also das ist ja jetzt keine Library, die ich mir runterladen kann oder das ist ja eigentlich nur ein Konzept. Das heißt, ich glaube, mich richtig zu erinnern, Elasticsearch hatte sich ja auch weiterentwickelt. Wir haben ja in dem Projekt auch richtig, richtig viel auch gelernt über Elasticsearch. Und Elasticsearch konnte ja auch schon Aggregation, glaube ich. Also wir haben damals Facetten, ja. Genau, aber der Urlaubcube ist ja jetzt nicht komplett weg. Dieses Konzept nutzen wir ja, glaube ich, heute noch. Also wenn ich das jetzt erzwingen würde, dann könnte ich mich jetzt mit euch über den Urlaubcube immer noch unterhalten und wie, wie, oder? Also, oder das ist ja immer noch ein ähnliches Konzept. Wir schneiden einen Teil aus.
Christoph
Ja, das stimmt. Also konzeptionell ist es noch das. Es ist sogar ziemlich genau das oder es ist noch sehr, sehr dicht dran, aber es spiegelt sich weniger in einer konkreten Datenstruktur wieder als damals.
Katharina
Also, mit mir könntest du dich wahrscheinlich über das Konzept nicht so gut unterhalten, weil ich, sag ich mal, Exply nicht mit dem Konzept im Kopf gelernt habe. Also, würdest du mir das erklären, würde ich wahrscheinlich sagen, oh ja, das ist genau das, was wir in Exply machen. Aber da wir uns schon komplett auf Elasticsearch verlassen haben, als ich mit dem Projekt gekommen bin, denke ich auch nur in Elasticsearch-Filtern und Aggregationen und so was.
Christoph
Ja, das stimmt. Das meinte ich auch damit, dieser Urlaub-Cube spiegelt sich nicht mehr so direkt in der Datenstruktur wieder. Aber mal als Konzept und als Denkmodell ist er trotzdem sehr, sehr hilfreich.
Florian
Können wir ja noch mal eine extra Folge machen zum Urlaub-Cube in Exply. Ja, wenn ich mich jetzt noch, also wenn ich jetzt noch eine Technologie-Änderung, also wir waren ja gerade bei Ember.js mit der Technologie, weil wir waren jetzt ziemlich viel im Backend, wir können jetzt mal auf die Frontend-Seite wechseln, was sich da so getan hat. Wir sind mit Ember.js damals gestartet, weil es gab halt kein Reakt oder das war halt noch so in den Kinderschuhen, dass, genau, dass wir unsere Erfahrungen, die wir in anderen Projekten davor gesammelt haben, dann halt wirklich produktiv anwenden konnten, deswegen sind wir mit Ember.js gestartet und das hat auch ganz gut funktioniert. Irgendwann sind wir dann aber zu Reakt geswitcht und das ist passiert, also ich habe ja immer UI-Konzepte gezeichnet und wir hatten dann dieses Dashboards-Konzept, also wir hatten glaube ich erst eine Suche, Chris, ganz am Anfang eine Suche mit so einem Suchschlitz und dann haben wir rechts irgendwelche Diagramme dargestellt oder war das links? Das war dieses auf Frontend-Seite, ich glaube auch mit D3 damals noch, D3.js, da hatten wir auch noch keine Library verwendet, genau, wir sind dann auf das Reakt-Ökosystem gewechselt, als wir angefangen haben mit diesem Dashboard-Konzept, also dass sich der Nutzer tatsächlich Dashboards zusammenbauen kann, da Widgets konfigurieren kann, die hin und her schieben kann, weil einem Reakt auf der einen Seite sehr gute Tools an die Hand gibt, mit denen man auch sehr schnell entwickeln kann und das funktioniert auch und das andere Problem meiner Meinung nach war auch dieses, wir haben halt sehr große Datenstrukturen hin und her geschoben, also tief verschachtelt, du hast irgendwie eine Dashboard-Konfiguration, da drinne hast du eine Widget-Konfiguration und da drinne ist auch wieder was und Reakt kann halt besser mit diesen tief verschachtelten Datenstrukturen, ich glaube das war auch so ein Grund, warum wir gewechselt sind, weil es nicht wieder dein Gefühl ist, Chris.
Christoph
Ja, also dem Technologiewechsel ging eine thematische Neuausrichtung voraus. Bis X-Bite 2 hatten wir die Suche von einzelnen Daten, also von einzelnen E-Mails, von einzelnen Zeitbuchungen, viel stärker im Fokus. Und die Oberfläche und der Server waren ein bisschen darauf ausgelegt. Und wir hatten sogar eine zeitlange Spotlight-Integration für den Mac, dass man sagen konnte, okay, ich möchte jetzt halt mit Spotlight was suchen. Und dann hat man die Ergebnisse gesehen. Und das hat natürlich ein serverseitiges Rendering vorausgesetzt. Das heißt, es wurden sogar Teile von der Oberfläche auf den Server gerendert und Teile im Browser, um das Ganze dann zusammen zu puzzeln. Und das ist aber zunehmend zu einem Korsett geworden. Und das war ein Punkt, der sich dann an der Stelle geändert hat. Wir gesagt haben, wir gehen etwas weg von der Suche von einzelnen Daten und gehen mehr in Richtung von Aggregation. Das war auch das, was wir damals selber mehr gebraucht haben. Und der zweite Punkt, der sich geändert hat, wir haben gesagt, okay, dieser Dashboard-Gedanke kam ein bisschen daher, dass wir gemerkt haben, wir wollen Daten vergleichen. Wir wollen verschiedene Daten-Kontexte. Wir wollen im Prinzip verschiedene Suchen nebeneinander legen. Wir wollen nicht nur eine Suche haben. Wir wollen nicht nur ein Ergebnis sehen. Wir wollen zwei Ergebnisse sehen. Weil wir die beide brauchen für eine größere Aufgabe letztlich. Und damals hatten wir gesagt, okay, die gesamte Ergebnissberechnung ist halt eine Query-Analystics-Search, aber es ist halt genau eine. Und das ist natürlich superschwierig, wenn man dann sagt, ja, aber hier möchte ich jetzt den Januar und daneben möchte ich den Februar haben. Das ist einfach schwer zu implementieren. Warum hilft da Reakt? Als wir diesen Shift gemacht haben, haben wir uns überlegt, wie wir das ganze technologisch auf neue Beine stellen. Wir haben auf dem Server ein ganz neues Konfigurations- und, sage ich mal, Ausführungs-, also Runtime-Konzept gebaut und haben im Frontend dann überlegt, okay, das müssen wir jetzt neu machen, möchten wir vielleicht die Technologie wechseln. Und haben dort dann auf Reakt geschielt. Und der Grund war damals, also man muss sagen, Ember hat sich weiterentwickelt seitdem, aber der Grund damals war zum einen Performance für den Endnutzer von der Anwendung und auch Entwicklungsgeschwindigkeit bei uns. Und der Grund war, wir hatten jetzt auch noch weniger Berechnungen auf UI-Seite, sondern es ging um fast ausschließlich, also die Ergebnisse wurden jetzt fast ausschließlich auf dem Server berechnet und ausschließlich in der UI gerendert und wir hatten große Datenänderungen, die wir darstellen wollten und weniger Interaktionen, die komplett kleinzeitig berechnet wurden.
Florian
Genau, und für die Darstellung ist es halt sehr komfortabel, wenn, also da fühlt sich, hat sich Reaktor robuster angefühlt, ne, weil man, auch gerade, wenn man jetzt in Datensstrukturen rumschreiben möchte oder anpassen möchte.
Christoph
Ja, da gibt es ja verschiedene Wege. Also, ich hatte damals mit Sebastian Gruffurst mich zusammengesetzt und wir haben gesagt, okay, wie können wir die Applikation so bauen, dass sie schnell ist. Wir wollen schnelle Updates und wenig komplexe Logik auf kleinen Seiten. Und wir haben eine sehr große und sehr komplexe Applikation. Und das, man kann den React sehr unterschiedlich einsetzen. Und wir haben gesagt, wir setzen auf den Redux Store und wir benutzen immutable Objekte. Und zwar ausschließlich immutable Objekte in dem Store. Das heißt, jetzt für alle React-Techniker, alle React-Komponenten waren pure. Wir konnten quasi mit Referenzvergleichen sofort feststellen, welche Teile der UI sich neu erinnern müssen und welche nicht. Und das, was wir als Datum in dem Redux Store hatten, also der State von der Applikation, der bestand zum größten Teil aus dem, was der Server in einer Response geliefert hat. Das waren halt die Zahlen und die Balken und die Kurven, die dann nur noch gerendert werden sollten.
Florian
Katharina, du bist ja ein bisschen später dazu gekommen in das Projekt. Ich glaube, du bist auch im Frontend eingestiegen. Jetzt hat der Chris ja gesagt, wir haben Reakt. Oder bist du bist im Frontend eingestiegen? Nein, bin ich nicht. Verdammt.
Katharina
Also jein, die Antwort ist jein. Ich hatte einen ersten Explei-Versuch gewagt, das war noch relativ früh, da war ich ja noch im Studium und hab da schon die ersten unsicheren Schritte im Frontend unternommen, hatte dann mal wieder eine Theoriephase in der Uni, also das war nur ein hoher Kurz und kein richtig tiefer Einstieg ins Projekt, der kam dann erst später.
Christoph
Ja.
Katharina
Das war so im Juli 2018 und da hatten wir gerade diesen großen Umbau mit dem Document Hypes. Da kann ich vielleicht auch gleich noch mal was dazu sagen. Und da bin ich praktisch direkt in diesen riesen Umbau mit reingeworfen worden und das war hauptsächlich bekannt.
Florian
Ach so. Schade, ich wollte dich nämlich gerade fragen, ob denn das stimmt, was der Chris gesagt hat. Aber du hast ja ein bisschen Frontend gesehen. Hast du das Gefühl, dass der Frontend Co... Also, dass es ein komplexes Projekt ist, was wir da haben, frontend-seitig? Von mir aus auch backend-seitig? Oder ist das alles ganz entspannter, sich im Frontend zu bewegen?
Katharina
Also ich muss gerade schon zustimmen, ich denke wir haben ein großes und komplexes Frontend. Auch wenn ich, also ich mach da immer nur so einzelne Abstecher ins Frontend, um mal ein paar Komponenten anzupassen und so. Ich bin relativ froh, dass ich da noch keine großen Änderungen im BeatDuck Store oder mit den Sagas oder sonst was machen musste.
Florian
Dann hätte man Alex noch mit dazuholen können, der hätte jetzt noch was.
Katharina
Ja, das stimmt, er hätte viel mehr zu sagen können.
Florian
Der kann ja was in die Kommentare schreiben. Alex, wenn du das hörst, bitte schreib was in die Kommentare. Okay, ich glaube frontend-seitig, also was ich jetzt noch mitbekomme, wir können ja gleich zu den Document-Types kommen, was ich jetzt frontend-seitig noch mitbekommen habe, zumindestens, weil ich auch dort mit am Anfang mit unterstützt habe, ich bin ja dann irgendwann aus dem Projekt rausgegangen als Entwickler zumindestens, ich mache aber immer noch Konzepte, war diese, also die unterschiedlichen Bibliotheken, die wir benutzt haben, um Diagramme zu zeichnen. Wir hatten ganz in der ersten Zeit tatsächlich das selber implementiert mit D3 und mit React gibt es, also hat man halt eine sehr, sehr große Auswahl aus Libraries, also die einem Diagramm zeichnen. Und genau, ein großes Thema war auch immer Interaktivität, also dass man halt zum Beispiel in einem Diagramm einen Balken anklicken kann und dann ändern sich andere Diagramme und ich weiß gerade gar nicht, wie viele Bibliotheken wir da aktuell im Einsatz haben, es könnten zwei oder drei verschiedene sein, je nachdem welchen Diagramm-Typ man braucht. Hast du da irgendwas mitbekommen, Chris? Weil wir machen ja gerade sehr viel Visualisierung.
Christoph
Im Moment basieren viele Widgets auf Recharts, das ist eine React-Chart-Library, aber nicht alle. Also wir haben auch Widgets, die sind auf andere Art und Weise entstanden, je nachdem, was gut gepasst hat, von daher sollte es gehen. Zur Komplexität würde ich noch eine Sache sagen, weil… Document-Types. Ne, tatsächlich zu der Struktur der UI und vom Server. Es gibt hoch abstrakte Teile und es gibt aber auch, sag ich mal, diese Standard 0.8.15 Sachen, weil die hatten, als wir die Architektur dafür neu entworfen haben, gesagt, was brauchen wir als Entwickler? Was brauchen wir als Entwickler davon? Und die Antwort war, wir brauchen ein System, wo man leicht Daten reinkriegt, darüber reden wir jetzt gleich. Und wir brauchen ein System, wo man schnell neue Visualisierungen reinkriegt. Das heißt, auf dem Server und auch im Frontend ist so eine Art Plug-In-System entstanden, was den Entwicklungsaufwand von neuen Widgets möglichst gering hält. Und es ist immer noch so, dass man die einzelnen Widgets unabhängig voneinander implementieren kann. Also wenn ich jetzt irgendeinen Widget lösche, dann ist es eine halt weg, aber es geht kein anderes kaputt. Und das ist total wichtig, damit die Anwendung gut funktioniert und man sich seine Dashboards frei zusammenstellen kann. Das ist auch total wichtig, damit wir in der Lage sind, dann halt noch nicht nur das dritte und vierte Widget zu bauen, sondern auch das zwanzigste und einundzwanzigste.
Florian
Vielen Dank. Mit dem Blick auf die Uhr würde ich jetzt, glaube ich, mal noch durch diese Liste durchgehen, die ich ganz interessant finden würde. Und zwar, was haben wir gelernt? Also es gab ja bestimmt so ein paar Sachen im Projekt, wo wir dann so gedacht haben, hinterher, oh ja, das ist interessant. Das Wissen nehmen wir mit auch in neue Projekte. Da machen wir es dann anders oder wie bei Exply. Wir schreiben halt irgendwas wieder neu. Genau, und da stehen jetzt ein paar Stichpunkte bei mir. Also ganz oben steht zum Beispiel auch Document-Hypes müssen raus. Katharina, jetzt kannst du was. Was sind dann Document-Hypes und warum haben wir die ausgebaut?
Katharina
Also das hat wieder viel mit Elasticsearch zu tun, weil Elasticsearch natürlich unsere Kernkomponente ist und wir es schon, ich glaube, ausführlich erklärt haben, zu einer älteren Elasticsearch-Version, also mit 2.5, was auf jeden Fall noch drin ist, dass jeder Index einen bestimmten Typ hatte. Und wir haben es dann praktisch so gemacht, dass wir für die verschiedenen Daten, die man rein importieren konnte, zum Beispiel E-Mails oder Zeitbuchungen, jeweils einen eigenen Typ erstellt haben und die dann auch in eigene Indizes gepackt haben. Das hat aber dazu geführt, dass man diese Daten eben nicht in einem Dashboard miteinander vergleichen konnte. Also man konnte nicht jetzt sich die E-Mails versus die Zeitbuchungen anzeigen, das macht jetzt vielleicht auch noch nicht so viel Sinn, aber anderen Datentypen hätte es auf jeden Fall Sinn gemacht, die miteinander vergleichen zu können. Das war eine sehr große Schwäche damals, außerdem ist dann auch Elasticsearch selber von dem Konzept abgekommen. Also dass wir jetzt nur noch ein Index für alle möglichen Datentypen haben. Soweit ich weiß, kann man in der aktuellen Elasticsearch-Version auch nur einen Typen haben, oder so?
Florian
Es gibt nur noch einen Index, genau, es gibt nicht mehr unterschiedliche Dokumententypen. Wenn ich mich richtig erinnere, dann ist das sozusagen die technische Erklärung, warum wir weggegangen sind von Document Types, aber es gibt auch eine aus Usability Sicht, weil uns hat das selber immer übelst frustriert in diesem Dropdown, also in der UI gab es dann einen Dropdown und dann musste man für jedes Widget immer...
Katharina
nicht mehr unterschiedliche Dokumente.
Florian
immer den Dokumenttypen auswählen, damit man nicht Doppelzählung reinbekommt, also dass Werte zum Beispiel nicht doppelt gezählt werden. Also es war auch aus Nutzerfreundlichkeits-Komplexitätssicht auch sehr gut, dieses, ich sag's mal in Anführungsstrichen, dieses Feature dann loszuwerden. Genau, und das war halt ein riesen Reflektor. Ich glaube, das hat hauptsächlich Katharina dann auch durchgezogen. Das waren ja irgendwie 80.000 Zeilen geänderter Code. Nee, Quatsch, keine Ahnung, weiß ich nie, müsste ich jetzt reingucken, aber ich glaube, da warst du ja hauptsächlich auch mit unterwegs.
Katharina
Ja, das haben Chris und ich zusammen gemacht. Ich bin mit reingekommen, also vielleicht 50% davon.
Christoph
Weiß ich nicht mehr genau. Aber es war auf jeden Fall noch ganz, ganz viel offen. Es war ganz viel, oh ja.
Katharina
Man muss noch viele Migrations schreiben. Das war damals sehr aufwendig, weil die ganzen Konfigurationen geändert werden mussten. Wir haben sehr viele Feldnamen umbenannt und Tests neu geschrieben.
Florian
Also für mich von außen hat sich da so angefühlt wie Straße einmal komplett aufreißen und dann hübsch wieder zubetonieren. Also nochmal gute Leitung verlegen, schnelles Internet, Glasfaser und so und dann alles wieder zumachen.
Katharina
Ja, also, glaube ich, ich glaube, das war's auch. Wir hatten auch hinterher nochmal, wie, sag ich mal, wieder alles auf dem alten Stand war. Das Ding bei so einem großen Umbau ist natürlich, ist, es ist übelst viel Arbeit, aber sehen tut man davon nichts, weil es an der Funktionalität praktisch nichts ändert. Das Dropdown ist weg. Okay, herzlichen, herzlichen Glück.
Florian
Das Dropdown ist weg. Hey, herzlichen Glückwunsch, mehrere Wochen Arbeit und das Dropdown kann man jetzt einfach weglassen. Genau.
Katharina
Genau. Also, wo wir gesagt haben, das ist jetzt fertig, das Merchantment jetzt war so, es funktioniert wieder wie vorher.
Florian
Und das Dropdown fehlt. Was ich, woran ich mich auch dran erinnern könnte, dieses Thema hat ja schon immer so geschwählt, dieses Document-Types. Und ich kann mich erinnern, wir haben die erste Diskussion geführt. Dann haben wir festgestellt, dass uns der Kopf wehtut. Dann haben wir die nächste Diskussion geführt. Dann haben wir uns festgestellt, dass uns der Kopf wehtut. Also das sind halt für mich waren das immer sehr, sehr interessante Diskussionen, weil das Problem halt nicht trivial zu lösen ist. Also aber wir haben ja auch also in die Diskussion sind wir eingestiegen aus Nutzer-Sicht. Das Dropdown ist, das war die Spitze des Eisbergs. Das muss weg. Und darunter hat sich halt dieser riesen, riesen Eisberg aufgetan. Und die Diskussionen, die haben mich immer sehr angestrengt. Aber ich fand es halt spannend.
Katharina
Ja, also es war am Ende schon so eine richtige Grundsatzdiskussion, inwiefern man Daten, die halt verschiedene Dimensionen haben, also verschiedene Felder haben, miteinander irgendwie sinnvoll vergleichen kann, gerade wenn sie in Beziehungen zueinander stehen, vielleicht auch in einer hierarchischen Beziehung oder so. Wie wollen wir das im LST Search modellieren, also dass der Nutzer sinnvoll auswerten kann und das ist auch alles ein Thema, da kommen wir bestauernd dran vorbei. Das weiß ich auch nicht, wann das fertig sein wird. Also ist heute noch ein Thema, das wir nochmal drüber nachdenken müssen. Wie müssen denn die Daten jetzt da aussehen, dass wir den Nutzer, die wirklich miteinander korrelieren kann.
Florian
Ich glaube, das hat, also zumindest, ich bin ja schon eine Weile länger dabei. Das fand ich an Exply halt immer sehr, sehr interessant über die letzten Jahre, weil das ist für uns auch eine Möglichkeit, neue Technologien auszuprobieren. Vielleicht waren wir deswegen auch in der Vergangenheit immer so schnell dran, mal Sachen neu zu bauen oder neu zu denken. Und ich habe immer das Gefühl, dass wir in dem Projekt sehr, sehr viel lernen, was wir auch in andere Projekte reintragen.
Christoph
Ja, das war. Irgendwann wurde es aber zum Problem. Irgendwann habe ich auch dann immer deutlich kommuniziert zu Leuten, das wird jetzt ein Produkt, das ist jetzt keine Spielwiese mehr, da ist kein Platz mehr für halbfertige Features, bitte denkt daran. Am Anfang war das das genaue Gegenteil. Wir haben ja die eigene DSL gehabt, wozu brauchen wir die Oberfläche, wir wollen ein flexibles System. Wir haben die Libraries ausgetauscht, wie es uns beliebt hat. Wir hatten da, weiß ich, wie viele verschiedene Web-Server drin und da.
Florian
Ja, aber den Absprung haben wir jetzt ja geschafft, ne? Also ich glaube, diese ganze Produktsache hat mir in der letzten Folge ja auch schon beleuchtet. Ich glaube, da haben wir ja auch sehr viel gelernt. Weil dieses Prototyp...
Christoph
Diese Prototypphase, die ist ja total wichtig. Ich muss ja auch meine erste Idee validieren und weiterentwickeln. Was soll ich denn eine schöne UI bauen für ein System, was mir überhaupt keine Daten liefert oder das Problem, das ich habe, überhaupt nicht löst?
Katharina
Aber es ist genauso wichtig, irgendwann aus der Prototypphase rauszukommen. Gerade wenn man das Ziel hat, es vielleicht auch irgendwie verkaufen zu können.
Christoph
Ja, wenn man es nicht bedienen kann ohne eine Woche intensive Einarbeitung, ist es halt auch nicht so nützlich.
Florian
Aber Document-Types war jetzt nicht mehr Prototyp, das war ja tatsächlich funktional entwickelt. Fallen euch jetzt noch Sachen ein, die wir irgendwie gelernt haben oder wo vielleicht dann eine größere Baustelle, wo wir die Straße wieder aufgerissen haben oder vielleicht auch kleinere Sachen, die vielleicht interessant werden, nochmal zu erwähnen.
Katharina
Mmm...
Christoph
Eine Sache, die sehr interessant ist, ist, dass das System quasi eine Multiprozess-Architektur ist, wenn man das so sagen kann. Und zwar hat es angefangen bei den Datenimporten. Wir beziehen die Daten aus sehr, sehr unterschiedlichen Quellen und die sind auch sehr unterschiedlich in der Performance und in der Stabilität. Und am Anfang haben wir quasi eine Server-Komponente gehabt. Das war ein Prozess und dort drin wurden Threads gestartet, die die Daten importiert haben. Und wir hatten immer wieder das Problem, dass durch irgendwelche Bugs irgendwo mal diese Threads amok gelaufen sind. Die sind mal stehen geblieben und ließen sich dann auch nicht mehr so richtig beenden, weil die wollten einfach nicht. Und das war natürlich doof. Und da haben wir dann gesagt, okay, wir starten den Import in einem anderen Prozess. Das heißt, wir können den jederzeit beenden. Wir können den von außen gut überwachen. Wir müssen auch uns nicht Gedanken machen, ob jetzt die Library, die halt dieses System gerade anbindet, auch wirklich alle Connections zumacht oder ob da möglicherweise irgendwo Speicherbeleg bleibt oder was auch immer. Und haben dann dort eine sehr interessante Interprozesskommunikation gebaut. Am Anfang haben wir versucht oder überlegt, das System verteilt zu bauen, dass die quasi über Ports und Sockets kommunizieren mit TLS, also HTTPS war das verschlüsselt, und haben dann gesagt, okay, das ist zu langsam. Wir machen das jetzt über, wir schieben jetzt Bites direkt durch den RAM und das sind Memory Map Files, da haben wir eine Library für, die kommt, glaube ich, ursprünglich aus dem High-Frequency-Trading, also die ist eher auf Performance ausgelegt und so kommunizieren quasi die Prozesse miteinander. Und das Ganze wurde dann nochmal interessant bei dem Jira Add-on, weil verständlicherweise hat Atlassian, wenn man einen Plug-in schreibt für Jira, dann möchte Atlassian gerne, dass der Jira Server davon nicht beeinträchtigt wird in der Performance und Stabilität. Das ist eine sehr gute Zielstellung und ich glaube, dass auch viele Kunden sich wünschen, dass wenn sie ein Plug-in installieren, dass ihr Server dann gut weiter funktioniert. Und dafür haben die auch, also Atlassian hat ein Plug-in System entwickelt, was auch diese ganzen Add-ons voneinander isoliert und Exply als Applikation da reinzupacken war halt ein bisschen overkill. Ich meine, da steckt ja das X-Search mit drin, das ist ja nicht nur ein kleines Convenient-Feature, sondern es ist ein riesen Blumenstrauß, das ist eine eigene Datenauswertung. Und da haben wir den gleichen Weg gehen können, dass wir sagen, okay, wir blockieren jetzt nicht den Jira-Prozess und packen da alles rein und dann auch noch mit diesem Sandboxing wird das Ganze noch langsamer, sondern wir sagen, okay, wir haben einen dünnen Rapper und wir starten einen zweiten Prozess, der eigenständig läuft und seine eigenen Ressourcen hat und die auch selbst verwalten kann. Und die kommunizieren dann auch nicht über einen Port, den man aufmachen muss, weil das mögen auch viele Leute nicht. Das ist auch immer die Frage, ist der vielleicht doch von außen erreichbar und ist das überhaupt sicher? Sondern die kommunizieren auch über diese Memory-Channels und das hat sehr, sehr gut funktioniert. Und das ist auch der aktuelle Stand, wie es funktioniert.
Florian
Ich glaube, auch mit diesem Jira Plugin haben wir ja auch sehr viel gelernt, auch was Betrieb angeht und so unterschiedliche Datenbanken. Das waren zumindest Themen, die immer so am Rande hochgekommen sind. Da hat halt einmal hier eine Microsoft SQL oder wie das heißt, unterschiedliche Datenbanken, für die man dann sozusagen wieder irgendwas anpassen muss, war von außen zumindest immer so ein Thema. Also da haben wir auch sehr viel gelernt, die Integration in ein anderes Tool. Genau, ich würde euch jetzt am Ende noch die Frage stellen, gibt es irgendwelche Themen, auf die ihr euch freut, wo wir vielleicht wieder die Straße aufreisen oder zeichnet sich schon irgendwas am Horizont ab? Was wäre denn so euer Wunschkonzert für die, ich sag mal fürs nächste Jahr, Exply-Entwicklung? Habt ihr da irgendwelche...
Katharina
Also ich freu mich im Moment auf jedes neue Feature, das ich entwickeln darf, weil im Moment, ich sag mal, durch das Einführen dieser Konfigurations-UI haben wir den Funktionsumfang vielleicht relativ stark eingeschränkt, zum Beispiel, dass man nur aufs Summieren kann als Datenauswertung. Man konnte auch bis vor kurzem nicht irgendwelche selber Berechnungen durchführen und jetzt sind wir aber gerade in dem Prozess, dass wir neue Funktionen hinzufügen, darunter, dass man zum Beispiel auch Durchschnitte bilden kann, anstatt nur aufzusummieren oder Minimum Wert herausfinden oder Maximum Wert herausfinden. Außerdem bauen wir gerade auch ein, dass man mit den Daten Berechnungen durchführen kann und so und das ist komplex. Also die gerade technischen Konzepte zu machen, ist oft sehr anstrengend, aber es macht gerade, also es macht auch sehr viel Spaß. Wir wollen ja die harten Nüsse knacken hier und das sind alles so harte Nüsse. Das macht sehr viel Spaß. Und da wird, denke ich, auch noch einiges kommen. Das andere Thema ist natürlich, diese ganzen Funktionen, die wir jetzt mal einbauen, auch irgendwie intuitiv benutzbar zu machen. Ich glaube, das ist für uns aktuell die größere Herausforderung, eine UX zu bauen, die trotzdem noch irgendwie möglichst einfach ist. Dass der Nutzer, auch wenn er nicht total den Plan hat von Datenauswertung, sich da irgendwas zusammenbauen kann. Ja, das wird auch noch mal spannend.
Florian
Chris, hast du irgendwas? Vielleicht machen wir ja Kotlin. Hä? Kotlin?
Christoph
Na gut, das wäre ein rein technischer Umbau. Ja, Groovy durch Kotlin irgendwann ersetzen. Das hatte ich mir schon mal angeguckt, das lässt sich eher schlecht automatisieren oder nur zum Teil automatisieren. Aber ich meine, davon hat der Kunde letztlich erstmal nichts, nur danach gehen vielleicht die Features schneller oder der Speicherfootprint ändert sich, hoffentlich wird er kleiner. Ähm, naja.
Florian
neuer Hammer für die gleichen Nägel.
Christoph
Genau, genau, das ist sage ich mal, darauf hätte ich Lust, so perspektivisch, muss man natürlich gucken, kann man das schrittweise machen oder muss man das wieder alles auf einmal machen, wie bei den Document-Types, wo ich, was ich auch total spannend finde, wo wir, sage ich mal schon die Fühler ausgestreckt haben, ist der ganze Cloud-Betrieb, also dort noch...
Florian
Das ist eigentlich mal darauf.
Katharina
Das war's für heute.
Christoph
Also es gibt jetzt schon Cloud-Instanzen, die man sich als dem Instanzen holen kann, aber dort den Betrieb stärker zu automatisieren, das wird interessant. Die Anbindung vielleicht, also ist jetzt leider nicht mit konkreten Datum geplant, an die Jira Cloud. Das wird interessant und dieses, sage ich mal, dieses ganze große Thema nach der Entwicklung, das interessiert mich halt auch sehr, sehr groß, also der Betrieb der Anwendung. Das finde ich auch sehr, sehr spannend. Bin ich gespannt, wann das kommt.
Florian
Es bleibt spannend, das wird nicht langweilig und wir werden ganz viel lernen in Zukunft.
Katharina
Auf jeden Fall.
Florian
Gut, dann denke ich, haben wir jetzt viel über Exply, Technologiestack und was uns da so bewegt, gelernt. Ich danke euch auf jeden Fall, dass ihr euch die Zeit genommen habt. Danke auch den Leuten, die da draußen zuhören. Lasst einen Kommentar da. Genau, abonniert uns. Wir freuen uns auf die nächste Folge. Macht's gut!
Katharina
Gut, tschüss!
Florian
Tschüss, auf Wiedersehen!
