building a product

Sven Wiegand – orgavision GmbH

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
Artikel

Transkript

In dieser Episode werfen wir einen Blick auf unseren Backend Technologie-Stack. Herzlich willkommen. Ich bin Sven Wiegand, CTO bei Orgavision.
Benjamin
00:00:27
Ich bin Benjamin Hagemeister, Backend-Entwickler bei Orgavision.
Sven
00:00:31
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?
Benjamin
00:00:57
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.
Sven
00:01:27
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.
Benjamin
00:01:45
Das war eine super Entscheidung.
Sven
00:01:45
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.
Benjamin
00:02:44
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.
Sven
00:03:49
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.
Benjamin
00:04:16
Insbesondere wenn man dann eine Mischung hat. Wenn man bestehenden Java Code.
Sven
00:04:18
Genau genommen.
Benjamin
00:04:20
Hat und dann schrittweise um Scala ergänzen oder umstellen will. Das ist da einfach deutlich schwerer.
Sven
00:04:26
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.
Benjamin
00:04:38
Ja, wir haben nicht wirklich darüber gesprochen. Es stand von vornherein fest.
Sven
00:04:43
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.
Benjamin
00:05:12
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.
Sven
00:05:42
Streamaby.
Benjamin
00:05:43
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.
Sven
00:06:02
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.
Benjamin
00:06:23
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.
Sven
00:10:23
Hat sich also auch zur Religion entwickelt, genau wie die Programmiersprache und die Entwicklungsumgebung.
Benjamin
00:10:28
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.
Sven
00:11:13
Trionören und Skripte Skripte schreiben in XML.
Benjamin
00:11:14
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.
Sven
00:13:36
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.

Feedback

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.

Mit einem Klick auf "Nachricht absenden" erklärst Du Dich damit einverstanden, dass wir Deine Daten zum Zwecke der Beantwortung Deiner Anfrage verarbeiten dürfen. Die Verarbeitung und der Versand Deiner Anfrage an uns erfolgt über den Server unseres Podcast-Hosters LetsCast.fm. Eine Weitergabe an Dritte findet nicht statt. Hier kannst Du die Datenschutzerklärung & Widerrufshinweise einsehen.

★★★★★

Gefällt Dir die Show?
Bewerte sie jetzt auf Apple Podcasts