002: Unser Backend-Technologie-Stack
Welche Technologien nutzen wir im Backend und warum haben wir uns für diese entschieden?
27.02.2023 54 min
Zusammenfassung & Show Notes
Wir gehen durch unseren Backend-Technologie-Stack und erklären, warum wir uns für genau diese Komponenten entschieden haben und weshalb alternative Lösungen ausgeschieden sind.
Benjamin und Sven führen durch unseren Backend-Technologie-Stack und erklären, warum wir uns für genau diese Komponenten entschieden haben und weshalb alternative Lösungen ausgeschieden sind.
Technologien
Technologien
Artikel
- Sebastian Sellmair: I hated Gradle! Kotlin and the buildSrc Plugin made me love it
- Martin Fowler: CQRS
Transkript
In dieser Episode werfen wir einen Blick auf unseren Backend Technologie-Stack.
Herzlich willkommen. Ich bin Sven Wiegand, CTO bei Orgavision.
Ich bin Benjamin Hagemeister, Backend-Entwickler bei Orgavision.
Genau. Und heute sind wir ja dementsprechend nur zu zweit. Und heute solls gehen
um unseren Backend Technologie-Stack,
wo wir einfach mal ein detaillierteren Blick drauf werfen wollen und dann auch
erklären wollen, warum wir uns für bestimmte Sachen und gegen andere Sachen entschieden haben.
Ja, was waren eigentlich unsere Kriterien für die Auswahl von Themen?
Ich könnte jetzt wieder so anfangen wie in der letzten Episode Alles,
was cool ist, was wir schon immer mal machen wollten. Aber nein,
das stimmt so einfach nicht.
Im Endeffekt sind es halt einfach auch die Sachen, mit denen wir durchaus schon
Erfahrungen haben. Idealerweise gute Erfahrungen natürlich.
Allerdings durchaus auch gemischt mit Sachen, wo wir denken.
Naja, da haben wir vielleicht eher schlechte Erfahrungen gemacht.
Lass uns doch mal das und das jetzt auch machen.
Womit wir schon ein bisschen bessere Erfahrungen gemacht haben.
Aber Erfahrung ist dabei ein ganz, ganz wichtiger, ausschlaggebender Punkt.
Ja genau, das basiert dann auch wiederrum auf unseren Erfahrungen.
Wobei in der Vergangenheit durchaus umfangreiche Projekte mit Sachen begonnen
haben, wo wir niemand im Team hatten, der das ernsthaft schon mal nach Realität eingesetzt hat.
Ich denke da so an Wicket als Webframework. Ist schon lange her.
Das war eine super Entscheidung.
Müssen wir zu unserer Verteidigung sagen.
Naja, und das zeigt dann halt doch, dass man da dann in erhebliche Probleme reinläuft.
Und gleichzeitig ist es halt so, dass ja hier auch eine Business-Need dahinter steht.
Also wir wollen innerhalb eines Jahres ein Produkt liefern, ein MVP,
ein minimal variable Produkt und dementsprechend bietet es sich an,
Sachen zu nehmen, wo wir halt,
wissen, wo die Stärken und Schwächen liegen. Auch wie.
Wenn du sagst, dass an einigen Stellen an einigen Stellen halt anders ist und
wir uns doch für was entschieden haben, wo wir noch nicht ganz so viel Erfahrung haben.
Und auch noch wichtig Erfahrung betrifft hier zum einen natürlich die Entwicklungsseite,
und zum anderen auch die Betriebsseite, die da auch eine große Rolle spielt,
aber das dann auch bei den einzelnen Punkten differenzieren.
Na dann fangen wir ganz vorne an, nämlich beim Thema Programmiersprachen.
Ja, wir haben uns dafür entschieden, Kotlin zu verwenden. Ich könnte mal meine
Begründung dafür ganz einfach zusammenfassen Java kommt nicht in Frage und Scala
hätten wir ja auch nicht durchgesetzt bekommen.
Nein, also im Endeffekt ist es. Es ist halt so Kotlin ist auf jeden Fall die
modernere Programmiersprache als Java und hat da einige massive Vorteile.
So etwas geht an funktionaler Programmierung und Ähnliches haben wir ja auch schon eingesetzt.
Auch in einem anderen Projekt haben wir ja angefangen, zunehmend neue Sachen
in Kotlin zu machen und auch bestehenden Java Code auf Kotlin umzustellen.
Und von daher hat es sich halt einfach angeboten, das hier auch zu machen und
zwar gleich von vornherein und durchgängig. Also kein kein Gemisch aus verschiedenen Sachen.
Und so haben wir ja jetzt auch wieder viele Sachen. Wenn wir nutzen,
was, womit wir Erfahrung haben, womit wir uns auskennen.
In einigen Teilen schon sehr gut, in anderen Teilen bestimmt noch nicht ganz
so gut, wie es möglich wäre.
Was aber gleichzeitig durchaus auch noch moderner ist als in dem Fall Java,
was noch die Alternative gewesen wäre.
Genau. Wir haben beide schon in der Vergangenheit in Scala gearbeitet.
Aber da ist der riesige Unterschied der, weshalb es für unser Produkt nicht
in Frage kam, dass schlecht.
Interoperabilität zwischen Java und Scala ist natürlich gegeben,
weil es beides auf Java Virtual Machine basiert, aber einfach von den Programmier
Paradigmen und dem was der Scala Compiler generiert, hat das einfach nicht gut gepasst.
Insbesondere wenn man dann eine Mischung hat. Wenn man bestehenden Java Code.
Genau genommen.
Hat und dann schrittweise um Scala ergänzen oder umstellen will.
Das ist da einfach deutlich schwerer.
Genau und deswegen kam es für unser Produkt nicht in Frage. Und da war dann
halt auch nicht mit was ganz anderem arbeiten wollten.
Im neuen Produkt haben wir uns dann halt entsprechend, oder?
Stand überhaupt nicht zur Debatte. Sind wir ehrlich.
Ja, wir haben nicht wirklich darüber gesprochen. Es stand von vornherein fest.
Ja, wie sieht es denn? Wie schätzt du denn da die Situation mit Java ein?
Ich meine, es hat ja schon an einigen Stellen in den letzten Jahren hat er die
Geschwindigkeit ja doch ein bisschen zugenommen.
Und zum Beispiel gibt es ja tatsächlich Pattern Matching.
Also wenn man hier damit zu tun hat, das hat nicht mit regulären Expression
zu tun, sondern ich sag mal, da geht es um Switchcase und Stereoids, wenn man so nennen will.
Und das ist ja zum Beispiel eine Sache, die bietet Java inzwischen Kotlin aber nicht.
Naja, Kotlin schon, aber inzwischen eingeschränkter als Java muss man ja tatsächlich leider sagen.
Da sind auch mit meines Erachtens Mussmuster Kotlin auch noch nachliefern.
Da muss noch mehr kommen.
Ansonsten wird es natürlich irgendwann auch ein bisschen schwer noch zu rechtfertigen,
warum man nicht einfach direkt Java verwendet.
Was ich bei Java immer noch sagen muss, dass ich sage, so viele funktionale
Konzepte fühlen sich da für mich
fremd an, man merkt, dass sie irgendwie nachträglich eingebaut wurden.
Streamaby.
Und genau und ich finde das zum Teil, wenn ich es einmal in Java machen muss
an irgendeiner Stelle, dann brauche ich erst mal wieder eine Weile,
um zu verstehen, wie es geht.
Gut, das ist natürlich auch eine Sache, dass ich es nicht oft mache,
aber ich finde es dann auch zu
komplex, zu kompliziert. Das geht in Kotlin deutlich deutlich einfacher.
Und das Thema interessiert mich einfach, weil ich da so drin stecke,
weil ich tatsächlich nie praktischen Kotlin programmiert habe.
Also ich habe ganz früher C plus plus, dann Java jahrelang und dann Scala gemacht
und TypeScript ganz viel.
Aber Kotlin habe ich keine praktische Erfahrung.
Wie ist es denn damit? Pattern Matching? Was geht denn da und was geht nicht?
Ist jetzt ein bisschen sehr detailliert, aber interessiert mich einfach.
Also im Endeffekt, es geht schon eine ganze Menge. Du kannst halt so Sachen machen.
Du sagst, ich habe hier irgendwas. Ich weiß gar nicht genau,
was für ein Objekt das ist. Und wenn es jetzt das ist, dann mach ich das.
Wenn es das ist, mach ich das. Wenn das mache ich das und Ähnliches.
Du kannst im Zweifelsfall, wenn du Nebenbedingung gar nichts rein schreibst,
kannst du auch kompliziertere Bedingungen machen, dass du dann halt sagst okay,
wenn jetzt, weiß ich nicht.
Ich habe in der Funktion ein Objekt rein und dann mache ich in dem Moment,
wenn der Vorname sowieso ist und der Nachname länger als das,
dann mach das und Ähnliches kannst du dann machen.
Das ist immer eine Sache, wo es mir so geht. Wenn ich so ein Wesen sehe,
ohne dass irgendwie ein konkretes Objekt da drin steht, auf das geprüft wird,
fühlt sich das für mich immer ein bisschen komisch an, weil ich es von Scala
auch wirklich anders kenne.
Aber an einigen Stellen geht es einfach nicht anders. Ja.
Nein, so was geht nicht. Das hatte ich gerade sagen wollen. So eine der Sachen,
die mir am meisten fällt, ist das Dekonstruieren.
Ja, ist auch ein nicht nur von mir, sondern von anderen gewünscht Features.
Aber soweit ich weiß, gibt es da auch aktuell keine Pläne umzusetzen.
Was ich auch durchaus bei Scala häufiger genutzt habe und sehr schön fand.
Was ich jetzt aber nicht so essenziell wichtig finde, ist die Verarbeitung von
regulären Ausdrücken über.
Wenn also das so da drin heißt, das auf die Gruppen zugreifen kann,
die dann machen müssen, um wieder irgendwas rauszuholen.
Das geht in Scala schon auch sehr schön und elegant, das geht in Kotlin so auch
nicht. Aber ja, also es geht schon einiges.
Zum Thema Expression. Es ist ein Kotlin, übrigens auch eine Expression.
Also auch da kann man was zurückgeben. Das sind auch so Sachen.
Das war ja aber meines Wissens noch nicht der Fall. Wobei ich jetzt die letzten
Entwicklungen bei aber auch nicht so im Detail verfolgt habe.
Deswegen weiß ich es nicht wirklich.
Und das ist halt, wenn man wirklich funktional programmieren will,
ist das auch eigentlich fast schon essenziell, dass es im Idealfall alles eine Expression ist.
Ja, kann ich, kann ich verstehen. Wir verwenden Gradle.
In dem Fall was Erfahrung angeht, ist es halt auch wieder so hier in der Firma
setzen wir Gradle und mal ein.
Wobei ich glaube, das erste Gradle Projekt habe ich auch mit eingebracht,
weil ich halt aus der vorherigen vorherigen Firma schon einiges an Erfahrung mit Gradle hatte.
Ja, ich. Ich glaube, das System ist dann im Zweifelsfall was.
Wenn ein Projekt aufsetzt, sollte man das verwenden, wo man wirklich Erfahrung
hat und was einem dann irgendwie auch noch am ehesten Spaß macht,
falls das bei einem System geht.
Wenn man sich mal im Internet ein bisschen umschaut und gerade auch mal so diesen
Vergleich sucht. Gradle was ist man eben?
Dann findet man natürlich jede Menge Beiträge von Leuten, die eines der beiden
Systeme hassen und sagen, dass
man auf jeden Fall das andere nehmen sollte und auf gar keinen Fall das.
Hat sich also auch zur Religion entwickelt, genau wie die Programmiersprache
und die Entwicklungsumgebung.
Genau.
Was ich ganz interessant finde Ich habe sehr oft auf Beiträge gestoßen, wo halt Leute,
die halt für Maven waren und gegen Gradle, wo dann so Argumente kamen wie Ja,
Gradle hat eine steile Lernkurve, das ist halt mühsam, das zu lernen.
Man braucht dann im Grunde einen Experten im Team und wenn der mal krank ist, dann geht gar nichts.
Und außerdem, was sich da auch oft schon gelesen habe, sind dann so Sachen.
Es ist ein Bild System. Ich will keine DSL lernen, ich will es einfach nur verwenden.
Ich bin da jetzt in einer interessanten Situation. Meine Java Erfahrungen haben
angefangen in einer Firma, die angefangen hat mit Java, bevor es Maven gab,
die demzufolge als Bildsystem hatten.
Trionören und Skripte Skripte schreiben in XML.
Und danach?
Ja, genau. Und danach war ich in der Firma, wo wir dann erste Gradle gearbeitet
haben und dann mit Scala,
also mit Speed, dann später und erst hier bei Orgavision bin ich das erste Mal
wirklich intensiver mit Mädchen in Kontakt gekommen.
Und ich kann nur sagen, mein Mann hat auch eine steile Lernkurve.
Ich glaube, das hat viele, die es seit Jahren einsetzen. Die haben das vergessen,
weil es seit ewig her ist.
Und ich habe auch die Erfahrung gemacht, dass es jetzt keineswegs so ist,
dass jeder im Team das Skript im Detail kennt und irgendwie einzelne Punkte erklären kann.
Ich finde es dann schon auch an vielen Stellen einfach wahnsinnig sperrig,
was auch dem Format geschuldet ist.
Also XML magister für Maschinen gut verarbeitbar sein, aber ich bin keine Maschine,
ich kann nicht gut lesen, ich finde das einfach nur mühsam.
Und im Endeffekt muss man sagen, all diese Argumente, die könnte ich jetzt genauso
gut auch gegen meine bringen bringen, weil ich halt Gradle vorher gelernt habe und es einfacher finde.
Im Endeffekt ist das alles Quatsch. Das, was die meisten Entwickler regelmäßig
mal machen müssen, ist irgendwie genau Dependencies einzufügen,
Versionen aktualisieren,
und das kriegt man auch hin, wenn man wenig bis keine Erfahrung mit dem System
hat und hat dann irgendwie mal ein paar Kommandos auszuführen,
wenn man es nicht sowieso über die Entwicklungsumgebung macht.
Das kriegt man dann auch noch hin. Also von daher, ich persönlich würde immer
sagen verwendet das, was euch liegt.
Das ist bei mir persönlich halt eher Gradle als eben. Ein ganz,
ganz ausschlaggebender Punkt ist für mich wirklich das Dateiformat.
Also ich finde es einfach furchtbar für solche Sachen.
Dann ist es tendenziell halt auch so, Gradle und Medien verfolgen halt schon
sehr andere Ansätze. Also mir eben ist alles sehr strikt geregelt und man darf
ja eigentlich fast nichts machen.
In Gradle kann man alles machen, was dann natürlich auch zu totalem Wildwuchs
führen kann und zu Skripten, die mehrere 1000 Zeilen lang sind und so eben auch
wirklich keiner mehr weiß, was Sache ist.
Muss man aber ja in beiden Stellen nicht machen. Also es gibt dann ja auch Alternativen.
Was ich dann sehr interessant fand, war, als ich irgendwann meinen Namen gefunden
habe, mit dem man Skripte ausführen konnte, womit man dann im Endeffekt doch
irgendwie alles machen kann, was glaube ich auch ein Stück weit eigentlich gegen
die Philosophie von mir verstößt. Aber.
Ja, man kann ja glaube ich auch eigene Plugins schreiben, aber das ist dann
richtig aufwendig. Die muss man ja schreiben, die müssen ja auch irgendwie dann
wieder auch gebaut werden, damit sie dann überhaupt genutzt werden können.
Also das mit im Prinzip getrennte Projekte sein, glaube ich, oder?
Glaube ich nicht. Es hat doch keiner mitbekommen, wie sehr.
Was, was eigentlich ins Typsystem reingehören würde.
Ja, Ja. Ein Mann von der Art von Jasper.
Und da sind wir damals auch auf den Hype reingefallen. Da haben wir überhaupt
nicht viel analysiert, sondern als wir die ElasticSearch sgeschichte gemacht
haben, war klar Event Broker wird Kafka, weil zu der Zeit einfach hipp war.
Naja, also immer weiter.
Benjamin
00:00:27
Sven
00:00:31
Benjamin
00:00:57
Sven
00:01:27
Benjamin
00:01:45
Sven
00:01:45
Benjamin
00:02:44
Sven
00:03:49
Benjamin
00:04:16
Sven
00:04:18
Benjamin
00:04:20
Sven
00:04:26
Benjamin
00:04:38
Sven
00:04:43
Benjamin
00:05:12
Sven
00:05:42
Benjamin
00:05:43
Sven
00:06:02
Benjamin
00:06:23
Sven
00:10:23
Benjamin
00:10:28
Sven
00:11:13
Benjamin
00:11:14
Sven
00:13:36
Feedback geben
Wir freuen uns über Dein Feedback – sowohl zu unseren technischen Erlebnissen und Entscheidungen als auch zu unserem Podcast. Gibt es vielleicht ein Thema, dass Du gerne behandelt haben möchtest? Dann kontaktiere uns hier gerne.