Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

IT-Security

Produktentwicklung

Weitere Leistungen...

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Senior Agile Consultant

it-daily.net

Künstliche Intelligenz

Softwareentwicklung

Schreibt in Zukunft nur noch KI unsere Software?

Goetz Markgraf erklärt auf it-daily.net, wie KI mit „Vibe Coding“ die Softwareentwicklung verändert – Entwickler bleiben dabei weiterhin zentral.

Agil trotz klassischen Projektmanagements? Das kann doch nicht gehen! Agil und klassisch, das sind doch zwei Welten, die nichts miteinander gemein haben! Agil, das ist Scrum! Und Klassik, das ist das Wasserfall-Modell!Solche oder ähnliche Meinungen und Vorurteile kann man immer wieder von denjenigen hören, die in der klassischen Welt zu Hause sind und von agiler Arbeitsweise bislang nur gehört haben. Oder von solchen, die bisher ausschließlich agil gearbeitet haben und das klassische Projektmanagement nur vom Hörensagen kennen.Keine Frage, agil ist in, ist hip. Wer heute modern sein will, macht „in agil“. Und das prinzipiell auch aus gutem Grund, denn die Vorteile agiler Vorgehensweisen haben sich in den letzten Jahren – bzw. Jahrzehnten – für eine ganze Reihe von Aufgabenstellungen bewährt.Aber … insbesondere in großen Konzernen und Organisationen ist manchmal eine bestimmte Arbeitsweise vorgeschrieben. Viele große Unternehmen besitzen ein Projektmanagementhandbuch („PM-Handbuch“), das Prozesse, Ergebnistypen, Rollen und Gremien verbindlich vorschreibt. Ohne einen ausgearbeiteten Projektplan mit Phasen, Phasenabschlüssen, fixem Releasetermin, Budgetplanung, Ressourcenplanung und vorab fertiggestelltem Lastenheft erhält man keine Freigabe für sein Projekt, egal wie „agil“ sich der direkt zuständige Auftraggeber sein Vorhaben möglicherweise vorstellt.Dazu kommt, dass nicht jedes (Entwickler-)Team für Scrum geeignet ist. Gerade in großen, gewachsenen Organisationen trifft man auch diejenigen Mitarbeiter, die ihr Leben lang nach klarer Vorgabe gearbeitet haben und das nicht ändern wollen oder können.Aber: Heißt das, dass in einer solchen Umgebung eine agile Vorgehensweise unmöglich ist? Dass man stets streng nach dem Wasserfallmodell arbeiten muss? <h2>Das Wasserfallmodell</h2>Das Wasserfallmodell ist – wie der Name schon sagt – eine modellhafte Darstellung eines möglichst gut <a href="https://de.wikipedia.org/wiki/Wasserfallmodell#-1" target="_blank">vorab geplanten Vorgehens</a> . Kernidee ist, dass das Vorhaben in aneinander angrenzende Phasen zerteilt wird, die in der strengen Auslegung stets vollständig durchlaufen werden müssen, bevor eine neue Phase begonnen wird. Häufig schreibt das PM-Handbuch vor, dass die Ergebnisse einer Phase einzeln von einem Lenkungsausschuss abgenommen werden müssen.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/QmXyjTFpRfSRnnuEF8tY"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/QmXyjTFpRfSRnnuEF8tY" alt="Das Wasserfallmodell" width="1024" height="382" /></a> Arbeitet ein Unternehmen nach Wasserfall, so muss die komplette Kaskade von Tätigkeiten für jede Phase vorab soweit ausgeplant sein, dass Aufwand, Kosten und Zeit klar sind, ebenso wie der Inhalt der zu leistenden Arbeitspakete. Und diese Gesamtplanung beauftragt der Auftraggeber zu den genannten Kosten bei Projektstart zur Ausführung.Tritt während des Projektverlaufs eine Situation ein, die mit dem Plan kollidiert, so muss dieser aufwändig geändert werden. Der neue Plan wird dem Auftraggeber in Form eines Change Request (CR) vorgelegt, damit dieser die geänderte Planung akzeptiert. (Ein solcher CR betrifft in der Regel Kosten und Dauer eines Projektes. Die inhaltlichen Anforderungen werden nur selten im Projektverlauf geändert.)Mehrere Iterationen oder frühe und kontinuierliche Produktivsetzung von Projektergebnissen sind im Wasserfallmodell nicht vorgesehen. Und das ist nun wirklich nicht agil. <h2>Was heißt denn eigentlich „agil“?</h2>In den letzten beiden Abschnitten haben wir viel von „agil“ geredet. Aber was ist das eigentlich?Gerade in großen Organisationen trifft man zuweilen auf die Haltung: „Ich mache Dailys und habe ein Kanban-Board an der Wand, also bin ich agil“. Und das ist – offen gesprochen – absoluter Quatsch. Ebenso wenig stimmt es, dass nur dasjenige Projekt agil ist, das nach Scrum arbeitet oder streng die WIP-Limits des Kanban-Boards im Auge behält.Was agil bedeutet, haben eine Reihe von Leuten im sogenannten <a href="http://agilemanifesto.org/iso/de/manifesto.html" target="_blank">„Agilen Manifest“</a> im Jahr 2001 festgehalten. Dabei geht es um Werte und Prinzipien und nicht um eine konkrete Vorgehensmethode.Hier noch einmal ein Blick auf die vier agilen Werte zur Erinnerung:Individuen und Interaktionen über Prozesse und Werkzeuge Funktionierende Software über umfassende Dokumentation Zusammenarbeit mit dem Kunden über Vertragsverhandlung Reagieren auf Veränderung über Befolgen eines PlansDie Werte auf der rechten Seite sind wichtig, in der agilen Denkweise sind diejenigen auf der linken Seite aber wichtiger und gehen im Konfliktfall vor. <h2>Widerspricht klassisches Projektmanagement den agilen Werten?</h2>Auf den ersten Blick sieht es so aus, als würde das Wasserfallmodell das genaue Gegenteil der agilen Werte fordern, nämlich stets diejenigen Werte auf der rechten Seite denjenigen der linken Seite vorzuziehen.Der Projekt- und Aktivitätenplan wird vorab aufgestellt und möglichst genau befolgt. Eine Änderung dieses Plans ist ein aufwändiges Unterfangen, das viele Dokumente, Zustimmungen und ein Einbeziehen des Lenkungsausschusses erfordert. Allein die dafür notwendigen Menschen innerhalb kurzer Zeit zu einem Termin zusammenzubringen, ist in manchen Unternehmen ein Ding der Unmöglichkeit.Eine Phase ist beendet, wenn die Phasenabnahme erfolgt ist, ein späteres Zurückkehren zu einer vorherigen Phase ist nicht vorgesehen.Wie kann man da agil sein? Wie kann man so auf Veränderungen reagieren?Doch, es geht!Zunächst einmal muss man wissen, dass kaum ein Wasserfallmodell in der Realität so idealtypisch abläuft, wie es im obigen Bild suggeriert wird. Normalerweise überlappen die Phasen einander.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Va1PuyHzQleE5dzsYouZ"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Va1PuyHzQleE5dzsYouZ" alt="Das Wasserfallmodell mit sich überlappenden Phasen" width="1024" height="400" /></a> Auch in anderer Hinsicht kann und darf man von der „Ideallinie“ abweichen. Und genau an diesen Stellen kann man ansetzen – wenn die Organisation und die Auftraggeber mitspielen. <h2>Was kann man wie justieren?</h2>Zunächst einmal sollte man frühzeitig bei der Planung die verlangten Phasen möglichst weit überlappen. Alle Beteiligte sollen sich von Anfang an daran gewöhnen, dass die Konzeptionsphase bis kurz vor Ende der Realisierung läuft, und dass der Test schon wenige Wochen nach Beginn der Konzeptionen startet.Der nächste Schritt besteht darin, die gewünschten Funktionen in möglichst unabhängige Einzel-Features zu schneiden. Mindestens ein ausführliches Lastenheft – auch „Fachliches Grobkonzept“genannt – besteht ja vor Beginn des Projektes, sonst könnte das Projekt nicht geplant werden. Also weiß ich, was sich der Auftraggeber alles an Funktionen, an Features wünscht.Diese Features werden dann nach folgenden Gesichtspunkten bewertet:<ul><li>Sind andere Features davon abhängig?</li><li>Wie wichtig ist das Feature für den Gesamterfolg?</li></ul>Fühlt sich jemand an Aufstellen und Priorisieren eines Product Backlogs erinnert? Das, was wir hier tun, ist sehr ähnlich. Allerdings rate ich davon ab, diese Featureliste „Product Backlog“ zu nennen. Begriffe erzeugen Realität, und wenn die Projektcontroller, die auf einem Wasserfallmodell bestehen, derartige Begriffe hören, könnten Alarmsignale angehen.Ist diese Vorarbeit getan, habe ich eine Liste von Features, die in eine Reihenfolge gebracht sind.Der nächste Schritt ist absolut entscheidend: Ich teile das gesamte Projekt in (mindestens) zwei Teile, jeweils mit einem Release am Ende.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PCZqeVh2RbSMDH7SnnRN"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PCZqeVh2RbSMDH7SnnRN" alt="Wasserfallmodell mit zwei Releases" width="1024" height="266" /></a> Was gibt mir die Erlaubnis, das Projekt so zu planen? Die Auftraggeber möchten in der Regel sehr schnell Resultate erzielen. Gleichzeitig möchten sie nicht auf die von ihnen anfangs aufgestellten Features verzichten. Aber beides muss nicht notwendigerweise zum gleichen Zeitpunkt passieren. Wenn ich geschickt argumentiere, kann ich die Auftraggeber von den Vorteilen mehrerer Releases überzeugen.Wie ich das Projekt aufteile, ist situationsabhängig. Vielleicht orientiere ich mich an den Features, teile sie in „Release 1.0“ und „Release 1.1“ (oder weitere) auf. Vielleicht teile ich auch den Aufwand oder die Zeit linear – z. B. zu 70 % bzw. 30 % – und ordne die Features danach zu. In jedem Fall muss dem Auftraggeber und dem Lenkungsausschuss bewusst werden, dass sie beim ersten Release nicht die komplette Funktionalität haben, diese aber in weiteren Releases bekommen werden.Insbesondere die Liste der Features, die im ersten Release vorgesehen sind, stimme ich intensiv mit den Auftraggebern ab. Gleichzeitig behalte ich im Hinterkopf, dass diese Liste nur ein „erster Aufschlag“ ist. Warum, das erkläre ich gleich.Sobald diese Vorarbeiten einvernehmlich geklärt und bestätigt sind, kann das Projekt starten und die Projektarbeit beginnen. Dabei werden die Features in der aktuell entschiedenen Reihenfolge bearbeitet.Jedes Feature durchläuft jetzt für sich genommen den Wasserfallprozess:<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/8tQgsQG6SIylQteFATPr"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/8tQgsQG6SIylQteFATPr" alt="Feature durchlaufen jedes für sich den Wasserfallprozess" width="1024" height="577" /></a> <h2>Anpassungen während der Projektlaufzeit</h2>Jetzt läuft also das Projekt. Das Team ist dabei, die einzelnen Features nacheinander (oder auch parallel) zu konzipieren, zu entwickeln und dem Komponententest zu unterziehen.Und auch wenn es diejenigen, die an Pläne glauben, nicht wahrhaben wollen: Es ist vorhersehbar, dass dabei etwas Unvorhersehbares geschieht.Zum Beispiel fällt bei der Entwicklung auf, dass die DV-Konzeption unvollständig gewesen ist oder verändert werden muss. Kein Problem. Da alle Phasen nahezu gleichzeitig laufen, kann ich mit einem einzelnen Feature jederzeit Schritte zurück machen.Nur führt das häufig zur nächsten Herausforderung:Ein Feature benötigt mehr Aufwand / Zeit als ursprünglich geplant!Das allererste Mittel, dieser Situation zu begegnen, ist Ruhe bewahren. Manchmal gleicht sich eine Aufwanderhöhung an einer Stelle durch Einsparungen an anderer Stelle aus. Vielleicht habe ich vorsorglich einen Aufwandspuffer eingebaut, aus dem sich das Projekt bedienen kann. Häufig genug reichen diese Maßnahmen aber nicht (mehr), und ich muss handeln.Im „normalen“ Wasserfall muss ich an dieser Stelle einen Change Request vorbereiten. In der angepassten Vorgehensweise habe ich noch andere Optionen.Als Grundsatz gilt: Jedes noch nicht begonnene Feature steht zur Disposition.Ich habe einige Handlungsmöglichkeiten, um auf die neuen Anforderungen zu reagieren:<ul><li>Ein Feature wird auf ein späteres Release verschoben. Ich muss nach jedem Release das Folgeprojekt sowieso neu bewerten. Es ist einfacher, einen gemeinsamen CR nach dem Release zu erstellen, als mehrfach während der Projektlaufzeit.</li><li>Features können in der Reihenfolge verändert werden. Manchmal löst das schon den Knoten, weil Abhängigkeiten, die ich vorher nicht gesehen habe, sichtbar werden.</li><li>Der Projektverlauf zeigt, dass einzelne geplante Features nicht unbedingt sinnvoll sind. Wir können dem Auftraggeber vorschlagen, als Kompensation unnötige Features wegzulassen. Erstaunlicherweise ist ein Auftraggeber bei einem laufenden Projekt häufig bereiter, über so etwas zu reden, als vor dem Start eines Projektes.</li></ul>In jedem Fall habe ich Handlungsspielraum, den ich nutzen kann.Häufig werden auch komplett neue Anforderungen an das Projekt gestellt. Und hier kann man mit einer angepassten Vorgehensweise richtig punkten.Ein „klassischer“ Projektleiter, der die agilen Werte nicht berücksichtigt, wird sich gegen eine solche neue Anforderung stets sperren. Das muss er oder sie sogar tun, denn schließlich gibt es ja einen vereinbarten Projektauftrag, den der Auftraggeber nicht einseitig ändern kann, und den der Projektleiter verteidigen muss.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1zFRAWv7Q2SZhhHHPYAh"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1zFRAWv7Q2SZhhHHPYAh" alt="Projektleiter weist neue Anforderung ab." width="1024" height="606" /></a> Die neue Anforderung ist aber möglicherweise gut und sinnvoll. Bleibt also wieder nur der CR? In unserem Szenario kann ich als Projektleiter jetzt für den Auftraggeber deutlich positiver reagieren. Ich nehme die neue Anforderung positiv zur Kenntnis, gemäß dem agilen Prinzip, Veränderungen zu begrüßen. Als Erstes bewerte ich sie zusammen mit dem Team.Und dann biete ich eines der bereits geplanten Features zum Streichen an. Natürlich kann ich als Projektleiter nicht einfach die Ausweitung des Scopes akzeptieren. Aber ein Tausch, bei dem die übrigen Parameter (Aufwand, Zeit) in etwa gewahrt bleiben, den kann ich akzeptieren.Wieder gilt der Grundsatz: Jedes, noch nicht begonnene Feature steht zur Disposition.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/7kdQW4JQSkiInT476sr9"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/7kdQW4JQSkiInT476sr9" alt="Agiler Projektleiter nimmt neue Features an" width="1024" height="484" /></a> <h2>Wir arbeiten agil</h2>Ein Projekt, das auf die oben beschriebene Weise geführt wird, wird beim Auftraggeber gut ankommen, denn er oder sie wird das Gefühl haben, Einfluss nehmen und das Projekt gestalten zu können. Und das, auch ohne jedes Mal einen CR ertragen zu müssen.Als Projektleiter hat man größere Freiheiten, um im Projektverlauf auf diejenigen Ereignisse zu reagieren, die mit deutlich größerer Häufigkeit auftreten, als es die Projektcontroller und die Damen und Herren des PM-Handbuches vermuten.Werfen wir noch einmal einen Blick auf die agilen Werte. Der Fokus des oben gesagten liegt dabei vor allem auf den Werten „Reagieren auf Veränderungen“ und „Zusammenarbeit mit dem Kunden“. Wie gezeigt kann man beide Werte auch in klassischer Vorgehensweise den Werten „Vertragsverhandlung“ und „Befolgen eines Plans“ vorziehen.Und wie steht es mit den anderen Werten und Prinzipien?Auch in einem klassischen Projekt sollten alle Projektmitarbeiter häufig – im besten Fall täglich – zusammenarbeiten. Besonders effektiv ist es, ein Projektteam an einem Ort zu konzentrieren, um miteinander zu kommunizieren, anstelle anonyme Konzepte „über den Zaun geworfen zu bekommen“ („Individuen und Interaktionen“ über „Prozesse und Werkzeuge“).Und automatisierte Tests helfen dabei, den Fokus auf „Funktionierende Software“ zu legen, anstelle auf „umfassende Dokumentation“.Sehr empfehlenswert ist es übrigens, einige weitere Methoden des agilen Werkzeugkastens zu adaptieren. Dazu gehören sicherlich das Daily Stand-up (IT und Fachbereich zusammen) und die Retrospektive (Retro), also das regelmäßige Zusammensitzen des gesamten Teams, um die Vorgehensweise zu hinterfragen. Eine solche Retro empfiehlt sich mindestens nach jedem Release (nennt sich dann üblicherweise „Lessons learned session“). Es hindert einen aber niemand daran, sich alle 2-3 Wochen mit dem Team zu treffen und die eigene Vorgehensweise zu reflektieren. <h2>Wo sind die Grenzen? Wie agil kann man werden?</h2>Das agile Manifest untermauert die vier oben genannten Werten mit einer Reihe von Prinzipien. Einige davon sind in einer klassischen Projektumgebung vergleichsweise schwierig umzusetzen. Dazu zählen insbesondere diejenigen Prinzipien, die auf eine frühe und regelmäßige Auslieferung von Software zielen. Klassische Organisationen erlauben Auslieferungen von Software häufig nur nach Durchlaufen eines komplexen Genehmigungsverfahrens, mit mehreren Stufen der Abnahme und Qualitätskontrolle. Einen solchen Prozess durchläuft man nur sehr ungern alle 2-3 Wochen.Trotzdem kann man auch hier sinnvolle Dinge tun:Um frühzeitig Rückmeldung von Anwendern zu bekommen, gibt es zum Beispiel die Methode des Rapid Prototyping, um (zumindest von ausgewählten Anwendern) frühzeitig eine Rückmeldung zu erhalten. <h2>Zusammenfassung: Es geht also doch</h2>Was zunächst wie ein Widerspruch ausgesehen hat, muss bei näherer Betrachtungsweise keiner sein. Es ist durchaus möglich, mit den Methoden des klassischen Projektmanagements die Werte und Prinzipien der agilen Softwareentwicklung zu verfolgen. Dazu ist es allerdings notwendig, dass Projektleiter und Auftraggeber einvernehmlich einige Vereinbarungen treffen.Das volle Potenzial von agilem Vorgehen wird man damit allerdings nicht erreichen können. Dafür muss eine Organisation bereit sein, die eigene Arbeitsweise zu verändern, mehr Transparenz zu wagen und mehr Kompetenzen von den Führungskräften auf die Mitarbeiter zu verlagern.Trotzdem kann man auch in einem klassischen Umfeld eine Arbeitsweise verfolgen, die willens und in der Lage ist, auf Veränderungen zu reagieren und nicht erst drei Jahre nach Projektstart (inklusive vier Change Requests) Software abzuliefern, die dann niemand (mehr) benötigt.Diese Ausrede gilt nicht mehr 😉

Agil trotz klassischen Projektmanagements?

<h2>Die Anwendung mit nur einer funktionalen Programmiersprache entwickeln</h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/GkXQVuLfQ2pYwSpbX1qz"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/GkXQVuLfQ2pYwSpbX1qz" alt="Cloud Native Illustration" width="973" height="423" /></a> F# ist eine großartige Sprache. Ich habe in meiner beruflichen Laufbahn eine Menge Programmiersprachen kennengelernt, aber selten war ich so begeistert wie von F#. Das liegt vor allem an dem funktionalen Paradigma, das diese Sprache unterstützt, sowie an der extrem schlanken Syntax. Aber nicht zuletzt auch daran, dass man damit endlich wieder Full Stack eine vollständige Anwendung mit nur einer Sprache und nur einem Paradigma entwickeln kann – und das auch noch funktional!Natürlich ist klar, dass das grundsätzlich auch mit JavaScript und Node.js funktioniert. Doch ich muss gestehen, dass ich JavaScript aus mehreren Gründen, die ich hier nicht ausbreiten möchte, nicht mag. Stattdessen halte ich den funktionalen Ansatz von F# und die (von ML und OCaml abgeleitete) Syntax für deutlich vielversprechender.<h2>Der Vorteil des funktionalen Paradigmas</h2>Der funktionale Programmierstil ist in vieler Munde und wird schon als möglicher nächster Paradigmenwechsel gehandelt (beispielsweise <a href="https://www.youtube.com/watch?v=6YbK8o9rZfI" target="_blank">hier</a> ). Gründe dafür gibt es viele. Unter anderem unterstützt diese Art der Programmierung folgende Konstrukte besonders gut:<ul><li>Unveränderliche Daten – kein shared state und keine side effects</li><li>Deklarativer Stil – Code, der zeigt, was man erreichen will und nicht, wie im Detail das erreicht wird.</li></ul>Beides sind Aspekte, die sowohl im Frontend als auch im Backend als wertvoll und zielführend eingeschätzt werden. Grund genug, sich mit funktionalen Sprache zu beschäftigen, die beides primär unterstützt.F# gehört zum .NET-Universum. Seit .NET-Core plattformunabhängig und open source ist, hat man keinen MS Windows lock-in mehr. Eine gute Einführung bekommt man auf <a href="http://fsharp.org" target="_blank">fsharp.org</a> . Wer noch mehr Gründe für die Sprache sucht, wird <a href="https://fsharpforfunandprofit.com/why-use-fsharp/" target="_blank">hier</a> fündig.<h2>Der SAFE-Stack</h2>Um eine vollständige Anwendung zu schreiben, braucht man allerdings noch ein paar zusätzliche Bibliotheken. Diese werden als „SAFE-Stack“ bezeichnet. Jeder Buchstabe steht dabei für ein Framework, bzw. eine Technologie:<table><tbody><tr><td><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/29XsaspCTouH7A0s5EBA" alt="Saturn Logo" width="250" height="30" /></td><td>Saturn → ein einfach zu entwickelndes REST- bzw. HTML-Backend</td></tr><tr><td><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/zFSLCCoHS4u1iUq08hAT" alt="Azure Logo" width="250" height="72" /></td><td>Azure → Integration in die Cloud-Dienste von Microsoft. Tatsächlich ist dieser „Buchstabe“ nicht besonders intensiv mit den anderen verknüpft. Ich werde ihn in diesem Tutorial nicht betrachten. Der „SAFE-Stack“ funktioniert auch mit AWS oder anderen Cloud-Anbietern – oder »on-Premise«.</td></tr><tr><td><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UgQtkcsYS2qrtC1mHSTn" alt="Fable Logo" width="250" height="185" /></td><td>Fable → auf Babel aufbauender Transpilier nach JavaScript inkl. HTML-Erzeugung und React-Anbindung</td></tr><tr><td><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/afo1KrAQOWIjiiwwbrgg" alt="Elmish Logo" width="220" height="220" /></td><td>ELMISH → Verwendung des Model-Update-View-Musters von Elm für F# im Frontend</td></tr></tbody></table>Die Bibliotheken des SAFE-Stack sind sehr umfangreich und mächtig. Man findet im Netz mehrere Templates und Tutorials (z. B. <a href="https://safe-stack.github.io/docs/learning/" target="_blank">hier</a> , <a href="https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/october/fsharp-safe-stack-functional-web-programming-for-net-core" target="_blank">hier</a> oder <a href="https://github.com/CompositionalIT/SAFE-Dojo" target="_blank">hier</a> ). Allerdings benutzen diese Tutorials häufig unterschiedliche zusätzliche Bibliotheken, sodass Code aus dem einen Beispiel in einem anderen nicht funktioniert und die eigentliche Struktur oftmals nicht klar wird.Für diese Artikelserie gehe ich daher von dem minimalen SAFE-Template aus und erkläre (fast) jede Zeile. Dadurch wird der Code vielleicht etwas (wirklich nur wenig!) umfangreicher als notwendig, aber ihr werdet sehen, dass trotzdem nicht viele Zeilen F#-Code notwendig sind, um eine funktionierende Anwendung zu erstellen.Weitere Bibliotheken könnt ihr dann gerne nach Belieben ergänzen.<h2>Das Tutorial</h2>In diesem und den folgenden vier Teilen werden wir eine (sehr) einfache To-do-Anwendung schreiben, also eine Anwendung, in der man Aufgaben anlegen und als erledigt markieren kann.Dazu werden wir iterativ vorgehen. In diesem Teil geht es um das Fundament mit einer noch sehr einfachen Funktionalität. Diese wird dann in den kommenden Teilen ergänzt und verfeinert.Ich gehe dabei davon aus, dass ihr bereits Grundkenntnisse in F# besitzt und <a href="https://dotnet.microsoft.com/download/dotnet-core/3.1" target="_blank">.NET Core 3.1</a> (oder neuer) installiert habt. Außerdem benötigt ihr noch <a href="https://nodejs.org/en/download/" target="_blank">Node.js</a> .<h2>Das SAFE Template</h2>Um unsere Anwendung zu schreiben, beginnen wir mit einem Template. Wir benutzen wie gesagt das minimale SAFE-Template, um das Beispiel einfach und verständlich zu halten.Zunächst müssen wir das SAFE-Template erst einmal auf unserem Rechner installieren:

```
dotnet new -i SAFE.Template
```

Als nächstes legt ihr ein Projektverzeichnis an, wechselt mit <code>cd</code> hinein und erzeugt hier eine Instanz des Templates:

```
dotnet new SAFE -m
```

(Das <code>-m</code>bedeutet, dass das minimale Template genutzt wird. Lasst ihr diesen Parameter weg, so wird die Anwendung deutlich umfangreicher, aber eben auch deutlich verwirrender und komplexer.)Der so erzeugte Verzeichnisbaum sieht auf der obersten Ebene wie eine Node.js-Anwendung aus, es gibt die üblichen Dateien und ein <code>src</code>-verzeichnis.Spannend sind allerdings die drei Unterverzeichnisse von <code>src</code>, die ihrerseits als .NET-Projekte (mit <code>.fsproj</code>-Datei) angelegt sind. In dem Client-Verzeichnis befinden sich außerdem noch eine HTML-Datei und ein Unterverzeichnis für statische Web-Inhalte (wie z. B.: HTML-Seiten, Bilder oder CSS-Files).Wenig überraschend enthält das Verzeichnis <code>Client</code> den Code für das Frontend und <code>Server</code> den für das Backend. Beide Projekte verweisen ihrerseits auf das Verzeichnis <code>Shared</code>, in dem Code abgelegt wird, der von beiden Teilen der Anwendung verwendet wird.Hier zeigt sich ein Vorteil, wenn man eine einheitliche Sprache und einheitliches Projekt benutzt: Es ist möglich, Funktionen nur einmal zu entwickeln und dann in beiden Teilen der Anwendung zu verwenden, wenn das erforderlich oder hilfreich ist.<h2>Starten</h2>Dieses Template ist bereits funktionsfähig und kann sehr einfach gestartet werden. Dazu braucht ihr zwei Terminal-Instanzen, die beide auf das Projektverzeichnis zeigen.Start des Servers:

```
cd src/Server
dotnet watch run
```

Damit startet der Server-Teil der Anwendung als echte .NET-Anwendung und zwar im Watch-Modus. Das bedeutet, dass die Anwendung bei jeder Änderung an einer Datei kompiliert und neu gestartet wird.Den Client startet man wie jede Node.js-Anwendung aus dem Hauptverzeichnis des Projektes mit einem einmaligen:

```
npm install
```

und anschließend mit:

```
npm run start
```

Das Template enthält eine Webpack-Konfiguration, die einen Development-Build der Anwendung erstellt. Auch hier wird bei jeder Änderung neu kompiliert und im Browser aktualisiert.Die bestehende Anwendung tut nichts anderes, als einen String aus dem Backend an das Frontend zu geben und dort anzuzeigen (http://localhost:8080). Wenig spannend, aber voll funktionsfähig.Ich schlage vor, dass ihr euch die drei Dateien<ul><li><code>Index.fs</code>(Hier steckt der Code für das Frontend)</li><li><code>Server.fs</code></li><li><code>Shared.fs</code></li></ul>einmal anschaut – der Code ist nicht besonders schwer zu verstehen.<h2>Erste Iteration</h2>Als nächstes bauen wir für die erste Iteration unsere Anwendung um. Den vollständigen Code findet ihr <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/01_Read-all-todos" target="_blank">hier</a> .<h3>Shared</h3>In dem geteilten Code bringen wir unsere Datenstruktur für die Todos unter, die sowohl im Backend als auch im Frontend verwendet wird, außerdem ändern wir den Pfad des Service, den wir anbieten möchten, und den Namen, unter dem wir ihn uns merken:

```
type Todo =
    {
        Id: int
        Description: string
 Completed: bool
 }

module Route =
 let todos = "/api/todos"

```

<h3>Server</h3>Vor der Definition der <code>webApp</code> fügen wir unsere „Datenbank“ ein:

```
let database = [
 {
 Id = 1
 Description = "Read all todos"
 Completed = true
 }
 {
 Id = 2
 Description = "Add a new todo"
 Completed = false
 }
]

```

Wir simulieren eine Datenbank durch eine einfache Liste von <code>Todo</code>s. Da wir in der ersten Iteration noch keine Veränderung an den Daten vornehmen möchten, reicht das. Wie üblich in F# brauchen wir keine Typ-Annotationen, da der Compiler durch die verwendeten Labels eindeutig den Typ <code>Todo</code> ableiten kann.Dann ändern wir noch die <code>webApp</code> selbst:

```
let webApp =
 router {
 get Route.todos (fun next ctx ->
 json database next ctx)
 }

```

Hier wird jetzt nicht mehr ein String sondern die zuvor definierte Datenstruktur zurückgegeben. Die zusätzlichen Parameter (<code>next</code> und <code>ctx</code>) wären nicht notwendig, ich habe es mir aber angewöhnt, sie immer mitzugeben, da so die Funktionen im router einheitlicher werden. In den nächsten Teilen werden wir mindestens <code>ctx</code> (= Context) brauchen.Natürlich hindert euch niemand daran, statt einem Lambda auch eine echte Funktion zu erstellen und diese an <code>get</code> zu übergeben.<h3>Client (aka Index.fs)</h3>Jetzt passen wir noch den Client an. Hier müssen wir etwas mehr umbauen, das führt aber am Ende auch nicht zu deutlich mehr Code. Wir strukturieren nur etwas um, um für spätere Erweiterungen einheitlicher zu sein, wie ihr in den nächsten Folgen sehen werdet.Grundsätzlich arbeitet das Elmish-Framework mit einem Model, dessen initialem Zustand, verschiedenen Transformationen aufgrund von Ereignissen (Commands) sowie dem eigentlichen Erstellen der View.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aJpxkUtdQ1i9Puh9zGab"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aJpxkUtdQ1i9Puh9zGab" alt="Model Update View Illustration" width="488" height="716" /></a>  (Quelle: https://safe-stack.github.io/docs/component-elmish/)Im Einzelnen:Das Model des Frontend soll eine Liste von <code>Todo</code>s sowie eine mögliche Fehlermeldung enthalten.

```
type Model =
 {
 Todos: Todo list
 Error: string
 }

```

Wir brauchen drei anstelle von einer Message, um die Anwendung später einheitlich erweitern zu können.

```
type Msg =
 | Load
 | Refresh of Todo list
 | Error of exn

```

Dabei ist <code>Load</code> die Message, die anweist, die Daten asynchron vom Server zu laden. <code>Refresh</code> wird im Erfolgsfall und <code>Error</code> im Fehlerfall benutzt.Das Model wird mit einer leeren Liste und einer Fehlermeldung gefüllt. Außerdem geben wir eine initiale Message an, und zwar die zum Laden der <code>Todo</code>-Liste, wie gerade eben definiert.

```
let init() =
 { Todos = []; Error = "" }, Cmd.ofMsg Load

```

In der Update-Methode unterscheiden wir unsere drei Messages.

```
let update msg model =
 match msg with
 | Load ->
 let loadTodos() = Fetch.get<unit, Todo list> Route.todos
 let cmd = Cmd.OfPromise.either loadTodos () Refresh Error
 model, cmd
 | Refresh todos ->
 { model with Todos = todos}, Cmd.none
 | Error err ->
 { model with Error = err.Message }, Cmd.none

```

<code>Load</code> erzeugt über <code>Fetch.get</code> einen Promise, der dann zum Erzeugen eines Kommandos als Container für eine Message benutzt wird. Was hier genau geschieht und was es mit diesem <code>Cmd</code> auf sich hat, werde ich im nächsten Teil der Serie erklären, sonst wird dieser Post zu lang.Der restliche Code sollte klar sein: Auf Basis des aktuellen <code>model</code> wird ein neues, geändertes <code>model</code> zurückgegeben. Das Framework kümmert sich darum, den Anwendungs-State zu aktualisieren. Der letzte Schritt ist das Neuzeichnen des UI.Das geschieht in der Funktion <code>view</code>:

```
let view model dispatch =
 div [ Style [ TextAlign TextAlignOptions.Center; Padding 40 ] ] [
 div [] [
 img [ Src "favicon.png" ]
 h1 [] [ str (sprintf "Todos: %i" model.Todos.Length) ]
 match model.Error with
 | "" -> div [] []
 | s -> p [ ] [ str s ]
 div [] ( model.Todos
 |> List.map (fun each -> p [] [str each.Description]))
 ]
 ]

```

Dieser Code verwendet das Builder-Pattern, um deklarativ HTML-Elemente zu erzeugen. Jedes Elemente erhält zwei Listen als Parameter. Die erste steht für Stil- oder CSS-Attribute und etwaige Event-Listener. Die zweite enthält Kind-Elemente. Kann ein Element keine Kind-Elemente aufnehmen, so nimmt es nur eine Liste.<h3>That’s it</h3>Mit diesen wenigen Änderungen haben wir die erste Iteration unserer Anwendung erreicht. Jetzt zeigt die Anwendung die oben definierten Todos an. Sollte der Server nicht gestartet sein, so zeigt das Frontend eine Fehlermeldung, arbeitet aber ansonsten problemlos weiter.Wichtig: Obwohl wir im gesamten Code keine einzige Typ-Deklaration verwendet haben, ist der Code statisch typisiert. Der Compiler nutzt sehr leistungsfähige type inference, sodass zur Entwicklungszeit Syntaxfehler leicht gefunden werden können. Außerdem benutzt eine geeignete IDE diese Informationen zur Code-Completion. Für Visual Studio Code gibt es mit Ionide das geeignete Plugin für F#.<h2>Zusammenfassung</h2>Wir haben mithilfe des SAFE-Templates mit wenigen Handgriffen eine Web-Anwendung mit nur einer Sprache in einem Projekt erstellt.Der von uns geschriebene Code ist rein funktional und benutzt im Frontend und Backend dieselben sprachlichen Paradigmen und Muster. Gefühlt gibt es keine Trennung mehr zwischen Frontend und Backend – bis auf die Kommunikation über REST.Auf dem Server verwenden wir Saturn (z. B. die Funktion <code>router</code> aus <code>Server.fs</code>), um sehr einfach einen HTTP-Service bauen zu können.Auf dem Client unterstützt uns Elmish mit seinem model-update-view-Pattern, während wir von Fable die Übersetzung nach JavaScript und auch die HTML-Erzeugung erhalten.Die Anwendung ist bislang noch nicht besonders komplex, aber sie ist eine gute Plattform, um in den nächsten Folgen aufbauen zu können.Stay tuned …Hier geht’s zum <a href="/wissens-hub/blog/tutorial-safe-stack-teil-2" target="_blank">zweiten Teil</a> der Reihe.

Tutorial: F# mit SAFE-Stack – Teil 1x

<h2>Eine Anwendung mit nur einer (funktionalen) Programmiersprache entwickeln</h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aGDB4r3Tx3kV8ApffdnQ"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aGDB4r3Tx3kV8ApffdnQ" alt="Spielsteine und Hände" width="1024" height="443" /></a> (https://unsplash.com/photos/rMm0dChKUaI)Willkommen zurück!Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-1">ersten Teil</a> der Serie haben wir unser Grundgerüst für eine einfache To-do-Anwendung gebaut. Der Code der Anwendung findet sich dabei im Wesentlichen in drei Dateien, eine für das Frontend, eine für das Backend und eine, die in beiden Schichten benutzt wird.Der Code ist vollständig in F# geschrieben und benutzt die Bibliotheken des SAFE-Stacks, insbesondere:<ul><li>Giraffe (für die Bearbeitung von HTTP-Requests)</li><li>Fable (für den F# nach Javascript-Transpiler und die React-UI-Elemente)</li><li>Elmish (für das Model-Update-View-Pattern)</li></ul>Bisher kann die Anwendung nur eine fixe Liste von To-dos, die im Backend initialisiert sind, in der GUI anzeigen. Heute erweitern wir sie um eine wichtige neue Funktionalität:Wir wollen neue Aufgaben hinzufügen können.Den Stand des Codes vom letzten Teil findet ihr <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/01_Read-all-todos" target="_blank">hier</a> .Den vollständigen Code von heute findet ihr <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/02_Add-todo" target="_blank">hier</a> .Steigen wir direkt ein. Los geht’s diesmal mit dem Frontend:<h2>Index.fs</h2>Um eine neue Aufgabe hinzuzufügen, verwenden wir eine Eingabezeile und einen Button. In der Eingabezeile gibt der Benutzer an, um welche Aufgabe es geht und der Button legt das To-do an.Da im Model-Update-View-Pattern der vollständige Zustand einer Anwendung im Model hinterlegt ist, müssen wir die Datenstruktur für das Model zunächst um ein Attribut für den Inhalt der Eingabezeile erweitern:

```
type Model =
 {
 Todos: Todo list
 Error: string
 Description: string // <- das hier ist neu 
 }

```

Des weiteren benötigen wir zwei neue Messages: Eine, wenn der Inhalt des Eingabefeldes geändert wird, und die andere, um das neue To-do anzulegen:

```
type Msg =

 ... // die bisherigen Messages

 | DescriptionChanged of string
 | AddTodo

```

Jetzt dürfen wir nicht vergessen, in der <code>Init</code>-Funktion auch die <code>Description</code> auf einen leeren String zu setzen (der Compiler meckert bereits, dass da etwas fehlen würde!).

```
let init() =
 { Todos = []; Error = ""; Description = "" }, Cmd.ofMsg Load

```

Soweit so einfach. Allerdings meckert der Compiler immer noch, und zwar darüber, dass der <code>match</code>-Ausdruck in der Funktion <code>update</code> nicht vollständig sei – womit er völlig recht hat. Ergänzen wir also den Code für die Behandlung der beiden fehlenden Messages:

```
let update msg model =
 match msg with

 ... // die bisherigen Messages

 | DescriptionChanged s ->
 { model with Description = s}, Cmd.none
 | AddTodo ->
 let newTodo description = Fetch.post<string, Todo list> (Route.todos, description)
 let cmd = Cmd.OfPromise.either newTodo model.Description Refresh Error
 { model with Description = "" } , cmd

```

Die Behandlung für <code>DescriptionChanged</code> ist vermutlich selbsterklärend, der neue Text wird in das Model eingefügt.Spannender ist <code>AddTodo</code>. Und an dieser Stelle möchte ich euch wie versprochen die merkwürdige Konstruktion mit dem <code>Fetch</code> und dem <code>Cmd</code> erklären.<code>Cmd</code> ist der Name einer Datenstruktur, die eine Message hält, also ein Container für eine Message.<code>Cmd</code>-Container werden an zwei Stellen verwendet:<ol><li>In der <code>init</code>-Funktion</li><li>In der <code>update</code>-Funktion</li></ol>In beiden Fällen wird ein Tupel aus dem neuen Model und einem <code>Cmd</code> zurückgegeben.Wozu benötigen wir das? Können wir nicht einfach eine Message zurückgeben?Nein, können wir nicht. Denn in F# gibt es keinen <code>null</code>-Ausdruck, also können wir nicht einfach keine Message zurückgeben. Wir benötigen schon allein daher einen Container.Es gibt aber noch einen zweiten Grund, und den sehen wir hier in der Behandlung von <code>AddTodo</code> – ebenso, wie bei <code>Load</code> aus dem ersten Teil:

```
 | Load ->
 let loadTodos() = Fetch.get<unit, Todo list> Route.todos
 let cmd = Cmd.OfPromise.either loadTodos () Refresh Error
 model, cmd

```

Die Kommunikation mit dem Backend erfolgt nämlich asynchron über einen Promise.<code>Fetch</code> stammt aus der Bibliothek Thoth, die ebenfalls Teil des SAFE-Stacks ist. <code>Fetch.get</code> bzw. <code>Fetch.post</code> rufen dabei nicht direkt das Backend auf, sondern erzeugen einen Promise.Hierbei müssen wir übrigens den Typ für den Parameter zum Backend und dem Rückgabewert angeben, den kann der Compiler wirklich nicht ermitteln. Der GET-Aufruf hat wie bei einem GET üblich keinen Body, daher geben wir als ersten Typ <code>unit</code> an. Der GET liefert eine Liste von To-dos zurück, die wir als zweiten Typ angeben:

```
Fetch.get<unit, Todo list> Route.todos

```

Der POST-Aufruf sieht ähnlich aus. Hier geben wir auch Daten an das Backend, nämlich den <code>string</code> mit der Beschreibung des neuen <code>Todo</code>s. Als Rückgabe erwarten wir wieder eine Liste von <code>Todo</code>s:

```
Fetch.post<string, Todo list> (Route.todos, description)

```

(Die Klammern sind wichtig, da alle Parameter als ein Tupel an <code>Fetch.get</code> bzw. <code>post</code> übergeben werden und nicht als einzelne Parameter.Verwendet wird das Ganze als Parameter für <code>Cmd.OfPromise.either</code>. Schauen wir uns den Aufruf einmal im Beispiel unseres POST-Requests an:

```
Cmd.OfPromise.either newTodo model.Description Refresh Error

```

Die Funktion <code>either</code> nimmt vier Parameter:<ol><li>Den Bezeichner einer Funktion, die einen Promise zurück liefert (in unserem Fall die Funktion <code>newTodo</code>). Wichtig: Hier wird nicht der Promise selbst übergeben.</li><li>Der Parameter, der an die Funktion aus 1. übergeben werden soll. In unserem Fall die <code>Description</code> aus dem Model. Bei dem GET-Request steht dort <code>()</code>, also nix.</li><li>Eine Message, die verwendet werden soll, wenn der Promise fertig ist. Die Message muss dabei genau den Datentyp aufnehmen können, die auch das Ergebnis des Promises ist (hier: <code>Todo list</code>).</li><li>Eine Message, die verwendet werden soll, wenn bei der Bearbeitung des Promises ein Fehler auftritt. Der Parameter dieser Message ist vom Typ <code>exn</code> (eine Abkürzung für <code>System.Exception</code>).</li></ol>Schaut euch den Aufruf des GET an. Ist jetzt klar, warum zwischen <code>loadTodos</code> und <code>()</code> definitiv ein Leerzeichen stehen muss?Der so erstellte <code>Cmd</code> ist (neben einem unveränderten Model) der Rückgabewert dieser Funktion. Das Elmish-Framework erzeugt dann den Promise, führt ihn aus und erzeugt je nach Ergebnis asynchron eine der beiden Messages.<h3>Anpassung der UI</h3>Als letztes müssen wir die <code>view</code>-Funktion anpassen. Um diese nicht unendlich groß werden zu lassen, teilen wir sie in einzelne Funktionen auf, die man als Komponenten bezeichnen könnte – zumindest um die UI einer Komponente.Die eigentliche <code>view</code>-Funktion kann dadurch recht kurz werden:

```
let view model dispatch =
 div [ Style [ TextAlign TextAlignOptions.Center; Padding 40 ] ] [
 div [] [
 img [ Src "favicon.png" ]
 h1 [] [ str (sprintf "Todos: %i" model.Todos.Length) ]
 
 descriptionView model dispatch
 errorView model
 todosView model dispatch 
 ]
 ]

```

Neben dem Header werden drei weitere Funktionen aufgerufen (die natürlich vor dieser Funktion im Code stehen müssen, da der F#-Compiler nur von vorne nach hinten liest).Hier gibt es die neue Eingabezeile:

```
let descriptionView model dispatch =
 div [] [
 input [
 Placeholder "What is to be done?"
 Value (model.Description)
 OnChange (fun ev -> !!ev.target?value |> DescriptionChanged |> dispatch)
 ]
 button [
 OnClick (fun _ -> AddTodo |> dispatch)
 ] [ str "Add" ]
 ]

```

Interessant ist das <code>OnChange</code>-Property. Dieses erhält als Parameter eine Funktion mit dem Event als Parameter. Mit der Konstruktion <code>!!ev.target?value</code> können wir auf den Inhalt des Textfeldes, das das Event ausgelöst hat, zugreifen. Damit das geht müsst ihr vorher noch ein weiteres Fable-Modul einbinden:

```
open Fable.Core.JsInterop

```

Mit <code>!!</code> greifen wir dann auf JavaScript-Objekte zu, und mit <code>?</code> auf Elemente eines JS-Objektes, natürlich ohne jede Typ-Prüfung (also: aufpassen!). Wir erhalten damit den Inhalt des Textfeldes und geben diesen an eine Message weiter.Die ganze Zeile:

```
!!ev.target?value |> DescriptionChanged |> dispatch

```

Ist dabei eine – wie ich finde – elegante Schreibweise für:

```
dispatch (DescriptionChanged (!!ev.target?value))
```

Das funktioniert auch, aber ich bevorzuge die Pipeline-Darstellung, da sie sich einfacher von vorne nach hinten lesen lässt:<ol><li>Nimm den Value aus der Komponente des Events,</li><li>packe ihn in eine <code>DescriptionChanged</code>-Message</li><li>und gibt diese als Parameter an die <code>dispatch</code>-Funktion.</li></ol><code>dispatch</code> ist – wenig überraschend – die Funktion, die eine Message aufnimmt und diese im nächsten Zyklus an die <code>update</code>-Funktion reicht. Hier benötigen wir keinen <code>Cmd</code>-Container, da wir ja stets eine Message an <code>dispatch</code> übergeben können – ansonsten würden wir es halt nicht aufrufen.Den Inhalt der anderen beiden Funktionen kennen wir schon, er stand vorher genauso in der <code>view</code>-Funktion.

```
let errorView model =
 match model.Error with
 | "" -> div [] []
 | s -> p [ ] [ str s ]

let todosView model dispatch =
 div [] ( model.Todos |> List.map (fun each ->
 p [ ] [str each.Description]))

```

Damit ist unser Frontend fertig.<h2>Server.fs</h2>Ab jetzt darf unsere Pseudo-»Datenbank« nicht mehr unveränderlich sein. Wir werden Funktionen benötigen, die deren Inhalt manipulieren. Zur besseren Übersicht packen wir die komplette Funktionalität in ein eigenes Modul mit dem Namen <code>Database</code>:

```
module Database =

 let mutable private database: Todo list = []

```

Das Schlüsselword mutable weist F# an, dass der Inhalt von <code>database</code> geändert werden kann.Wichtig! Dadurch wird nicht die Liste selbst änderbar, diese bleibt read only. Aber ich kann die eine Liste durch eine andere ersetzen und wieder in <code>database</code> ablegen.Initial ist <code>database</code> jetzt also eine leere Liste. Um trotzdem mit etwas starten zu können, schreiben wir eine Initialisierungs-Funktion:

```
 let init() =
 database <- [
 {
 Id = 1
 Description = "Read all todos"
 Completed = true
 }
 {
 Id = 2
 Description = "Add a new todo"
 Completed = true
 }
 {
 Id = 3
 Description = "Toggle State"
 Completed = false
 }
 ]

```

Damit niemand direkt auf <code>database</code> zugreift (wir haben es ja extra mit <code>private</code> gekennzeichnet), brauchen wir Zugriffsfunktionen, dabei insbesondere eine, die direkt nach <code>Id</code> sortiert.

```
 let getAll () =
 database

 let getAllSorted () =
 database |> List.sortBy (fun each -> each.Id)

```

Als letztes benötigen wir noch eine Funktion, um die »Datenbank« auf einen neuen Stand zu bringen:

```
 let save model =
 database <- model

```

Dabei steht <code><-</code> für die Zuweisung an einen <code>mutable</code> Bezeichner (wie auch schon in der <code>init</code>-Funktion). Die Syntax sieht hier extra ein sehr besonderes Zeichen vor, zusammen mit dem Schlüsselwort <code>mutable</code>, damit niemand leichtfertig so etwas macht. Eine bestehende Zuweisung zu ändern bricht nämlich mit dem funktionalen Paradigma. In dieser Beispiel-Anwendung können wir das machen, grundsätzlich solltet ihr so etwas, wenn es irgendwie geht, vermeiden.Als letztes rufen wir noch die <code>init</code>-Funktion auf, damit unsere Datenbank auch gefüllt ist. Dieser Code wird ausgeführt, sobald das Modul <code>Database</code> geladen und initialisiert wird.

```
 do init()

```

Wichtig! Alle diese Funktionen müssen eingerückt werden, damit sie zu dem oben deklarierten Modul gehören.<h3>Business Logik</h3>Jetzt brauchen wir noch die Business Logik unserer Anwendung. Diese ist in unserem Beispiel sehr überschaubar, denn unser Backend kann lediglich ein neues To-do anlegen.Auch diese Logik kapseln wir in einem eigenen Modul. (Ihr könnt beide Module auch gerne in eigene Dateien auslagern, ich habe mir das gespart):

```
module Todos =

 let newId model =
 model
 |> List.map (fun each -> each.Id)
 |> List.max
 |> (+) 1

 let addTodo model description =
 let id = newId model
 let newTodo = { Description = description; Completed = false; Id = id }
 newTodo :: model

```

Die erste Funktion (<code>newId</code>) ermittelt eine neue, eindeutige <code>Id</code> für ein neues <code>Todo</code>. Wieder einmal fällt die elegante-Pipeline-Syntax auf:<ol><li>Nimm das Model,</li><li>hole von jedem die <code>Id</code>,</li><li>ermittle davon den größten Wert</li><li>und erhöhe ihn um 1</li></ol>Dagegen sieht <code>addTodo</code> schon fast langweilig normal aus. Übrigens hängen wir das neue To-do vorne an, was für unveränderliche Listen der empfohlene, weil performanteste Weg ist.So, wir sind fast fertig. Wir müssen nur noch unseren <code>router</code> ergänzen, damit er den POST-Request auch verarbeiten kann.

```
let webApp =
 router {

 ... // die bisherige Behandlung des GET-Requests

 post Route.todos (fun next ctx -> 
 task {
 let! description = ctx.BindModelAsync<string>()
 let model = Todos.addTodo (Database.getAll()) description
 Database.save model
 return! json (Database.getAllSorted()) next ctx
 })
 }

```

<div>Ich hatte euch versprochen, dass wir diesmal wenigstens den Parameter <code>ctx</code> benötigen werden: Damit greifen wir auf den Body des Requests zu. Auch das geschieht asynchron und muss daher in einem <code>task</code> gekapselt werden. Damit Tasks genutzt werden können, benötigen wir Zugriff auf das entsprechende Modul:

```
open FSharp.Control.Tasks.V2.ContextInsensitive

```

Die Ausrufezeichen (<code>!</code>) bei let und return sind dafür da, um auf das Ergebnis der asynchronen Verarbeitung zu warten, bzw. um uns wieder mit der Umwelt zu synchronisieren.Beim Zugriff auf den Body des POST-Requests müssen wir angeben, welchen Datentypen wir erwarten, in diesem Fall <code>&lt;string&gt;</code>.Damit die neu hinzugefügte Aufgabe im Frontend nicht als erstes Element auftaucht, liefern wir die Liste nach <code>Id</code>s aufsteigend sortiert zurück.Wir hätten natürlich auch im Frontend sortieren können. Vielleicht wäre es sinnvoll, solche Funktion in <code>Shared</code> zu platzieren, dann hätten sowohl Front- als auch Backend darauf Zugriff.<h2>Shared.fs</h2>Nix zu tun. Wir verwenden weiterhin denselben Pfad, nur diesmal mit POST und nicht mit GET.<h2>That’s it</h2>Die neue Anwendung verfügt jetzt über die erwähnte Eingabezeile. Wenn eine neue Aufgabe erstellt wird, wird diese zu der Liste der Anwendungen hinzugefügt und die Eingabezeile wieder geleert.<h2>Zusammenfassung</h2>Diesmal haben wir asynchrone Verarbeitung im Frontend mit Hilfe von Promises kennengelernt. Außerdem haben wir die <code>dispatch</code>-Funktion zum erstellen von Messages aufgrund von Benutzereingaben benutzt, sowie unser Frontend in kleinere »Komponenten« aufgeteilt.Tatsächlich kennen wir im Frontend jetzt so ziemlich alles, was man wissen muss, um die Funktionalität eines User Interface zu programmieren.Im Backend haben wir Business Logik eingefügt und eine Pseudo-Datenbank erzeugt.Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-3" target="_blank">nächsten Teil</a> der Serie werden wir bestehende To-dos verändern, wir wollen sie nämlich als erledigt kennzeichnen können.Stay tuned …</div>

Tutorial: F# mit SAFE-Stack – Teil 2

<h2>Eine Anwendung mit nur einer (funktionalen) Programmiersprache entwickeln</h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Q0nva1wZRDamuuNz2kUS"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Q0nva1wZRDamuuNz2kUS" alt="SAFE-Stack: Checkliste, teilweise abgehakt" width="1024" height="412" /></a> (https://unsplash.com/photos/RLw-UC03Gwc)Willkommen zurück zum dritten Teil der Serie.Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-1">ersten Teil</a> der Serie haben wir das Grundgerüst für eine einfache To-do-Anwendung gebaut, die zunächst nur eine feste Liste von Todos anzeigen konnte. Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-2">zweiten Teil</a> haben wir sie dann erweitert, um neue To-dos hinzufügen zu können.Die Anwendung ist vollständig in F# geschrieben und benutzt die Bibliotheken des SAFE-Stacks, insbesondere:<ul><li>Giraffe (für die Bearbeitung von HTTP-Requests)</li><li>Fable (F# nach Javascript und React-UI-Elemente)</li><li>Elmish (für das Model-Update-View-Pattern)</li></ul>In diesem Teil fügen wir der Anwendung eine neue, wichtige Funktion hinzu:Wir wollen Aufgaben als erledigt markieren können.Dazu soll das Backend einen neuen Service-Call anbieten und das Frontend diesen nutzen. Außerdem soll der Status einer Aufgabe angezeigt werden, sodass der Anwender diesen auch ändern kann.Den Stand des Codes vom letzten Teil findet ihr <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/02_Add-todo" target="_blank">hier</a> .Den vollständigen Code von heute findet ihr <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/03_Toggle-completed" target="_blank">hier</a> .Los geht’s wieder einmal mit dem Frontend:<h2>Index.fs</h2>Wenn wir eine neue Funktionalität zur Verfügung stellen wollen, müssen wir wie immer dafür auch (mindestens) eine neue Message anbieten:

```
type Msg =

 ... // die bisherigen Messages

 | ToggleCompleted of int

```

Der Parameter soll die <code>Id</code> des <code>Todo</code>s aufnehmen.Das Model kann unverändert bleiben, ebenso die <code>init</code>-Funktion.Aber natürlich brauchen wir für die neue Message eine Behandlung in der <code>update</code>-Funktion (der Compiler meckert auch schon):

```
let update msg model =
 match msg with

 ... // die bisherigen Messages

 | ToggleCompleted id ->
 let url = sprintf "/api/todos/%i/toggle_complete" id
 let newModel id = Fetch.patch<unit, Todo list> url
 let cmd = Cmd.OfPromise.either newModel () Refresh Error
 model, cmd

```

Im Backend werden wir gleich einen Service-Call anbieten, mit dem das »erledigt«-Flag eines <code>Todo</code>s umgeschaltet wird. Dazu nutzen wir einen Endpunkt »unterhalb« von <code>/api/todos</code>, der die <code>Id</code> des zu ändernden <code>Todo</code>s in der URL erwartet. Da wir ein bestehendes Datenobjekt ändern, verwenden wir das HTTP-Verb PATCH.Als Erstes erzeugen wir einen URL-String mit der <code>Id</code> darin. Der Rest des Codes sieht ziemlich genauso aus wie die anderen Calls zum Backend.Wir gehen davon aus, dass auch dieser Aufruf die neue, komplette Liste von <code>Todo</code>s zurückliefert, wie das schon bei <code>AddTodo</code> der Fall ist.<h2>User Interface</h2>Da die Darstellung eines einzelnen <code>Todo</code>s jetzt umfangreicher wird, lagern wir sie in eine eigene Funktion aus:

```
let todoView todo dispatch =
 div [] [
 input [
 Type "checkbox"
 Checked todo.Completed
 OnClick (fun _ -> todo.Id |> ToggleCompleted |> dispatch)
 ]
 label [ ] [str todo.Description]
 ]

```

Falls ihr diesen Code selbst tippt, werdet ihr zwischendurch möglicherweise Fehlermeldungen bekommen. Insbesondere, solange diese Zeile noch nicht da ist:

```
 Checked todo.Completed

```

Solange der Compiler nämlich nur sieht, dass wir von der Variablen <code>todo</code> die Eigenschaft <code>Description</code> nutzen (vorletzte Zeile), kann die type inference den Typ von <code>todo</code> nicht eindeutig erkennen. Das liegt daran, dass auch im Typentyp <code>Model</code> eine Eigenschaft <code>Description</code> definiert ist – was offensichtlich eine schlechte Wahl gewesen ist. Zum Glück ermöglicht es die Verwendung der Eigenschaft <code>Completed</code>, eindeutig den Typ von <code>todo</code> zu ermitteln. Andernfalls müsste man diesen Parameter typisieren (<code>(todo: Todo)</code>).Ansonsten denke ich, dass der Code klar ist: Ein <code>todo</code> wird durch eine Checkbox und einen Text repräsentiert. Und an der Checkbox hängt ein <code>OnClick</code>-Handler, der die neue Message auslöst.Die bereits bestehende Funktion <code>todosView</code> müssen wir natürlich noch umbauen, damit die neue Funktion zum Zeichnen eines To-dos auch aufgerufen wird:

```
let todosView model dispatch =
 div [] ( model.Todos |> List.map (fun each ->
 todoView each dispatch))

```

Das war’s auch schon im Frontend. Werfen wir einen Blick ins Backend:<h2>Server.fs</h2>Unser Modul <code>Database</code> kann unverändert bleiben. Im Modul <code>Todos</code> benötigen wir allerdings eine Funktion, um das <code>Completed</code>-Flag eines Eintrags zu ändern.Auf den ersten Blick erscheint die Implementierung dieser Funktion unnötig kompliziert. Allerdings arbeiten wir bei funktionaler Programmierung mit unveränderlichen Datentypen, d. h. eine Funktion, die aus der bestehenden Liste einen Eintrag ändert, kann es nicht geben.Stattdessen müssen wir die Liste kopieren und dabei den einen Eintrag mit dem bestehenden aus Vorlage neu erzeugen.

```
module Todos =

 ... // die bisherigen Funktionen

 let toggleComplete model id =
 let toggle todo =
 if id <> todo.Id then todo
 else { todo with Completed = not todo.Completed}
 model |> List.map toggle

```

Wir erstellen dafür eine eingebettete Funktion <code>toggle</code>, die ein <code>todo</code> auf die richtige <code>Id</code> prüft. Stimmt die <code>Id</code>, so wird ein neues <code>todo</code> zurückgegeben, als Kopie mit verändertem <code>Completed</code> Status. Im anderen Fall wird das übergebene <code>todo</code> unverändert zurückgegeben.Diese Funktion verwenden wir dann in der <code>List.map</code>-Funktion.Das Ergebnis ist eine neue Aufgabenliste, die wir dann an das Modul <code>Database</code> übergeben können. Das tun wir im <code>router</code>, wo alle HTTP-Requests ankommen:

```
let webApp =
 router {

 ... // die bisherigen Funktionen

 patchf "/api/todos/%i/toggle_complete" (fun id next ctx ->
 let model = Todos.toggleComplete (Database.getAll()) id
 Database.save model
 json (Database.getAllSorted()) next ctx
 )

```

Ich denke, der Code ist im Wesentlichen klar: Wir rufen die neue Funktion auf, geben das neue <code>model</code> an <code>Database.save</code> und liefern wie immer eine sortierte Liste zurück.Neu ist der Parameter in der URL. Parallel zu den »normalen« HTTP-Verben (<code>get</code>, <code>post</code>, <code>put</code>, <code>patch</code> …), die einen festen String als URL nehmen, gibt es jeweils ein formatierte Variante (<code>getf</code>, <code>postf</code>, <code>putf</code>, <code>patchf</code> …), in deren URL-String Parameter enthalten sein können. Die Formatierungsregeln entsprechen denen bei <code>printf</code> oder <code>sprintf</code>. Alle diese Parameter werden vorne an die Parameterliste angefügt (also vor <code>next</code> und <code>ctx</code>).Falls ihr euch fragt, warum wir den String <code>"/api/todos/%i/toggle_complete"</code> nicht – wie die andere URL auch – in <code>Shared.fs</code> abgelegt haben: Das geht leider nicht so einfach.Sowohl <code>sprintf</code> als auch <code>patchf</code> erwarten keinen <code>string</code>, sondern einen typisierten Parameter, in dessen Signatur enthalten ist, welcher Variablentyp als Platzhalter erwartet wird (z. B. <code>%i</code> für eine Ganzzahl). Der Compiler kann das erkennen und aus dem Zeichenketten-Literal im Code den richtigen Typ ableiten. Das funktioniert aber nicht mehr, wenn die Zeichenkette einfach an eine Variable gebunden wird. In diesem Fall leitet der Compiler einfach den Typ <code>string</code> ab – was dann in der Verwendung bei <code>sprintf</code> und <code>patchf</code> zu einem Fehler führt.Daher bleibt uns hier nur die Möglichkeit, diesen Formatstring direkt an dieser Stelle im Code zu hinterlegen. Was leider die Nützlichkeit des Moduls <code>Route</code> in <code>Shared.fs</code> deutlich einschränkt.So, damit ist der Code fertig und lauffähig. Probiert es gerne einmal aus.<h2>Zusammenfassung</h2>In diesem – zugegebenermaßen kürzeren – Teil der Serie haben wir eine wichtige Funktionalität erstellt, nämlich eine bestehende Aufgabe verändert.Damit kennt ihr alles Wichtige, um selbst Full-Stack-Anwendungen zu erstellen:<ul><li>Verwendung des Model-Update-View-Pattern</li><li>Erstellung einer HTML-UI</li><li>Kommunikation zwischen Frontend und Backend mittels GET, POST und PATCH – und zwar mit und ohne Parameter in der URL</li><li>Parallele Verarbeitung, um eine nicht blockierende Anwendung im Frontend und Backend zu erstellen.</li></ul>Die Anwendung ist hiermit feature complete.Die letzten beiden Teile der Serie werden sich mit Sonderthemen beschäftigen: Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-4" target="_blank">nächsten Teil</a> hübschen wir das Frontend deutlich auf, der letzte Teil widmet sich dem automatisierten Testen.Viel Spaß …

Tutorial: F# mit SAFE-Stack – Teil 3

<h2>Eine Anwendung mit nur einer (funktionalen) Programmiersprache entwickeln</h2><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/iPFBhiZZS3W6OKwfZTlk" alt="Polieren" width="1024" height="588" />(https://unsplash.com/photos/P4H2wo6Lo7s)Willkommen zurück zum vierten Teil der Serie.Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-1" target="_blank">ersten Teil</a> der Serie haben wir das Grundgerüst für eine einfache Todo-Anwendung gebaut, die zunächst nur eine feste Liste von Aufgaben anzeigen konnte. Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-2" target="_blank">zweiten Teil</a> haben wir sie dann erweitert, um neue Aufgaben hinzufügen zu können. Am Ende des <a href="/wissens-hub/blog/tutorial-safe-stack-teil-3" target="_blank">dritten Teils</a> war die Anwendung dann bereits feature complete, da existierende Aufgaben auch als abgeschlossen markiert werden können.Die Web-Anwendung ist vollständig in F# geschrieben und benutzt die Bibliotheken des SAFE-Stacks, insbesondere:<ul><li>Giraffe (für die Bearbeitung von HTTP-Requests)</li><li>Fable (F# nach Javascript und React-UI-Elemente)</li><li>Elmish (für das Model-Update-View-Pattern)</li></ul>Natürlich würde man in einer echten, produktiven Anwendung eine Aufgaben auch noch ändern und löschen können wollen. Aber um das zu bauen, benötigen wir keine neue (Sprach-)Elemente und Patterns, also habe ich das aus diesem Tutorial herausgelassen.Trotzdem sind wir noch nicht fertig.Heute wollen wir uns nämlich um das Aussehen unserer Anwendung kümmern. Ehrlich gesagt ist das bisherige Frontend optisch echt nicht besonders ansprechend. Alle Texte stehen einfach eng untereinander, Schriftgröße und Buttonformen entsprechen nicht dem heutigen Standard.Aber zum Glück können wir das ändern. Unsere Oberfläche besteht aus HTML-Elementen, die gestylt werden können.Frontend-Spezialisten könnten jetzt eine eigene CSS-Datei erstellen und an den einzelnen UI-Objekten in den view-Funktionen mit <code>Class "xxx"</code> die jeweiligen Styles zuweisen.Ich bin leider nicht besonders gut in CSS. Daher habe ich einen anderen Weg gewählt. Schauen wir es uns an.Den Code vom letzten Mal findet ihr <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/03_Toggle-completed" target="_blank">hier</a> .Den vollständigen Code von heute gibt es <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/04_UI-styling" target="_blank">hier</a> .<h2>Bulma</h2>Auf der Website <a href="https://bulma.io" target="_blank">bulma.io</a> findet man einen Anbieter einer CSS-Datei, in der eine Vielzahl von möglichen UI-Elementen bereits vorbereitet ist. Darunter sind Styles für Buttons und andere Komponenten, aber auch Layout-Informationen für mehrspaltige Seiten, Header und Footer und viele weitere einfach einzusetzende Klassen.Diese Bibliothek werden wir für unser Projekt nutzen. Eine Möglichkeit wäre es, sie dem Projekt hinzuzufügen und – wie oben beschrieben – die CSS-Klassen direkt an den HTML-Elemente in den <code>view</code>-Funktionen zu nutzen. Das finde ich aber nicht besonders elegant. Ich möchte doch eigentlich die gesamte Anwendung in F# schreiben. Und obwohl <code>Class</code>-Angaben natürlich gültiger F#-Code sind, wünsche ich mir doch eine besser integrierte Lösung.Und zum Glück gibt es die in Form der Bibliothek Fulma.<h2>Fulma</h2>Die ähnlichen Namen kommen nicht von ungefähr. <a href="https://fulma.github.io/Fulma/" target="_blank">Fulma</a> ist ein F#-Wrapper um die Bulma-Bibliothek. Sprich: Mit Fulma können wir fertige UI-Komponenten so nutzen, wie wir das bisher mit den Fable-React-Komponenten — zum Beispiel <code>h1</code> oder <code>div</code> – gemacht haben. Und Fulma kümmert sich darum, die richtigen HTML-Elemente mit den entsprechenden CSS-Klassen zu erstellen.Damit können wir weiterhin bei unserem deklarativen Stil für die UI bleiben, ohne den Code mit einer Vielzahl von Elementen mit dedizierten <code>Class</code>-Angaben zu stilistisch zu verwässern.<h2>Bulma und Fulma ins Projekt einbauen</h2>Der einfachste Weg, Bulma ins Projekt zu bringen, ist, die <a href="https://github.com/jgthms/bulma/blob/master/css/bulma.css" target="_blank">bulma.css</a> -Datei in das Verzeichnis <code>src/Client/public</code> zu kopieren. Natürlich kann man Bulma auch per <code>npm</code> in das node-Projekt einbinden, aber das schien mir die Mühe nicht wert.Fulma hingegen ist eine F# Bibliothek und muss dem .NET-Projekt hinzugefügt werden. Dazu wechseln wir in das Verzeichnis <code>src/Client</code>. Dort fügen wir die Bibliothek unserem Projekt hinzu:

```
dotnet add package Fulma.Extensions.Wikiki.Tooltip
dotnet build

```

Ab jetzt sind wir bereit und können die neue Funktionen nutzen.Natürlich müssen wir heute ausschließlich unser Frontend anpassen.<h2>Index.fs</h2>Den ganzen oberen Abschnitt unseres Codes mit den Messages und der <code>update</code>-Funktion lassen wir unverändert. Änderungen gibt es erst weiter unten, wo die <code>view</code>-Funktionen stehen.In dem dortigen Bereich von <code>open</code>-Anweisungen fügen wir eine weitere hinzu:

```
open Fulma

```

Ab jetzt stehen uns neue UI-Komponenten zur Verfügung. Die Dokumentation auf der Fulma-Website ist leider nicht besonders ausführlich, aber wenn man sich ein bisschen eingelesen hat, reicht es später meistens aus, die Bulma-Dokumentation zu lesen. Wie die Komponenten dann in Fulma heißen, ist meistens intuitiv klar, bzw. kann mithilfe der Code-Completion herausgefunden werden.Also verändern wir jetzt unsere erste große Funktion <code>todoView</code> für die Darstellung eines <code>todo</code>:

```
let todoView todo dispatch =
 Level.level [] [
 Level.left [] [
 Level.item [] [
 input [
 Type "checkbox"
 Checked todo.Completed
 OnClick (fun _ -> todo.Id |> ToggleCompleted |> dispatch)
 ]
 ]
 Level.item [] [
 div [
 match todo.Completed with
 | true -> Style [ CSSProp.TextDecoration "line-through" ]
 | false -> Style []
 ] [
 Label.label [ Label.Modifiers [
 if todo.Completed then
 Modifier.TextColor IsSuccess
 Modifier.TextWeight TextWeight.Normal
 ] ] [ str todo.Description ]
 ]
 ]
 ]
 ]

```

Ok, das ist jetzt sehr viel umfangreicher als die vorherige Version (hier im Vergleich):

```
let todoView todo dispatch =
 div [] [
 input [
 Type "checkbox"
 Checked todo.Completed
 OnClick (fun _ -> todo.Id |> ToggleCompleted |> dispatch)
 ]
 label [ ] [str todo.Description]
 ]

```

Aber wir möchten ja auch, dass unsere Anwendung hübscher wird. Also verwenden wir das Fulma-Element <code>Level</code>. Und dieses erfordert (leider), dass man einige Elemente schachtelt.Im ersten <code>item</code> befindet sich die Checkbox. Es gibt zwar eine Fulma-Checkbox, ich habe mich aber für die »normale« entschieden, damit wir sehen können, dass Fulma problemlos mit »normalen« HTML-Komponenten gemischt werden kann. Das ist auch kein Wunder, denn letztlich erzeugen diese Fulma-Funktionen auch nur HTML-Elemente, nur eben mit vordefinierten Class-Eigenschaften.Das zweite item enthält ebenfalls einen »normalen« <code>div</code>. Wir verwenden ihn dafür, den Text durchzustreichen – eine Option, die in der Dokumentation zu Fulma oder Bulma nicht gefunden habe. In dem <code>div</code> steckt dann allerdings ein Fulma-<code>Label</code> mit entsprechenden Style-Attributen.Unsere nächste Funktion ist deutlich einfacher:

```
let todosView model dispatch =
 Box.box' [] ( model.Todos |> List.map (fun each ->
 todoView each dispatch))

```

Letztlich verwenden wir hier nur eine <code>Box</code>, um einen Rahmen mit Schattierung um alle Aufgaben zu zeichnen. (Das Zeichen <code>'</code> bei <code>Box.box'</code> ist kein Tippfehler. Den genauen Grund dafür kenne ich nicht – ich vermute, der der Name <code>box</code> bereits irgendwie vergeben war und sich die Entwickler daher für <code>box'</code> entschieden haben.)Unsere Eingabezeile für neue Aufgaben ist wieder etwas aufwändiger:

```
let descriptionView model dispatch =
 Columns.columns [ ] [

 Column.column [ ] [
 Input.text [
 Input.Placeholder "What is to be done?"
 Input.IsRounded
 Input.Value (model.Description)
 Input.OnChange (fun ev -> !!ev.target?value |> DescriptionChanged |> dispatch)
 ]
 ]

 Column.column [ Column.Width (Screen.All, Column.IsNarrow) ] [
 Button.button [
 Button.Color IsPrimary
 Button.OnClick (fun _ -> AddTodo |> dispatch)
 ] [ str "Add" ]
 ]
 ]

```

Aber wirklich kompliziert ist der Code nicht. In zwei Spalten nebeneinander stehen der Text und der Button. Die Konstruktion <code>Column.Width (Screen.All, Column.IsNarrow)</code> dient dazu, dass der Button nicht die gleiche Größe hat wie das Eingabefeld. <code>Screen.All</code> ist dabei der Platzhalter für alle Arten von Screens (Desktop, Tablet, Mobilephone …), damit die Eigenschaft stets richtig  gewählt wird. Hier scheint eine Stärke von Bulma/Fulma durch, denn die sich ergebene Website ist responsive und reagiert auf Veränderungen z. B. in der Breite des Browser-Fensters.Zuletzt die eigentliche <code>view</code>-Funktion.

```
let view model dispatch =
 div [ ] [
 Columns.columns [ ] [
 Column.column [
 Column.Width (Screen.All, Column.IsHalf)
 Column.Offset (Screen.All, Column.IsOneQuarter)
 ] [
 Section.section [
 Section.Props [ Style [ TextAlign TextAlignOptions.Center ] ]
 ] [ 
 img [ Src "favicon.png" ]
 Heading.h1 [] [ str "Todo list" ]
 ]
 
 descriptionView model dispatch
 errorView model
 todosView model dispatch 
 ]
 ]
 ]

```

Die <code>Columns</code> am Anfang sorgen für die Zentrierung des restlichen Inhalts: Der Inhalt ist einen halben Screen breit und hat links einen Rand von einem Viertel Screen.Auf diese Weise haben wir jetzt eine deutliche Verbesserung der Optik unserer kleinen Anwendung erreicht.<table><tbody><tr><td>Vorher:<img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/NJkJaDRUR543EBA48Ujs" alt="Screenshot alte Version" width="400" height="476" /></td><td>Nachher:<img loading="lazy" width="682" height="720" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/JDYCwkaRW6MifbeXa5hh" alt="Screenshot neue Version" /></td></tr></tbody></table><h2>Zusammenfassung</h2>In diesem – erneut recht kurzen – Teil der Serie haben wir eine Möglichkeit kennengelernt, eine F#-Anwendung optisch zu verbessern. Es gibt noch eine Vielzahl von weiteren Optionen – insbesondere ist es möglich, eigene Komponenten mit einer dedizierten CSS-Datei zu erstellen.Alles, was man dafür braucht, sind Funktionen, die HTML-Elemente zurückgeben und diese sinnvoll stylen.Sicher gebe ich zu, dass auch diese Anwendung kein perfektes UI-Design besitzt, eine wirklich ansprechende Oberfläche zu erstellen, überlasse ich dann aber euch.Bulma und Fulma sind wie gesagt nur eine Möglichkeit, eine Web-Anwendung aufzuhübschen. Aber diese Bibliotheken sind in der SAFE-Welt sehr verbreitet. Wenn ihr nämlich ein neues SAFE-Projekt aufsetzen möchtet und diesmal nicht mit dem minimalen sondern dem normalen Template beginnt, dann werdet ihr feststellen, dass dort Bulma und Fulma bereits integriert sind. Auch in vielen anderen Beispielen zu SAFE habe ich sie gefunden. Man kann also behaupten, dass es sich hierbei um so etwas wie einen de facto Standard für F# mit SAFE-Stack handelt.Einen letzten Teil habt ihr noch vor euch. Nächstes Mal fügen wir noch automatisierte Unit-Tests hinzu. Damit wären wir dann vollständig.Ich freue mich auf euch.

Tutorial: F# mit SAFE-Stack – Teil 4

<h2>Eine Anwendung mit nur einer (funktionalen) Programmiersprache entwickeln</h2><img width="1024" height="620" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/zS7ttO2rTyKECs1LRC7w" alt="Prüfung, Test" /> (https://unsplash.com/photos/BCBGahg0MH0)Willkommen zurück zum fünften und letzten Teil der Serie.Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-1" target="_blank">ersten Teil</a> der Serie haben wir das Grundgerüst für eine sehr einfache Todo-Anwendung gebaut, die zunächst nur eine feste Liste von Aufgaben anzeigen konnte. Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-2" target="_blank">zweiten Teil</a> haben wir sie dann erweitert, um neue Aufgaben hinzufügen zu können. Am Ende des <a href="/wissens-hub/blog/tutorial-safe-stack-teil-3" target="_blank">dritten Teils</a> war die Anwendung dann bereits feature complete, existierende Aufgaben können jetzt als abgeschlossen markiert werden. Im <a href="/wissens-hub/blog/tutorial-safe-stack-teil-4" target="_blank">vierten Teil</a> haben uns um die Optik gekümmert und die Anwendung deutlich ansprechender gestaltet.Die Web-Anwendung ist vollständig in F# geschrieben und benutzt die Bibliotheken des SAFE-Stacks, insbesondere:<ul><li>Giraffe (für die Bearbeitung von HTTP-Requests)</li><li>Fable (F# nach Javascript und React-UI-Elemente)</li><li>Elmish (für das Model-Update-View-Pattern)</li></ul>Funktional und optisch sind wir fertig. Aber einen ganz wichtigen Teil haben wir bisher unterschlagen, und zwar einen, der sehr gerne vergessen – oder sollte ich sagen: verdrängt? – wird:TestenJede Anwendung muss getestet werden, bevor sie produktiv eingesetzt wird! State of the art sind dabei natürlich automatisierte Tests. Und genau diese wollen wir heute zum Einsatz bringen. Ihr werdet sehen, dass auch das sehr einfach geht. Generell spielt bei automatisiertem Testen der funktionale Programmierstil seine Stärke voll aus.<h2>Test-Frameworks</h2>Für .NET gibt es mehrere Test-Frameworks, aus denen ihr wählen könnt. Für die Verwendung mit F# habe ich diese hier gefunden:<ul><li><a href="https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-fsharp-with-mstest" target="_blank">MSTest</a> </li><li><a href="https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-fsharp-with-nunit" target="_blank">NUnit</a> </li><li><a href="https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-fsharp-with-dotnet-test" target="_blank">xUnit</a> </li></ul>Zu allen Frameworks gibt es Dokumentation von Microsoft selbst aber auch aus anderen Quellen.MSTest scheint veraltet zu sein. NUnit ist sehr deutlich von JUnit abgeleitet, das für Java und andere Sprachen der Java Virtual Machine den de facto-Standard darstellt. xUnit ist eine Weiterentwicklung von NUnit.Für dieses Tutorial habe ich mich für xUnit entschieden. Es scheint mir für unseren Anwendungsfall am einfachsten und klarsten einsetzbar zu sein, außerdem ist es das neueste der drei Frameworks. Insbesondere können wir mit xUnit einfache Testfunktionen schreiben, so wie es sich für F# gehört. Mit den anderen Bibliotheken müssen wir eine Klasse erzeugen, da dies bei C#, der Hauptsprache von .NET, so gemacht wird. Geht zwar in F#, passt aber nicht zum funktionalen Paradigma.Also nehmen wir xUnit.Den vollständigen Code vom letzten Mal findet ihr <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/04_UI-styling" target="_blank">hier</a> .Den Code von heute gibt es <a href="https://github.com/goetz-markgraf/SAFE-Todo-Blog/releases/tag/05_Tests" target="_blank">hier</a> .<h2>Ein Testprojekt hinzufügen</h2>Aktuell befinden sich in unserem Projektverzeichnis drei .NET-Projekte, die jeweils in einem eigenen Verzeichnis untergebracht sind:<ul><li><code>src/Client</code></li><li><code>src/Shared</code></li><li><code>src/Server</code></li></ul>Jetzt fügen wir noch ein viertes hinzu, in dem die Tests angesiedelt werden.Dazu erzeugen wir ein neues Verzeichnis und wechseln hinein:

```
cd src
mkdir Test
cd Test

```

In diesem Verzeichnis erzeugen wir jetzt ein Projekt für xUnit:

```
dotnet new xunit -lang "F#"

```

Will man eines der anderen Frameworks verwenden, muss man <code>xunit</code> durch <code>nunit</code> oder <code>mstest</code> austauschen.Jetzt müssen wir noch diejenigen Projekte hinzufügen, deren Code wir testen möchten, bzw. die davon abhängig sind:

```
dotnet add reference ../Shared/Shared.fsproj
dotnet add reference ../Server/Server.fsproj

```

Ab jetzt ist alles klar und wir können starten, die Tests zu schreiben.<h2>Test.fs</h2>In dieser Datei stehen unsere Tests. Als Vorlage ist diese Datei schon angelegt. Im oberen Bereich »öffnen« wir die Module, auf die wir uns beziehen möchten:

```
open Xunit

open Shared
open Server

```

Jede andere Funktion, die noch in der Datei steht, können wir löschen.Jetzt können wir unsere Testfunktionen schreiben. Damit sie vom xUnit auch erkannt werden, verstehen wir sie mit der Annotation <code>[&lt;Fact&gt;]</code>Wir werden nur unser <code>Todo</code>-Modul testen. In diesem Modul steckt die »Business-Logik« unserer Anwendung. Natürlich kann man auch die anderen Funktionen testen, aber für dieses Tutorial reicht mir das.Fangen wir also damit an, den Mechanismus zu testen, der neue Ids für die Aufgaben erzeugt:

```
[<Fact>]
let ``create new Id`` () =
 let model = [{ Id = 2; Description = "Todo 1"; Completed = false}]
 let result = Todos.newId model
 Assert.Equal(3, result)
```

Wir erzeugen ein <code>Model</code> mit einem <code>Todo</code> mit der <code>Id</code> 2 und erwarten, dass uns die 3 als neue, mögliche <code>Id</code> zurückgegeben wird.Die doppelten Backticks <code>``</code> erlaubt es, in F# Bezeichner mit Leerzeichen zu verwenden. Im normalen Code ist das sicher keine gute Idee, da Leerzeichen dort eine andere Bedeutung haben und zu Verwirrung führen können. Aber für die Bezeichnung eines Tests sind sprechende Namen ungemein empfehlenswert, und wir können auf Unterstriche oder CamelCase verzichten.Wie schon gesagt, spielt das funktionale Paradigma beim Testen seine Stärke aus. Da das Ergebnis einer pure function (wie man sie möglichst verwenden sollte) nur von den Eingabeparametern abhängt, muss man nur diese richtig erzeugen und die Funktion aufrufen. Dadurch wird das given-when-then-Pattern eines Tests deutlich sichtbar:

```
given => let model = [{ Id = 2;
 Description = "Todo 1"; Completed = false}]
when => let result = Todos.newId model
then => Assert.Equal(3, result)

```

Der größte Aufwand besteht darin, die Eingabewerte und das erwartete Ergebnis zu konstruieren. Dazwischen steht dann immer nur der Funktionsaufruf der zu testenden FunktionSo können wir auch die anderen beiden Funktionalitäten unserer Geschäftslogik testen:

```
[<Fact>]
let ``add todo`` () =
 let model = [{ Id = 1; Description = "Todo 1"; Completed = false}]
 let result = Todos.addTodo model "Todo 2"
 let expected = { Id = 2; Description = "Todo 2"; Completed = false}
 Assert.Contains(model.Head, result)
 Assert.Contains(expected, result)

[<Fact>]
let ``shall toggle complete state`` () =
 let model = [{ Id = 1; Description = "Description"; Completed = false}]
 let result = Todos.toggleComplete model 1
 let expected = [{ Id = 1; Description = "Description"; Completed = true}]
 Assert.Equal<Todo list>(expected, result)

```

Im ersten Fall haben wir die Existenz des alten und des neuen Todos im Model geprüft, beim zweiten Mal sogar das exakte Model angegeben, das wir durch die Transformation erwarten.Warum wir beim zweiten Test in der <code>Assert.Equal</code>-Methode den Typ angeben müssen, weiß ich nicht, aber ohne diese Annotation `<Todo list>` kommt der Compiler nicht klar.Diese Tests sind sicher nicht ausreichend. Insbesondere werden keine etch-cases getestet (leere Listen, Dubletten etc.) Aber wie bei allem in diesem Tutorial geht es ja nur um das Prinzip.<h2>Was ist mit mocking?</h2>Ein großes Thema beim Testen ist normalerweise das mocking. Dabei werden diejenigen Objekte und deren Funktionalitäten, die die zu testende Funktion benötigt, durch Fassaden-Objekte ersetzt, deren Verhalten man kontrolliert und später abfragen kann. Geht das auch in F#?Grundsätzlich ja. Mit <a href="https://archive.codeplex.com/?p=foq" target="_blank">Foq</a> existiert auch eine entsprechende Bibliothek für F#.Doch im großen und ganzen benötigt man mocking bei funktionalen Sprachen nicht. Beziehungsweise, man benötigt dafür kein Framework.Wieso?Weil die Funktionen, die man testet keine Seiteneffekte haben – zumindest meistens. Wenn einer Funktion eine bestimmte Funktionalität dynamisch zur Verfügung gestellt werden soll, dann gibt man diese als Parameter mit. Innerhalb eines Tests kann man leicht ein Lambda so erstellen, dass es das gewünschte Verhalten hat, und der zu testenden Funktion mitgeben.Es gibt keine Referenzen, die Objekte auf andere Objekte halten und die man mocken müsste. Das Ergebnis einer Funktion hängt nur von den Eingabeparametern an. Und über die habe ich in meiner Test-Funktion die volle Kontrolle.So einfach ist das.<h2>Zusammenfassung</h2>Damit sind wir am Ende unserer Artikelserie angekommen. Ich hoffe, sie hat euch Freude gemacht, und ihr konntet etwas für eure zukünftigen Projekte mitnehmen.Der SAFE-Stack ist eine mächtige Sammlung von einfach zu nutzenden Frameworks, mit denen man full stack Anwendungen schreiben kann.Aber natürlich kann man die Komponenten auch einzeln verwenden. Mithilfe von <a href="https://saturnframework.org/explanations/overview.html" target="_blank">Saturn</a> kann man funktionale Web-Backends schreiben, losgelöst vom Frontend.<a href="https://fable.io" target="_blank">Fable</a> und <a href="https://elmish.github.io" target="_blank">Elmish</a> ermöglichen es, Web-Frontends in F# zu schreiben, die mit sehr wenig Overhead ansprechende und funktionale Oberfläche bieten. Der F#-Code kann dabei problemlos mit anderem, in JavaScript geschriebenem Code interagieren.Sprich: es muss nicht immer full stack sein. Ihr könnt die Komponenten auch einzeln verwenden.Ich habe bei allen Frameworks immer nur die Grundlagen gezeigt. Alle können noch viel mehr. So ermöglicht es Saturn zum Beispiel, mithilfe eines <code>controller</code> alle HTTP-Endpunkte für CRUD-Operationen in REST-konformer Konvention zu erstellen, ohne die Pfade und HTTP-Verben einzeln definieren zu müssen (siehe <a href="https://saturnframework.org/explanations/controller.html" target="_blank">hier</a> ).Elmish unterstützt unter anderem die Manipulation der history eines Browsers, um Usern Bookmarks auf einzelne Dialoge der Anwendung zu ermöglichen (siehe <a href="https://elmish.github.io/browser/" target="_blank">hier</a> ).Es gibt noch Vieles zu entdecken.Und dabei wünsche ich euch viel Spaß.

Tutorial: F# mit SAFE-Stack – Teil 5

Die Sprache Kotlin erfreut sich zunehmender Beliebtheit. Laut dem <a href="https://insights.stackoverflow.com/survey/2021/#technology-most-popular-technologies" target="_blank">2021 Stackoverflow Survey</a> nutzen knapp 10 % aller professionellen Entwickler Kotlin. Viele kennen die Sprache als „das bessere Java", was Kotlin wohl auch ist. In diesem Artikel möchte ich zeigen, wieso Kotlin noch mehr ist als das. Kotlin ist vielmehr so etwas wie „der freundliche Superheld aus der Nachbarschaft".
(_Foto: https://unsplash.com/photos/9XAnXWHu9_4_)

Das Team bei JetBrains, das Kotlin baut, hat eine pragmatische Sprache zum Ziel. Kotlin ist weniger auf theoretische Konstruktionen und Vollständigkeit optimiert, sondern auf leichten Einstieg und einfache Benutzbarkeit (DX = Developer Experience). 

* Du möchtest weniger Boilerplate Code schreiben als in Java? – Probier Kotlin aus!
* Du möchtest unveränderbare Datenstrukturen und Sicherheit vor `null` haben? – Probier Kotlin aus!
* Du möchtest mehr in funktionalem Stil schrieben? – Probier Kotlin aus!

Kotlin ist nicht furchterregend, Kotlin ist (oder erscheint) ganz leicht und einfach. Die Sprache und auch die Dokumentation sind auf eine niedrige Einstiegshürde hin ausgerichtet.

Im Folgenden werden ich davon ausgehen, dass du diese „Basics" von Kotlin bereits kennst:

* Kein Schreiben von Gettern und Settern
* `data class`, die zusätzlich automatisch `equals`, `hashCode` und `toString` erstellt
* Unveränderbarkeit (`val` vs. `var`, `List` vs. `MutableList` usw.)
* Null-Sicherheit (`String` vs. `String?`)
* Type inference (`val name = "String"`, ohne `name` explizit zu typisieren)
* Funktionen und Lambdas als Parameter von anderen Funktionen (`list.map { i -> i+1 }`, oder `list.map(::adder)`)
* Lambdas mit nur einem Parameter: der Parameter ist implizit als `it` verfügbar
* Listenoperationen (`listOf(1, 2, 3).map{it + 10}`)
* `if`, `when` und viele andere Schlüsselwörter sind Ausdrücke/Expressions und keine Anweisungen/Statements

Sollte diese Liste Fragen und Kopfschütteln hervorrufen, schlage ich vor, du schaust dir die <a href="https://kotlinlang.org/docs/basic-syntax.html" target="_blank">grundlegende Kotlin-Syntaxdokumentation</a> einmal an.

Also, los geht's mit Kotlin-Funktionen, die du vielleicht noch nicht kennst ...






## Scope-Funktionen: nette kleine Helfer

Kotlin bietet in der Standardbibliothek eine Reihe von nützlichen Helfer-Funktionen. Drei davon, die zu den „Scope-Functions" gehören, möchte ich hier einmal vorstellen:

* let
* also
* apply

(_Es gibt noch mehr Scope-Functions, aber bisher habe ich nur diese drei verwendet._)

Alle drei Funktionen kann man als Methode von jedem beliebigen Objekt aufrufen, ja sogar als Methode von Literalen (wie `3` oder `"Hallo"`).



### `let`

Mit `let` kann ich etwas mit einem Objekt tun, ohne dauerhaft eine Variable dafür anlegen zu müssen. Hier zunächst erst einmal ein etwas überflüssiges Beispiel, das aber die grundsätzliche Nutzung zeigt.

```
// irgendeine Funktion zum Lesen von Daten
fun readSomeData(): <SomeType> { ... }

val result = readSomeData()
val displayString = result.let {
 if (it.isValid())
 it.data.toString()
 else
 it.error.toString()
}
```

Wir nehmen `result`, das von irgendeinem Typ `SomeType` ist, und rufen die Methode `let` auf. Das geht wie gesagt bei jedem Objekt. `let` nimmt ein Lambda als Parameter und übergibt seinerseits das Objekt diesem Lambda als Parameter. Das Ergebnis der Methode `let` ist das Ergebnis des Lambdas, hier also eine String-Version der Daten oder der Fehlermeldung.

Natürlich könnte man dieses Beispiel auch leicht mit einem einfachen `if` lösen, klar. Aber die Scope Function erlaubt es mir, auf die Variable `result` zu verzichten, wenn ich sie nicht woanders brauche:


```
// irgendeine Funktion zum Lesen von Daten
fun readSomeData(): <SomeType> { ... }

val displayString = readSomeData().let {
 if (it.isValid())
 it.data.toString()
 else
 it.error.toString()
}
```

`let` dient also dazu, Variablen zu vermeiden und damit den Scope einer Funktion sauber zu halten.

Ein weiteres Einsatzgebiet ist ein impliziter `null`-Check:

```
readData()?.let {
 println(it.status)
}
```

Durch das `?` vor dem `.let` werden die Funktion und damit das Lambda nur ausgeführt, wenn das Objekt davor nicht `null` ist.




### `also`

`also` funktioniert sehr ähnlich wie `let`, nur dass das Ergebnis der Funktion das Objekt ist, auf dem man die Funktion aufgerufen hat. `also` dient also dazu, mit einem Objekt etwas zu tun, trotzdem aber genau diesen Wert unverändert zurückzugeben oder weiterzuverwenden.

Das Einsatzgebiet sind vor allem Nebenwirkungen, wie Logging oder Zwischenspeichern in der Datenbank.

```
val result =
 aList
 .filter { /* filter the list */ }
 .also { log("Length: ${it.size}") }
 .map { /* do something more with the list */ }
```

Hier, mitten in der Listenverarbeitung wird mittels `also` zwischendurch die Länge der aktuellen Liste ausgegeben.

Hier noch ein Beispiel:

```
val folder = File(basePath, someFolder)
 .also { it.mkdirs() }
```

Ich möchte in der Variablen `folder` das `File`-Objekt eines bestimmten Verzeichnisses speichern. Gleichzeitig möchte ich sichergehen, dass dieses Verzeichnis und alle darüber angelegt werden, sollte das noch nicht der Fall sein.



### `apply`

`apply` funktioniert so ähnlich wie `also`. Der Unterschied besteht darin, dass das Objekt dem Lambda nicht als Parameter übergeben wird, sondern als „Receiver": innerhalb des Lambdas ist das Objekt, auf dem ich `apply` aufrufe, als `this` erreichbar.

Damit ist `apply` wunderbar dafür geeignet, klassische Java-Objekte leeren Konstruktoren zu erstellen und direkt nach der Erstellung mit Werten zu versehen:

```
val header = HttpHeaders().apply {
 set("api_key", /* some api key */ )
 set("Content-Type", "application/json")
}
```

In `header` wird ein `HttpHeader`-Objekt hinterlegt, das direkt nach dem Erstellen mit ein paar Werten gefüllt wird. Das ist sozusagen ein Ersatz für die in klassischen Java-Bibliotheken oftmals fehlenden sinnvollen Konstruktoren und auch eine Alternative zum Builder-Pattern.




## Top-Level Funktionen: Wofür brauche ich Klassen?

In Java müssen alle Funktionen Teil einer `class` sein, entweder als `static` oder als Member-Function. In Kotlin braucht man keine `class`, um eine Funktion zu erstellen. Man kann sie einfach direkt in die Datei einfügen:

```
package myPackage

fun adder(a: Int, b: Int): Int {
 return a + b
}
```

Diese Funktion kann von überall in diesem Package aufgerufen werden oder in ein anderes Package importiert werden:

```
Paket myOtherPackage

importiere myPackage.adder

...
 val result = adder(10, 20)
...
```

Wenn man Kotlin-Code schreibt, sollte man wirklich einen guten Grund haben, Funktionen in einer Klasse anzusiedeln. Das könnten zum Beispiel sein:

* Ich will eine `data class` mit zusätzlichen Member Functions ausstatten
* Das Framework benötigt Klassen (wie z. B. bei Spring)

Bevor du aber eine Klasse erstellst, nur um ein paar Funktionen zu gruppieren, versuch es doch mal mit Top-Level-Funktionen. Das Gruppieren kann man durch separate Dateien immer noch erreichen. Eine mit `private` markierte Top-Level-Funktion ist nur innerhalb derselben Datei erreichbar. Kapselung funktioniert also immer noch.





## Single Expression Body: Wofür brauche ich die geschweiften Klammern?

Es gibt eine sehr nette alternative Schreibweise für Funktionen, deren Body nur aus einer einzigen Expression besteht, dessen Ergebnis auch gleich der Rückgabewert der gesamten Funktion ist. In diesem Fall kann ich folgendes weglassen:

* Geschweifte Klammern
* Deklaration des Return Types
* Das Schlüsselwort `return`

Ich muss stattdessen nur ein Gleichheitszeichen (`=`) setzen.

Hier zum Vergleich:

```
// "java-esque" style
fun add (a: Int, b: Int): Int {
 return a + b
}
```

ist genau dasselbe wie

```
// functional style
fun add (a: Int, b: Int) = a + b
```

Hier noch ein weiteres Bespiel:

```
fun giveType(o: Any) =
 when (o) {
 is Int -> "Sorry, just an integer"
 is Double -> "Hey, it has decimal numbers"
 is String -> "It's a String"
 else -> "I have no idea"
 }

println(giveType(10)) // Sorry, just an integer
println(giveType(10.5)) // Hey, it has decimal numbers
println(giveType("Hello")) // It's a String
println(giveType(Date())) // I have no idea
```

(_Hinweis: Normalerweise sollte man `Any` meiden, wie der Teufel das Weihwasser. Das hier dient nur zur Verdeutlichung._)

Gerade bei Funktionen, deren Body nur aus einer `when`-Expression besteht, ergibt diese Schreibweise sehr viel Sinn.





## Extension Functions: Auf die „fließende" Tour

Eine „Extension Function" ist eine Funktion, bei der der Funktionsname _nach_ einem Typ steht (mit `.` getrennt).

```
fun String.duplicate(): String { return this + this }
```

Beim Aufruf dieser Beispielfunktion wird die Zeichenkette zweimal hintereinander gesetzt:

```
"Test".duplicate() // ergibt: "TestTest"
```

Es sieht so aus, als hätten wir die aktuelle Klassendefinition erweitert und ihr eine neue Member Function gegeben. Fragen tun sich auf: Welche Nebenwirkungen hat das? Wann und warum sollte ich das tun?

Keine Angst!

Das ist nicht das, was hier passiert. Betrachte eine Extension Function als ganz normale Funktion mit einer anderen Art der Parameterübergabe. Anstatt einen der Werte *nach* dem Funktionsnamen in Klammern zu übergeben, wird er *vor* den Funktionsnamen geschrieben. Innerhalb der Funktion kann dieser Wert mit `this` erreicht werden.

Wenn man sich Extension Functions so vorstellt, verlieren sie ihren Schrecken und werden einfach nur zu ... Funktionen.

Das Schreiben von Extension Functions gibt uns die Möglichkeit, Algorithmen auf eine „fließende Weise" (fluent) zu schreiben.

Wenn wir zum Beispiel für eine Autovermietung arbeiten, könnten wir Funktionen wie diese erstellen:

```
val cars: List<Car> = // eine Datenstruktur,
 // die die Autos der
 // Autovermietung enthält

fun List<Car>.compactClass() = ...

fun List<Car> isAvailable(day: LocalDate) = ...
```

Später in unserer Hauptfunktionen können wir schreiben:

```
val result = cars
 .compactClass()
 .isAvailable(today)
```

Einfach, nicht? Man nimmt eine Datenstruktur (in diesem Fall eine Liste von Autos) und ruft eine Funktion darauf auf. Mit dem zurückgegebenen Wert (wieder eine Liste von Autos) ruft man die nächste Funktion auf. Und so weiter ...

„Fluent Code" ist häufig lesbarer und verständlicher.






## Algebraic Data Types: Wie modelliere ich meine Domäne?

Viele funktionale Programmiersprachen unterstützen sogenannte <a href="https://en.wikipedia.org/wiki/Algebraic_data_type" target="_blank">algebraische Datentypen</a>. Dies ist ein komplizierter Name für eine eigentlich sehr einfache Sache. Es bedeutet nur, dass mir zwei verschiedene Möglichkeiten zur Verfügung stehen, Datenstrukturen zu erstellen.

Eine Möglichkeit besteht darin, mehrere Werte zu *kombinieren*, um eine neue Datenstruktur zu bilden. In Kotlin nennen wir diese Dinge ... `class` oder besser `data class`:

```
data class Adresse(
 val street: String,
 val number: String,
 val zipCode: String,
 val Stadt: String
)
```

Ich nehme an, dass du damit vertraut bist. Fast jede Programmiersprache kann so etwas (`struct`, `class`, `record` ...). Eine der beiden Modellierungsmöglichkeiten ist damit abgehakt.

Die zweite Art, Daten zu strukturieren, ist eine, die von etlichen Programmiersprachen *nicht* unterstützt wird. Die Idee besteht darin, nicht mehrere Werte zu kombinieren, sondern eine Struktur zu definieren, die genau *eine* Ausprägung aus einer bestimmten Menge von Werten zulässt.

Nehmen wir zum Beispiel eine abstrakte Datenstruktur `contact information`, die eine E-Mail-Adresse *oder* eine Telefonnummer enthalten könnte. Eine `contact information` kann nur einen dieser Werte enthalten, nicht beide zur gleichen Zeit.

Der erste Gedanke könnte eine `enum class` mit den möglichen Werten `EMAIL_ADDRESS` und `PHONE_NUMBER` sein. Aber das ist nicht genug, weil ich für beide Fälle zusätzliche Daten speichern will, eben die E-Mail-Adresse oder die Telefonnummer. Natürlich kann eine `enum class` auch Daten enthalten, aber das reicht uns nicht, denn bei einer `enum` müssen die Datenstrukturen in jeder Ausprägung vom gleichen Typ sein. Das ist in unserem Beispiel nicht der Fall.

Wir nehmen stattdessen eine `sealed class` oder besser noch ein `sealed interface` mit speziellen Ableitungen:

```
sealed interface ContactInformation

class EmailAddress(
 val email: String
): ContactInformation

class PhoneNumber(
 val countryCode: Int,
 val areaCode: Int,
 val number: Int
): ContactInformation
```

Das `sealed` führt dazu, dass alle Ableitungen dieser Klasse oder dieses Interface dem Compiler bekannt sein, also in *einem* Compile-Vorgang durchlaufen werden müssen. Einmal compiliert kann von einer solchen Klasse oder Interface später woanders nicht mehr abgeleitet werden. Auf diese Weise kann der Kotlin-Compiler sicher sein, dass er alle möglichen Ausprägungen für `ContactInformation` kennt.

Man benutzt ein solches Konstrukt meisten mit einer `when`-Expression:

```
fun getPrintString(ci: ContactInformation) =
 when (ci) {
 is EmailAdresse -> ci.email
 is PhoneNumber ->
 "+${ci.countryCode}-${ci.areaCode}-${ci.number}"
 }
```

Man braucht hier keinen `else`-Zweig, da der Compiler prüfen kann, dass die Fälle vollständig sind.

Mit <a href="https://arrow-kt.io/" target="_blank">ArrowKt</a> gibt es übrigens eine Bibliothek, die häufig verwendete funktionale Datentypen enthält, um Funktoren, Monaden und andere funktionale Patterns zu nutzen.




## Functiontypes with Receiver: Ist das ein „Extension-Lambda"?

Ich habe noch eine Sache, die ich zeigen möchte: Functiontypes with receiver.

Wir haben oben die Extension Functions gesehen, Funktionen, in deren Implementierung einer der „Parameter" als `this` zur Verfügung steht. Diese Funktionen besitzen natürlich auch eine Typsignatur und können auch als Parameter einer anderen Funktionen übergeben werden.

Klingt kompliziert? Ist es gar nicht. Schauen wir uns ein Beispiel an:

```
fun ifFileExists(file: File, action: File.()->Unit) {
 if (file.exists() && !file.isDirectory)
 file.action()
}
```

Diese Funktion nimmt zwei Parameter: ein `File` und eine andere Funktion, die eine Extension Function von `File` ist, selbst keinen Parameter nimmt und auch nichts zurückgibt: `File.()->Unit`.

Was tut `ifFileExists`? Wenn der übergebene Pfad existiert und kein Verzeichnis ist, dann wird die Funktion mit `File` als `this`-Wert aufgerufen.

Normalerweise werden solche Konstrukte mit Lambdas verwendet, die dadurch zu „Extension-Lambdas" werden (Ich schreibe „Extension Lambda" in Anführungszeichen, weil das keine offizielle Bezeichnung ist. Aber ich finde, sie beschreibt gut, worum es geht):

```
val file = Datei("/tmp/hello")

ifFileExists(aFile) {
 val Inhalt = readText()
 println(content)
}
```

Wenn es eine Datei unter `/tmp/hello` gibt und diese kein Verzeichnis ist, wird das Lambda ausgeführt, das den Inhalt liest und ausgibt. Spannend ist, dass man einfach `readText()` schreiben kann (ohne `this.` davor), denn `this.` kann man bekanntlich weglassen, wenn der Ausdruck eindeutig ist.

Wozu brauche ich ein solches Konstrukt? Mit „Extension Lambdas" kannst du Funktionen schreiben, die eine eigene DLS (=domain specific language) aufbauen.

Hier ist ein Beispiel aus der Kotlin-Dokumentation über <a href="https://kotlinlang.org/docs/type-safe-builders.html" target="_blank">type-safe builder</a>:

```
fun result() =
 html {
 head {
 title {+"XML encoding with Kotlin"}
 }
 body {
 h1 {+"XML encoding with Kotlin"}
 p {+"this format can be used as an alternative markup to XML"}

 // an element with attributes and text content
 a(href = "https://kotlinlang.org") {+"Kotlin"}

 // mixed content
 p {
 +"This is some"
 b {+"mixed"}
 +"text. For more see the"
 a(href = "https://kotlinlang.org") {+"Kotlin"}
 +"project"
 }
 p {+"some text"}

 // content generated by
 p {
 for (arg in args)
 +arg
 }
 }
 }
```

`html` ist eine Funktion, die ein „Extension Lambda" als Parameter nimmt und es mit einem bestimmten Builder-Objekt versorgt, das seinerseits die Funktionen `head` und `body` anbietet. `head` macht dasselbe mit einem anderen Builder, der unter anderem eine `title` -Funktion anbietet. Und so weiter.

In der oben erwähnten Dokumentation findest du den Quellcode zum Erstellen dieser DSL. Es ist wirklich erstaunlich wenig Code.

Extension Functions und „Extension Lambdas" sind übrigens alles, was man braucht, um die weiter oben erwähnten Scope Functions zu bauen. Schau dir mal den Sourcecode dafür an, du wirst staunen, wie kurz er ist.



## Zusammenfassung

Kotlin als Sprache kann deutlich mehr, als nur durch „syntactic sugar" umständliche Java-Sprachkonstrukte zu vereinfachen. Top-Level-Functions und Extension Functions ermöglichen funktionale, fließende Programmierung, `sealed class` und `sealed interface` ermöglichen algebraische Datentypen und das alles zusammen mit „Extension Lambdas" erlauben es, sehr lesbaren Code zu schreiben und auf „optical noise" zu verzichten.

Vielleicht hast du Lust bekommen, das bei deinem nächsten Projekt einmal auszuprobieren.

Tatsächlich ist selbst hier bei Kotlin nicht Schluss: Die meisten Entwicklerinnen und Entwickler setzen Kotlin ein, um Bytecode für die JVM (Java Virtual Machine) oder für Android zu erzeugen. Es gibt aber noch mehr Ziele für Kotlin-Code:

* Es gibt einen nativen Compiler (Kotlin/native), der plattformspezifische Binaries erzeugt, wodurch man z. B. iOS-Apps in Kotlin schreiben kann.
* Mit Kotlin/JS kann man Kotlin auch verwenden, um JavaScript zu erzeugen, als Alternative zu TypeScript, aber mit „algebraic data types".
* Mit Kotlin/multiplatform kann man das alles zusammen in einem gemeinsamen Projekt mit einem zentralen `gradle`-Build nutzen und dabei, wenn sinnvoll, Code zwischen den Modulen teilen.

Ich hoffe, ich konnte etwas mehr über eine Sprache erzählen, die du vielleicht schon benutzt, von der du aber möglicherweise das gesamte Potenzial noch nicht kanntest.

Kotlin, mehr als nur „das bessere Java"

Viele HTTP-Backends werden heutzutage mit Spring bzw. Spring Boot gebaut. So leistungsfähig Spring ist, so schwergewichtig ist das Framework auch. Außerdem liegt nicht jedem Developer die "Magie" in Spring Boot, die allein durch Annotationen Funktionalitäten zur Verfügung stellt. In diesem Artikel möchte ich als Alternative zeigen, wie man mit sehr wenig Aufwand ein abgesichertes HTTP-Backend auf Basis von **Ktor** erstellt.

<a href="https://ktor.io/" target="_blank">Ktor ist eine leichtgewichtige Alternative</a>zu Spring/Spring Boot, die meine Kollegen auch schon vorgestellt haben ([Ein Microservice mit Kotlin und Ktor – ohne Spring](https://blog.codecentric.de/microservice-kotlin-ktor-ohne-spring) und [Ktor – Es muss nicht immer Spring sein](https://blog.codecentric.de/ktor-es-muss-nicht-immer-spring-sein)). Das Framework wird von JetBrains entwickelt und offiziell unterstützt. Mittlerweile in Version 2.X ist Ktor gut für den produktiven Einsatz bereit. Besonders für Ktor spricht, dass der Code, den man schreiben muss, kurz und leicht verständlich ist.

Die Dokumentation ist weitgehend hervorragend und erleichtert den Einstieg. Allerdings sind fast alle Beispiele in der Dokumentation auf das Einsatzszenario ausgerichtet, dass Ktor auch das Anwendungs-Frontend in HTML per Server Side Rendering (SSR) ausspielt.

In unserer Praxis ist es allerdings häufig so, dass als Frontend eine Single-Page-App (SPA) oder vielleicht eine Mobile-App zum Einsatz kommt und sie mit dem Backend per HTTP/REST-Calls kommuniziert. Gerade im Bereich Authentication und Security passen daher die Beispiele nur bedingt.

## Das Beispielprojekt

In diesem Artikel bauen wir zusammen ein Ktor-Backend auf, das folgende Anforderungen erfüllt:

* Es kommuniziert mit dem Frontend im JSON-Format.
* Das Frontend (das wir nicht bauen werden) soll dann eine Login-Maske bereitstellen und die dort eingegebenen Daten per POST als Body an einen HTTP-Endpunkt schicken.
* Als Authentication Source wird ein LDAP-Server genutzt.
* Die Session-ID wird im Falle einer erfolgreichen Authentifizierung dem Client als Session-Cookie übergeben. Die Session-Daten befinden sich ausschließlich auf dem Server.
* Es gibt gesicherte Endpunkte, die nur zugänglich sind, wenn der Client mit einem gültigen Session-Cookie zugreift. Diese haben ihrerseits Zugriff auf die in der Session gespeicherten Daten.
* Möchte sich der Client ausloggen, kann er einen Endpunkt aufrufen, der die Session invalidiert und löscht. Ab hier kann man auch mit dem vorher noch gültigen Session-Cookie nicht mehr auf die gesicherten Endpunkte zugreifen.

Wenn eine solche Kommunikation über HTTPS abläuft, sind viele Sicherheitslücken geschlossen. Leicht kann man die Lösung noch um ein CSRF-Token erweitern, das ist aber nicht Inhalt dieses Beispiels.

Den <a href="https://github.com/goetz-markgraf/ktor-session-auth/tree/01_aufbau-sicheres-http-backend-kotlin-ktor" target="_blank">Code für diesen Artikel</a> findet ihr in Github. Es ist allerdings sinnvoller, wenn ihr diesen Artikel als Tutorial anseht und die einzelnen Schritte selbst durchführt.

Fangen wir an:

## Ktor-Projekt aufsetzen

Ein neues Ktor-Projekt erstellt man in am einfachsten in IntelliJ, da die IDE dafür ein Projekt-Template bereithält:

![New Project Ktor.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aPG4prOWQeeT1dDWkEcG)

Bei `Configuration in:` wählt man am besten `Yaml file` oder `HOCON file`, aber nicht `Code`. Das hat zu Folge, dass ein Properties-File erzeugt wird, in das man später noch weitere Anwendungsparameter zur Konfiguration einfügen kann.

Auf der nächsten Seite wählt ihr folgende Module:

* kotlinx.serialization
* Sessions
* Authentication LDAP

Der Wizard wird von sich aus noch weitere Module hinzufügen:

* Routing
* Content Negotiation
* Authentication

So gerüstet kann man auf `Create` klicken.

![New Project Plugins.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/reApw8E8QPiUU2soJthA)

## Session einrichten

Der Wizard hat einige Dateien erzeugt. Wir kümmern uns im Folgenden insbesondere um `Security.kt` im Package `de.codecentric.plugins`. Den Inhalt der Funktion `configureSecurity` könnt ihr löschen, den schreiben wir komplett neu. Als erstes schreiben wir diesen Code in die Funktion:

```kotlin
 install(Sessions) {
 cookie<SessionContent>("KTOR_SESSION", SessionStorageMemory()) {
 cookie.path = "/"
 cookie.extensions["SameSite"] = "lax"
 }
 }
```

`install` dient immer dazu, ein „Plugin“ (aka ein „Module“) zu aktivieren und damit den Funktionsumfang von Ktor zu erweitern. Das Plugin `Sessions` ist so eine Erweiterung.

In dem Lambda geben wir an:

* dass die Session über Cookies gehalten wird und dass der Inhalt der Session die Klasse `SessionContent` ist – diese Klasse kommt gleich.
* dass die Sessiondaten im Backend gehalten werden (und nicht im Cookie selbst) und zwar mittels eines `SessionStorageMemory`-Objekts.
* wie der Cookie aussehen soll.

Wir ergänzen noch die Klasse für die Session-Daten:

```kotlin
data class SessionContent(
 val user: String
) : Principal
```

Jetzt kann Ktor schon mal Sessions anlegen, wenn man darum bittet. Genau das wollen wir im nächsten Schritt tun.

## Authentication einrichten

Wir möchten einzelne Routen nur dann bedienen, wenn in der Session ein gültiger User eingetragen ist. Dazu ergänzen wir den folgenden Code hinter dem `install`-Code, den wir gerade geschrieben haben:

```kotlin
 authentication {
 session<SessionContent> {
 validate { it }

 challenge {
 call.sessions.clear<SessionContent>()
 call.respond(HttpStatusCode.Forbidden, "not authorized")
 }
 }
 }
```

Dieses Plugin müssen wir nicht explizit mittels `install` installieren. Stattdessen liefert es eine Helper-Function namens `authentication` mit, die das Plugin implizit installiert.

Im Lambda geben wir an, dass die authentication über die `session` geschieht und dass als `Principal` eben jedes `SessionContent`-Objekt genutzt werden soll. Daher hatten wir `SessionContent` auch von `Principal` abgeleitet.

Im Lambda gibt es zwei weitere Funktionen:

`validate` muss ein gültiges `Principal` zurückgeben. Da wir dieses bereits als Inhalt der Session benutzen (`it`) reicht es, das zurückzugeben. Wenn man mit Gültigkeitszeiträumen von Sessions arbeiten möchte, könnte man die hier prüfen.

`challenge` wird aufgerufen, wenn `validate` kein gültiges `Principal` zurückliefern kann. In diesem Fall löschen wir sicherheitshalber eine etwaige Session und antworten mit einem HTTP-Status 403.

Jetzt können wir bereits einzelne Routen absichern. Um das zu prüfen, erstellen wir eine Route, die nur aufgerufen werden kann, wenn der Request authentifiziert ist.

```kotlin
 routing {
 authenticate {
 route("/api") {
 get("/who-am-i") {
 call.principal<SessionContent>()?.let {
 call.respond(WhoAmIResponse.fromPrincipal(it))
 }
 }
 }
 }
 }
```

`routing` sagt, dass wir Ktor jetzt Endpunkt-Routen bekannt machen. Durch `authenticate` wird der Endpunkt abgesichert. Der Code des Endpunkts (`get`) holt dann nur das `Principal` und gibt es in ein `WhoAmIResponse`-Objekt verpackt wieder zurück.

```kotlin
@Serializable
data class WhoAmIResponse(val user: String) {
 companion object {
 fun fromPrincipal(session: SessionContent) = WhoAmIResponse(session.user)
 }
}
```

So, fertig. Jetzt müssen wir "nur noch" dafür sorgen, dass sich jemand anmelden und damit eine gültige Session erzeugen kann. Dafür nutzen wir öffentliche Endpunkte, die nicht abgesichert sind. Der folgende Code ergänzt unser `routing`-Lambda, kann aber auch in einem separaten `routing`-Aufruf stecken.

```kotlin
 route("/public") {
 post("/login") {
 val loginRequestBody = call.receive<LoginRequest>()
 val correct = validateLocally(loginRequestBody)
 if (correct) {
 call.sessions.set(SessionContent(loginRequestBody.username))
 call.respond(HttpStatusCode.OK)
 } else {
 call.respond(HttpStatusCode.Forbidden)
 }
 }

 post("invalidate-session") {
 call.sessions.clear<SessionContent>()
 call.respond(HttpStatusCode.OK)
 }
 }
```

Der Endpunkt `/public/api` holt aus dem Body ein `LoginRequest`-Objekt, das `username` und `password` enthält. Die werden in einer externen Funktion `validateLocally` geprüft. Wenn sie gültig sind, wird ein `SessionContent`-Objekt in die Session geschrieben und der Aufruf war erfolgreich. Sonst kommt ein HTTP-Status 403.

```kotlin
@Serializable
data class LoginRequest(val username: String, val password: String)
```

Natürlich brauchen wir jetzt auch eine Prüffunktion:

```kotlin
private fun validateLocally(loginRequestBody: LoginRequest) =
 loginRequestBody.username == "Philip J. Fry"
 && loginRequestBody.password == "fry"
```

(Warum wir gerade diese Login-Informationen als gültig ansehen, erkläre ich weiter unten).

Fertig. Wenn wir den Server jetzt starten, kann man sich mit dem User "Philip J. Fry" und dem Password "fry" einloggen, einen geschützten Endpunkt aufrufen, der ohne gültige Session nicht erreichbar ist.

Testet das gerne mit Postman – oder irgend einem anderen HTTP-Client.

Aber wir können noch mehr!

## Authentifizierung per LDAP

Ein fest implementierter User ist natürlich nicht schön. Stattdessen hatten wir ja gesagt, dass die Credentials gegen ein LDAP geprüft werden sollen (wir laden zunächst keine weiteren Daten aus dem LDAP).

Ein solches LDAP kann man leicht mittels `docker compose up -d` und der folgenden `docker-compose.yml` starten:

```yaml
version: '3.5'

services:
 ldap-aquar:
 container_name: ldap-aquar
 image: rroemhild/test-openldap
 ports:
 - "10389:10389"
 - "10636:10636"
 networks:
 - local-network

networks:
 local-network:
 driver: bridge
```

In diesem LDAP sind etliche User aus Futurama hinterlegt, zum Beispiel jener "Philip J. Fry".

Die Anbindung an das LDAP geschieht in einer alternativen `validate…`-Funktion:

```kotlin
private fun validateInLDAP(loginRequestBody: LoginRequest): Boolean {
 val user = ldapAuthenticate(
 UserPasswordCredential(loginRequestBody.username, loginRequestBody.password),
 "ldap://localhost:10389",
 "cn=%s,ou=people,dc=planetexpress,dc=com"
 )

 return user != null
}
```

`ldapAuthenticate` ist eine Funktion, die von dem `Authentication LDAP`-Modul geliefert wird. Sie liefert im Erfolgsfall ein User-Objekt zurück. Wir machen damit nicht mehr, als dass wir sicherstellen, dass dieses Objekt nicht `null` ist.

Sinnvollerweise sollten die Konfigurationswerte (URL, Port und auch der Query-String) in die `application.yml` ausgelagert werden, aber das habe ich mir gespart, um das Beispiel kurz zu halten.

In dem Post-Enpunkt muss nur noch diese Validation-Funktion genutzt werden:

```kotlin
post("/login") {
 val loginRequestBody = call.receive<LoginRequest>()
 val correct = validateInLDAP(loginRequestBody)
 ...
```

## Testen

Wir wollen unseren Code natürlich auch testen. Dafür legen wir neben den vordefinierten Test einen neuen Test an und nennen ihn z. B.: `SecurityTest`.

Einen Ktor-Test kann man mithilfe der helper function `testApplication` schreiben. Im Lambda ist dann ein `client` verfügbar, mit dem ich meine Endpunkte aufrufen kann. Für "normale" Routen reicht das, in unserem Fall müssen wir aber mehr machen. Der Client muss `json` sprechen, außerdem müssen wir ihm beibringen, dass er den Session-Cookie bei Requests mitschicken soll.

Damit das geht, muss ich noch folgende Dependency in die `build.gradle.kts` hinzufügen:

```kotlin
 testImplementation("io.ktor:ktor-client-content-negotiation-jvm:$ktor_version")
```

Dann kann ich mir eine eigene helper function schreiben:

```kotlin
fun clientTest(testCode: suspend ApplicationTestBuilder.(HttpClient) -> Unit) =
 testApplication {
 val client = createClient {
 install(ContentNegotiation) { json() }
 install(HttpCookies)
 }

 testCode(client)
 }
```

Diese Funktion nimmt ein Lambda als Parameter und erzeugt selbst die `testApplication`. Darin wird ein eigener `client` erzeugt, der `json` spricht und `HttpCookies` kennt. Das übergebene Lambda wird dann mit diesem `client` als Parameter aufgerufen.

Ein Test sieht dann so aus:

```kotlin
 @Test
 fun `should not be able to call who-am-i without login first`() = clientTest { client ->
 client.get("/api/who-am-i").let {
 assertEquals(HttpStatusCode.Forbidden, it.status)
 }
 }
```

Ich rufe – ohne Anmeldung – den gesicherten Endpunkt auf und stelle fest, dass ich einen HTTP-Status FORBIDDEN erhalte.

Der Positiv-Test ist ähnlich schnell geschrieben:

```kotlin
 @Test
 fun `should login successfully`() = clientTest { client ->

 client.post("/public/login") {
 contentType(ContentType.Application.Json)
 setBody(LoginRequest("Philip J. Fry", "fry"))
 }.let {
 assertEquals(HttpStatusCode.OK, it.status)
 }

 client.get("/api/who-am-i").let {
 assertEquals(HttpStatusCode.OK, it.status)
 assertEquals(WhoAmIResponse("Philip J. Fry"), it.body())
 }
 }
```

Im ersten Schritt logge ich mich ein, und erhalte einen HTTP-Status OK. Danach kann ich auch den gesicherten Endpunkt aufrufen und kann das Ergebnis überprüfen.

Wenn man jetzt noch mehr Tests schreiben möchte, die einen angemeldeten Zustand benötigen, ist es sinnvoll, für den Login-Step eine eigene helper function (z. B.: `authenticatedTest`) zu schreiben. Der o. g. Test sähe dann nur noch so aus:

```kotlin
 @Test
 fun `should login successfully`() = authenticatedTest("Philip J. Fry", "fry") { client ->
 client.get("/api/who-am-i").let {
 assertEquals(HttpStatusCode.OK, it.status)
 assertEquals(WhoAmIResponse("Philip J. Fry"), it.body())
 }
 }
```

Ich überlasse es euch, diesen Helper zu schreiben …

## Zusammenfassung und Ausblick

Mit diesem wenigen Code kann man abgesicherte HTTP-Endpunkte aufbauen und sehr leicht testen. Das Arbeiten mit Ktor geht schnell, ist übersichtlich und – wie ich finde – sehr verständlich.

Der Code ist sicher noch verbesserungsfähig, vor allem ist schlecht, dass der Server die Session-Daten im Speicher hält. Das skaliert nicht, und außerdem überlebt eine Session den Neustart des Servers nicht. Aber das ist ein Thema für einen weiteren Artikel.

Aufbau eines sicheren HTTP-Backends mit Kotlin und Ktor

## Einleitung

KI-Tools, die die Arbeit des Softwareentwicklers unterstützen – oder eventuell sogar ganz ersetzen – sorgen im Moment für Schlagzeilen. In diesem Artikel möchte ich einen ganz persönlichen Erfahrungsbericht schreiben, wie es mir erging, als ich experimentell ChatGPT benutzt habe, um in Programmiersprachen, die ich bis dato nicht kannte, eine Anwendung zu entwickeln. Ich möchte hier zeigen, wie man ChatGPT – oder auch andere Large Language Models (LLMs) – als Werkzeug einsetzen kann, was es kann und wo die Grenzen liegen.

Ich habe bei meinem Experiment sowohl GPT-3.5 als auch GPT-4 Models verwendet. Der Unterschied war nicht groß, aber gefühlt vorhanden.

## Das Experiment

Go und Rust sind zwei Programmiersprachen, die mir grundsätzlich bekannt sind: Ich weiß, dass es sie gibt und ich weiß in etwa, was die Besonderheiten der Sprachen sind. In beiden Sprachen habe ich vor etwa zwei Jahren mal „Hello World“-Programme geschrieben, aber viel weiter bin ich nicht gekommen.

Zu Beginn meines Experiments war mir bei beiden Sprachen noch nicht einmal klar, wie ich jeweils ein Source-File strukturiere, es kompiliere oder automatisierte Tests schreibe. Und da dachte ich mir, könnte mir die Welt der KI helfen.

Ich habe also insgesamt zwei Konversationen gestartet, eine für Rust und danach eine für Go.

## Der Prompt macht die Musik

Grundsätzlich ist es immer eine gute Idee, ChatGPT zu Beginn einer Konversation über Szenario und Erwartungshaltung zu informieren. Teile dem System mit, was du von ihm erwartest. Ich habe jede meiner Konversationen mit so einem einleitenden Prompt begonnen:

>"You are a specialist in the programming language Rust and you are also a teacher in that language. I am a newbie who wants to learn Rust by developing an application.
>You shall guide me through that process. As a start, I want to know how a simple Rust program is structured, how I compile it and how I run it."

In beiden Fällen waren die Antworten extrem hilfreich. Mir wurde Beispielcode gezeigt und ich bekam Links auf die Webseiten, von wo ich Compiler und andere Tools herunterladen konnte.

Tatsächlich konnte ich, den Erklärungen 1:1 folgend, in beiden Fällen ein lauffähiges Programm erzeugen, starten und mein „Hello, World!“ bewundern.

Ab hier ist es übrigens sinnvoll, in der jeweiligen ChatGPT-Konversation zu bleiben und keinen neuen Chat zu starten. ChatGPT vergrößert seinen Kontext laufend. Wenn man in einer themenbezogenen Konversation bleibt, bezieht es die vorangegangene Anfragen und Antworten ein.

## Es wurde schnell schwierig

Die nächste Aufgabe war eigentlich auch einfach – wie ich dachte:

>"I want to add a function that takes two numbers and adds them together. I want to place this function in another file to keep the source files small."

In beiden Fällen konnte ich die Antwort auf diese Frage nicht 1:1 verwenden. Zwar wurde ein korrekter Code erzeugt, aber die Erklärung, wo ich die neue Datei erstellen musste und wie ich dafür sorgen sollte, dass es auch gefunden wird, war sowohl bei Rust als auch bei Go schlicht falsch.

Bei Go lieferte ChatGPT schnell eine korrigierte Fassung (ich hatte ChatGPT die Compiler-Fehlermeldung vorgeworfen), bei Rust hingegen musste ich die Originaldokumentation zur Hilfe ziehen.

Die Lösung war auch bei Rust schnell gefunden, aber hier wird schon die erste Lektion deutlich:

> **Was GPT produziert, muss nicht richtig sein.**

Ich möchte es gerne umformulieren und als **generelle Regel** für den Umgang mit derartigen KI-Tools ausdrücken:

> **Nutze *niemals* das Ergebnis von ChatGPT oder anderen LLMs, wenn du nicht in der Lage bist, die Richtigkeit selbst zu prüfen!**

## Der weitere Verlauf

In der Folge habe ich mir erklären lassen, wie man automatisierte Tests schreibt und wie man die Tests ausführt. Auch hier waren die Antworten von ChatGPT nicht 1:1 verwendbar. Trotzdem habe ich recht schnell die richtigen Lösungen gefunden.

Dann wurde es spannend. Ich habe ChatGPT mit meinem hypothetischen fachlichen Anwendungsfall bekannt gemacht:

>"I want to develop a web backend application in Go. Here are the requirements from my customer:
>Create a REST backend to record times. There should be a list of activities that are maintained in a database table. For each activity, a user can record any start and end times for each day through a POST endpoint. There is a GET endpoint to query the list of activities of a user for a specific day.

> As I have never written a web application in Go, please give me a list of at most three possible frameworks or libraries to use, together with pros and cons and an url to read more."

Ich habe mir bewusst von ChatGPT nicht den ganzen Code in einem Rutsch erzeugen lassen, denn es ging mir ja darum, selbst eine Anwendung zu entwickeln und dabei auch die Sprache zu lernen.

*(Meine bisherigen Versuche, komplette Lösungen über das normale ChatGPT Interface bauen zu lassen, waren nicht sehr erfolgreich. Vielleicht sind Tools wie <a href='https://github.com/geekan/MetaGPT' target='_blank'>MetaGPT</a> hier ja hilfreicher, das steht noch auf meiner Liste zum Ausprobieren. ChatGPT alleine kann das jedenfalls (noch) nicht.)*

Für jede Sprache habe ich dann eine Liste von Frameworks angeboten bekommen. Die aufgeführen Vor- und Nachteile waren für mich eher nichtssagend, daher habe ich jeweils die genannte Webseite aufgesucht und mir dort Codebeispiele angesehen. Dann konnte ich eine Wahl treffen.

## Datenbank lesen und schreiben

Als Datenbank habe ich Redis ausgewählt, einfach darum, weil es keine SQL-Datenbank ist und ich sie ebenfalls nicht kenne. In der Rust-Konversation habe ich mir Redis erklären lassen, was allerdings ohne einen Blick in die Dokumentation nicht verständlich gewesen ist.

Für beide Sprachen habe ich dann in der oben beschriebenen Weise nach Clients für Redis gesucht und bin ebenfalls fündig geworden.

Der nächste Schritt ging in beiden Fällen erfreulich einfach. Mithilfe von ChatGPT konnte ich Datenstrukturen erstellen und diese als JSON-String gewandelt in Redis ablegen und wiederfinden. ChatGPT hat mir auch geholfen, sinnvolle Keys für die Datenbank zu wählen. Allein durch diese Wahl (`TimeTracking:john_doe:237645`) habe ich einen Einblick bekommen, wie Keys in Redis aufgebaut werden können.

Auch gelang es sehr gut, für das Lesen und Schreiben sinnvolle Tests zu erstellen. Ich habe jeweils beschrieben, was der Test machen soll und dann funktionierenden Code erhalten.

Ich schreibe deshalb „funktionierend“, weil ich ziemlich sicher bin, dass der Rust-Code, der hier produziert wurde, nicht besonders elegant ist. Rust kennt eigentlich funktionale Elemente, sodass man nicht mit einem veränderbaren Array und einer simplen Schleife arbeiten müsste.

## Die Web-Schnittstelle

Als letzten Schritt habe ich mir dann helfen lassen, Web-Endpunkte zu erstellen. Einen GET-Endpunkt habe ich mit Rust und Go leicht bauen können, der POST-Endpunkt bei Rust hat aus irgendeinem Grund nicht funktioniert und bei Go fehlte mir am Ende die Zeit, auch das fertig zu bekommen. Ich bin aber sicher, dass das bei Go problemlos geklappt hätte, denn, so hässlich Go-Code auch aussieht, es ist im Grund ziemlich leicht, in der Sprache zu programmieren.

Nach nur 2-3 Stunden habe ich das jeweilige Experiment für beendet erklärt.

## Zusätzliche Hilfe durch codeium

Über ein Problem bin ich während meines Experiments mehrfach gestolpert. Ich habe manchmal den von ChatGPT erzeugten Code verändert. Teilweise, weil es notwendig war, um Fehler zu korrigieren, manchmal aber auch, um Features einzubauen, deren Erstellung mir aufgrund des bisherigen Lernerfolgs möglich erschienen ist.

In jedem Fall hat die Konversation davon natürlich nichts mitbekommen. Und ich habe auch nicht den gesamten Code wieder zurückgespielt (was ich natürlich hätte tun können).

An der Stelle hat mir Codeium geholfen, ebenfalls ein KI-Entwickler-Tool, das zur Familie der „code completions“ gehört. Deren bekanntester Vertreter ist GitHub Copilot. Codeium ist in den Code-Editor integriert, liest den aktuellen Code und erzeugt dazu passende Ergänzungen. Das hat mir sehr geholfen, die Lücken zu ergänzen, die ChatGPT natürlicherweise gelassen hat. Diese beiden Tool-Welten passen also sehr gut zusammen und ergänzen sich.

## Fazit

Drei Feststellungen kann ich nach der Zeit mit ChatGPT, Rust und Go machen:
1. Es geht erstaunlich schnell, sich mithilfe der KI in völlig neue Technologien einzuarbeiten. ChatGPT alleine reicht zwar nicht aus, aber es gibt viele Anhaltspunkte, sodass danach die Dokumentation des Herstellers i. d. R. ausreicht, die Lücken zu füllen. Ich war jeweils nach etwa 2-3 Stunden soweit, dass die Anwendung grundsätzlich lief!
2. Ohne grundsätzliche Programmierkenntnisse wäre ich nicht zum Ziel gekommen. Zwar wusste ich nicht, wie automatisierte Tests in Rust oder Go geschrieben werden, aber grundsätzlich ist mir das in vielen anderen Sprachen geläufig und somit war die Transferleistung möglich. Die Erklärungen alleine waren teilweise sehr dünn, obwohl ich explizit um Anleitung gebeten habe (natürlich hat ChatGPT, wie man es gewohnt ist, viel “gesagt”, aber meistens wiederholt es sich schlicht).
3. Ein perfekter Go- oder Rust-Entwickler wird man auf diese Weise nicht. Bei Go kommt man weiter als bei Rust, weil Rust aufgrund des deutlich komplexeren Typsystems viele Fallstricke bereithält, aber auch der produzierte Go-Code hat vermutlich bestenfalls Anfängerqualitäten.

Was bleibt: Ich empfehle jedem Entwickler sehr, ChatGPT in die tägliche Arbeit zu integrieren. Wie oft braucht man Hilfe zu einer bestimmten Fragestellung? ChatGPT ist so etwas wie ein „Stack Overflow-Forum“ auf Zuruf (auch dort sind die Lösung ja nicht immer korrekt). Die Trefferquote wird bei weiter verbreiteten Sprachen wie Java oder Kotlin, C#, JavaScript, TypeScript oder auch Python noch viel bessere Ergebnisse liefern.

Man ist in jedem Fall deutlich schneller, wenn man auf die neuen Tools nicht verzichtet. Ich bin sehr gespannt, wie sich ChatGPT oder auch spezielle Lösungen von anderen Herstellern weiterentwickeln werden.

KI-Tools zum Lernen neuer Programmiersprachen: Ein Erfahrungsbericht

In meinem [letzten Blogartikel](https://www.codecentric.de/wissens-hub/blog/ki-tools-zum-lernen-neuer-programmiersprachen-ein-erfahrungsbericht) habe ich geschrieben, was KI-Tools wie ChatGPT heute schon leisten können, wenn es darum geht, fachliche Anwendungen in ausführbaren Programmcode zu übersetzen.

Ich habe erfahren, dass die Ergebnisse zwar noch nicht zu 100 % korrekt sind, sondern immer noch überprüft und in vielen Fällen angepasst werden müssen. Aber trotzdem ist heute schon die Arbeitserleichterung so groß, dass ich nicht mehr auf den Einsatz solcher Hilfsmittel verzichten möchte. Ebenso wenig übrigens, wie ich auf meine leistungsstarke IDE verzichten möchte, die mir bei der Erstellung von Code auf andere Weise hilft.

Wir stehen erst ganz am Anfang dieser Entwicklung. ChatGPT und andere LLMs (LLM=large language model) befinden sich gerade in der Wachstums- und Ausprobierphase. Ich kann mir gut vorstellen, dass z. B. eine Firma wie JetBrains daran arbeitet, eine speziell auf Programmieren in Kotlin trainierte Lösung bereitzustellen, die fehlerfreien Code auf Basis normalsprachlicher Anweisungen erstellt. Google wird sicher dasselbe für Go tun, oder Microsoft für .NET und C#.

Werden wir also demnächst überflüssig? Braucht es bald gar keine Programmierer mehr, weil jeder Nutzer oder Product Owner selbst mithilfe dieser Systeme die gewünschten Anwendungen erstellen kann?

_(Image generiert mit `stable diffusion`)_

## Die Suche nach dem „Citizen Developer“

Es hat immer wieder Ankündigungen gegeben, dass diese oder jene Technologie professionelle Entwickler überflüssig machen würde. Bei der ältesten dieser Ankündigungen, von der ich mal gelesen habe, ging es um COBOL: Mit dieser Programmiersprache, deren Syntax der normalen englischen Ausdrucksweise angelehnt ist, sollten Business-Menschen selbst ihre Programme und Datenabfragen schreiben können. Was meines Wissens aber nie passiert ist. In den Jahrzehnten danach wurden unter anderem zu Visual Basic, Microsoft Access, Power Builder, Blue Prism oder AWS Amplify, Google App Sheet oder anderen Low-Code-Plattformen vergleichbare Ankündigungen gemacht.

Fakt ist: Ich habe noch keinen „Citizen Developer“ in großem Stil gesehen. Ein gutes Beispiel hierfür ist MS Access, nach meiner Wahrnehmung das erfolgreichste Low-Code-Tool bisher. Natürlich wurden in vielen Abteilungen Access-Lösungen in sehr unterschiedlicher Größe von Nicht-Informatikern erstellt. Doch sobald diese Lösungen mehrere Jahre benutzt und weiterentwickelt werden, treten die normalen Probleme jeder Softwareentwicklung auf:
* Die Anwendung wird komplexer, die Wartung und Weiterentwicklung zunehmend schwerer.
* Sobald die wesentliche, Wissen tragende Person die Abteilung oder das Unternehmen verlässt, geht sehr viel Know-how verloren, das die übrigen Kolleginnen und Kollegen in der Regel nicht haben.
* Sobald die Datenmenge eine gewisse Größe überschritten hat, wird die Anwendung spontan langsamer.
* Auf neue Access-Versionen zu wechseln, ist häufig mit aufwändigen Umbaumaßnahmen verbunden.
* und so weiter …

In die Jahre gekommene, große Access-Lösungen wurden meistens entweder abgeschafft oder irgendwann in die Hände der IT-Abteilung des Unternehmens gegeben – und dort abgeschafft.

Ich glaube, dass es hilfreich und sinnvoll ist, derartige Low-Code-Systeme für Prototypen oder Experimente zu verwenden, oder um spontan und unaufwändig eine Ad-hoc-Lösung für ein akutes Problem zu erstellen. Aber geschäftskritische Anwendungen benötigen eine entsprechende Vorbereitung und professionelle Begleitung. Zumindest ist es so bis heute.

## Übertragen auf KI-Tools zur Softwareentwicklung

Ich denke, dass wir bei KI-Tools zur Softwareentwicklung einen ähnlichen Fall haben. Im Moment sind die Systeme zwar noch nicht so weit, dass sie ganze Anwendungen erstellen können – aber das ist nur eine Frage der Zeit. Demnächst wird es so sein, dass man einem LLM sagen kann, was die Software können soll, und das System wird kompletten Code ausspucken, oder sogar die Lösung direkt in den Kubernetes-Cluster oder das Serverless-Cloud-Environment installieren. Keine Frage, das wird kommen, und auch früher, als manch einer glaubt oder hofft. Dass diese Systeme jetzt schon so gut sind, dass man ohne großes Vorwissen in zwei bis drei Stunden eine lauffähige Anwendung bauen kann, zeigt das sehr deutlich (siehe [meinen letzten Blogartikel](https://www.codecentric.de/wissens-hub/blog/ki-tools-zum-lernen-neuer-programmiersprachen-ein-erfahrungsbericht) zu diesem Thema).

Ich persönlich erwarte allerdings eine ähnliche Entwicklung wie bei den bisherigen Ankündigungen zum Citizen Developer: Es werden schnell und unaufwändig Anwendungen gebaut. Aber sobald sie komplex werden, häufig geändert werden müssen oder einfach sehr lange leben, muss es jemanden geben, der oder die die Anwendung mit professionellen Kenntnissen betreut.

## Von der Kunst, Anforderungen zu beschreiben

Jeder, der oder die schon einmal zu einer komplexen Fragestellung versucht hat, mit dem Fachbereich die wirklich *exakten* Anforderungen zu ergründen, weiß, dass es eine bestimmte Arbeitsweise und viel Erfahrung und Ausbildung braucht, um Edge-Cases und andere Feinheiten greifen zu können. Es dauert lange und erfordert viel Geschick, um eine Anforderung vollständig zu definieren.

Business-Analysten wird es also immer weiter geben (müssen). Doch auch mithilfe von guten Business-Analysten erleben wir häufig, dass erst beim Codieren – dem Übertragen der verbalen Beschreibung in eine unzweideutige, formale Schreibweise – Lücken in eben dieser Beschreibung sichtbar werden.

Normale Sprache ist in vielen Fällen zu mehrdeutig, schwammig oder – wenn man das Problem wirklich vollständig beschreiben möchte – zu langatmig, als dass es praktikabel wäre, komplexe und völlig neue Aufgabenstellungen ausschließlich damit zu beschreiben. Formalisierte Sprachen sind in der Regel besser geeignet, komplexe Sachverhalte auszudrücken. Die mathematische Formelsprache ist dafür ein gutes Beispiel.

Nur braucht man dafür eben auch eine Ausbildung. Und diese Ausbildung wird künftig Teil des Berufsbildes „Softwareentwickler“ sein, da bin ich sicher.

Ebenso ist es für Laien meist äußerst schwierig, vollständige Tests zu formulieren. Wenn aber die Software selbst in großen Teilen nicht mehr von einem Menschen mit dessen Verständnis erstellt wird, dann ist es nochmal so wichtig, das korrekte Funktionieren der Software sorgfältig zu testen.

Vielleicht übertragen wir als Software Developer demnächst Anforderungen nicht mehr in Programmcode, sondern in eine andere Formelsprache, die dann ausführbare Tests erzeugt. LLMs können dann „solange programmieren, bis alle Tests grün sind“.

In jedem Fall können wir uns als Entwicklerinnen und Entwickler mittelfristig nicht mehr darauf zurückziehen, „nur Code zu schreiben“. Ein großer Teil dieses Codes wird in Zukunft nicht mehr von einem Menschen geschrieben werden.

## Fazit

Die Arbeitsweise eines Entwicklers, einer Entwicklerin wird sich ändern, das steht wohl fest. Aber das ist im Berufsbild „Software Developer“ immer schon Teil des Deals. Ich habe mal gelesen, dass die allerersten Programmierer schon die Erfindung eines Assemblers unnötig fanden, da man den Code ja auch direkt in Maschinensprache eingeben kann. Assembler waren ihnen damals viel zu „hochsprachig“ und zu wenig technisch. Das war vermutlich die erste Auseinandersetzung darüber, was einen „Real Programmer“ auszeichnet.

Vielleicht (be-)schreiben Developer in der Zukunft nur noch die Requirements und LLMs programmieren dann einen Großteil der Software. Viele Standardaufgaben werden demnächst sogar komplett von LLMs erstellt. Aber darauf freue ich mich, ehrlich gesagt. Ich habe wirklich keine Lust, die 100. Login-Maske mit immer gleicher Logik zu schreiben, oder die exakte Spezifikation von OAuth2 nachzulesen, wenn mir ein Tool das direkt richtig erzeugen kann.

Wird es dadurch weniger Developer geben? Ich glaube das nicht. In den 80er und 90er Jahren, vor den zig Million kostenlosen Frameworks der Open-Source-Bewegung, musste man jede Bibliotheksfunktion entweder teuer einkaufen oder – häufiger – selbst schreiben. Damals haben Entwickler und Entwicklerinnen stundenlang immer wieder ähnliche Datenstrukturen und Funktionen entwickelt, die heute selbstverständlich zur Grundausstattung einer jeden Programmiersprache gehören.

Haben wir heute weniger Entwickler als damals? Benötigen wir weniger Entwickler als damals?
Eher im Gegenteil.

Ich bin gespannt.

## Weitere Informationen

Wer tiefer in diese Thematik einsteigen möchte, dem empfehle ich die Blog-Serie meines Kollegen Uwe Friedrichsen, der sich ebenfalls und sehr intensiv genau mit dieser Frage auseinandergesetzt hat: <a href='https://www.ufried.com/blog/chatgpt_already_knows/' target='_blank'>ChatGPT already knows</a>

Ersetzt KI die Softwareentwickler?

Der Klimawandel sorgte Ende 2023 für Dauerregen und Überschwemmungen. Nach zwei zu trockenen Jahren haben wir jetzt in Deutschland ein viel zu nasses Jahr. Keine Frage, wir müssen etwas tun! Unter dem Stichwort <a href='https://de.wikipedia.org/wiki/Green_IT' target='_blank'>Green IT</a> gibt es zunehmend Initiativen und Bestrebungen, von Seiten der IT dem Klimawandel entgegen zu wirken. In diesem Artikel werde ich beleuchten, wie die Wahl der Programmiersprache einen signifikanten Einfluss auf den Ressourcenverbrauch von Anwendungen haben kann, ohne Kompromisse eingehen zu müssen, und zwar mit der Programmiersprache *Rust*.

## Virtuelle Maschinen überall

Wir bei codecentric erstellen sehr häufig Geschäftsanwendungen für unsere Kunden. Diese Anwendungen sind in den allermeisten Fällen als Web-Anwendung aufgebaut, bestehend aus einem Frontend, meist in JavaScript oder TypeScript geschrieben, und einem Backend. In vielen Fällen läuft dieses Backend in einer Java Virtual Machine und ist in Java oder Kotlin, manchmal auch in Scala geschrieben. Als Framework kommt in vielen Fällen Spring Boot zum Einsatz.

Cloud-native Backends sind dagegen häufig in JavaScript oder TypeScript geschrieben und verrichten als Serverless Functions (z. B. AWS Lambdas auf Node.js) ihren Dienst.

Diese Backends sind dabei meistens nicht auf Performance und geringen Ressourcenverbrauch optimiert, sondern darauf, einfach, schnell und mit hoher Qualität entwickelt zu werden. Außerdem sollen sie so lesbar sein, dass man die Anwendungen auch nach Jahren noch leicht warten und verändern kann.

Die Programme sind mit Programmiersprachen geschrieben, die zur Laufzeit von eine virtuellen Maschine (JVM oder Node.js) ausgeführt werden. Diese virtuellen Maschinen haben einen Laufzeit-Overhead auf die Anwendung, da der Code zum Teil interpretiert und nicht von den Prozessoren der Infrastruktur direkt ausgeführt wird. Die Speicherverwaltung erfolgt außerdem zur Laufzeit per Garbage Collection.

Mit *Rust* (<a href='https://www.rust-lang.org/' target='_blank_'>rust-lang.org</a>) und *Go* gibt es seit ein paar Jahren zwei moderne Programmiersprachen in den Top 20 (<a href='https://www.tiobe.com/tiobe-index/' target='_blank'>des Tiobe Index</a>), die nicht auf einer virtuellen Maschine basieren, sondern direkt in Maschinensprache kompiliert werden. Anders als C und C++ hingegen erlauben beide Sprachen dabei das plattformunabhängige Entwickeln (*Write once, run anywhere*), das kennzeichnend ist für moderne Softwareentwicklung. Rust kommt dabei sogar ohne eine Garbage Collection zur Speicherverwaltung aus und erlaubt außerdem einen modernen Programmierstil, wie man ihn sonst nur bei Kotlin oder Scala findet.

Gute Gründe, sich diese Sprache einmal anzusehen.

## Ist Rust besser?

Wenn mich meine Kollegen fragen würden, was man mit Rust machen kann, das man nicht auch mit Java, Kotlin oder TypeScript machen kann – jeweils bezogen auf unseren Anwendungsfall bei codecentric –, dann muss ich ehrlicherweise antworten: Nichts.

Bei der reinen Softwareentwicklung bietet Rust keinen signifikanten Vorteil. Es gibt sogar einen (kleinen) Nachteil, denn die spezielle Form der Speicherverwaltung bei Rust, der (<a href='https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html' target='_blank'>Borrow Checker</a>), zwingt der Entwicklerin etwas mehr Arbeit und Nachdenken auf.

Wenn man aber die Frage umkehrt (Was kann man in Java, Kotlin oder TypeScript machen, das man nicht auch in Rust machen könnte?), dann kann kann man ebenfalls antworten: Nichts. Es gibt viele gute Frameworks, und auch das grundsätzliche Programmiermodell ist ebenso modern wie bei Kotlin oder TypeScript (Java hinkt hierbei tatsächlich etwas hinterher).

Daher habe ich ein Experiment angestellt und zwei funktionsgleiche Web-Backends in unterschiedlichen Sprachen und Frameworks geschrieben, um diese miteinander zu vergleichen.

## Der Versuchsaufbau

Zuerst habe ich eine Postgres-Datenbank erstellt, dort eine Tabelle angelegt und insgesamt 10 Mio. Records hineingelegt. Warum so viele? Ich wollte in meinem Test zufällig auf die Einträge zugreifen und implizite Caching-Mechanismen des jeweiligen Frameworks ausschließen.

Dann habe ich zwei funktional identische Backends gebaut, mit diesen Fähigkeiten:

- über den Endpunkt `/read/<id>` lädt man einen Record aus der Datenbank und erhält diesen im JSON-Format. Hierbei wird der Path-Parameter `<id>` (implizit) als Zahl validiert.
- Zusätzlich muss man sich bei dem Aufruf mit einem API-Key authentifizieren. Dieser Key wird entweder als Header (`X-API-Key`) oder als Query-Parameter (`?api_key=`) mitgegeben.

Im Kleinen entspricht das einem üblichen Web-Backend, wie wir es für unsere Kunden erstellen.

Als klassischen Kandidaten habe ich mich für eine Spring-Boot-Anwendung entschieden, mit Spring Data JDBC für den Zugriff auf die Postgres DB. Als Sprache nutze ich Kotlin. Exakt diesen Tech-Stack verwenden wir bei codecentric immer wieder in Kundenprojekten.

Als Vergleich mit Rust habe ich mich für das Framework <a href='https://rocket.rs/' target='_blank'>Rocket</a> entschieden. Mit Rocket kann man elegant und deklarativ Web-Backends schreiben. Ein SQL-Client gehört auch hier zum „Lieferumfang“.

## Vergleich des Codes

Spring Boot arbeitet objektorientiert mit automatischer „Verdrahtung“ der einzelnen Objekte untereinander. Rocket hingegen ist funktional aufgebaut. So wundert es nicht, dass das jeweilige Grundgerüst der beiden Anwendung sehr unterschiedlich ist.

Wenn man sich aber die reinen fachlichen Funktionen ansieht, stellt man große Ähnlichkeiten fest. Hier ist der Rust-Zugriffscode auf die Datenbank:
```Rust
pub async fn read_dummy_with_id(
 conn: &mut Connection<DummyDb>,
 id: i32,
) -> Result<DummyData, Error> {
 sqlx::query_as::<_, DummyData>("SELECT * FROM dummy_data WHERE id = $1")
 .bind(id)
 .fetch_one(&mut ***conn)
 .await
}
```

Und hier das Pendant in Kotlin:
```Kotlin
 fun readDummyWithId(id: Int): MutableList<DummyData> =
 jdbcTemplate.query(
 "SELECT * FROM dummy_data WHERE id = ?",
 arrayOf(id),
 intArrayOf(java.sql.Types.INTEGER),
 ) { rs, _ ->
 DummyData(
 id = rs.getInt("id"),
 value = rs.getString("value"),
 odd = rs.getBoolean("odd"),
 divisibleBy3 = rs.getBoolean("divisible_by_3"),
 visited = rs.getBoolean("visited")
 )
 }

```

In beiden Fällen wird ein SQL-Statement als String mit einem Platzhalter erstellt, die `id` übergeben und das Ergebnis in eine Datenstruktur gepackt. Bei Spring Boot musste das selbst machen, bei Rocket gab es dafür sogar einen Automatismus.

Auch der Controller-Code, um aufgrund einer HTTP-Anfrage das Ergebnis dieser Suche in eine HTTP-Antwort zu verwandeln, sieht im Prinzip sehr ähnlich aus. Hier der Code in Rust mit Rocket:
```Rust
#[get("/read/<id>")]
async fn read(
 mut db: Connection<DummyDb>,
 id: i32,
 _api_key: ApiKey,
) -> Result<Json<DummyData>, Status> {
 let res = read_dummy_with_id(&mut db, id).await.map_err(|e| match e {
 RowNotFound => Status::NotFound,
 _ => Status::InternalServerError,
 })?;

 Ok(Json(res))
}
```

Und hier in Kotlin mit Spring Boot:
```Kotlin
 @GetMapping("/read/{id}")
 fun read(@PathVariable id: Int): ResponseEntity<DummyData> {
 val res = dummyRepository.readDummyWithId(id)

 return if (res.isNotEmpty())
 ResponseEntity.ok(res.first())
 else
 ResponseEntity.notFound().build()
 }

```

In beiden Fällen wird das Ergebnis der o. g. Funktion genommen und analysiert. Gibt es eines, wird es zurückgegeben, sonst kommt ein `NotFound` Error (404). Bei Rust gibt es sogar noch einen `InternalServer` Fehler (500), wenn es bei dem Zugriff auf die DB ein Problem gibt. Das Passiert bei Kotlin mit Spring Boot auch, ist dort aber nicht explizit zu sehen. Geschmacksache.

Als letztes schauen wir uns noch den Code an, der den Api Key prüft.

Hier in Rust als Rocket Request Guard:
```Rust
 async fn from_request(request: &'r Request<'_>)
 -> Outcome<Self, Self::Error> {
 let api_key = match request.headers().get_one("X-API-Key") {
 Some(api_key) => api_key.to_string(),
 None => match request.query_value::<String>("api_key") {
 Some(Ok(key)) => key,
 _ => return request::Outcome::Error((Status::Unauthorized, ())),
 },
 };

 if api_key == "valid_key" {
 request::Outcome::Success(ApiKey(api_key))
 } else {
 request::Outcome::Error((Status::Unauthorized, ()))
 }
 }

```
 vs Kotlin als Spring Boot Filter:
```Kotlin
 override fun doFilterInternal(
 request: HttpServletRequest,
 response: HttpServletResponse,
 filterChain: FilterChain
 ) {
 val apiKey = request.getHeader("X-API-Key")
 ?: request.getParameter("api_key")

 if (apiKey == "valid_key")
 filterChain.doFilter(request, response)
 else
 response.sendError(HttpServletResponse.SC_UNAUTHORIZED)
 }

```

In beiden Fällen sieht man gut, dass zuerst in den Headers, dann in dem Query String nach dem API-Key gesucht wird.

Insgesamt ist der Rust-Code etwas umfangreicher und insbesondere das Fehlerhandling expliziter. Das gilt auch für die verwendeten Typen, insbesondere die Deklaration der Ergebnistypen einer Funktion. Rusts große Stärke, seine automatische Speicherverwaltung ohne Garbage Collection, erfordert leider etwas mehr Schreibaufwand.

Auch befinden sich hier die Frameworks sicher noch nicht in einem so ausgereiften Zustand wie Spring Boot, weswegen schwer lesbare Konstrukte wie `.fetch_one(&mut ***conn)` notwendig sind.

Doch wenn man beide Sprachen kennt, so stellt man fest, dass der Code in jedem Fall leicht verständlich und ebenso leicht zu warten ist. Aus meiner Sicht gibt es hier keinen *signifikanten* Unterschied.

## Und zur Laufzeit?

Nachdem beide Versionen liefen (was in beiden Fällen ungefähr gleich lange gedauert hat), war es für die Kontrahenten an der Zeit, in den Ring zu steigen. Hierzu habe ich von beiden Versionen eine lauffähige Anwendung gebaut und diese unter Last gesetzt. Dabei habe ich eine Minute lang insgesamt 600 Requests abgesetzt, 10 Requests pro Sekunde.

### Größe der Anwendung als Datei

Mit `./gradlew bootJar` habe ich aus dem Spring-Boot-Projekt eine ausführbare Datei erstellt. Die Rust-Anwendung habe ich mit `cargo build --release` gebaut.

Dateigröße:
- Kotlin: 30 MB \*)
- Rust 7,7 MB

*\*) Zu dieser Dateigröße kommt noch der Platz für die JVM hinzu, die i. d. R. zwischen 80 und 120 MB groß ist. Das ist z. B. wichtig, wenn man die Anwendung in einem Docker-Image ausliefert.*

Beide Dateien enthalten alles, was man zur Laufzeit braucht und können einfach gestartet werden (bei Kotlin natürlich mit der JVM). Beide Anwendung liefen nicht in einem Docker-Container, sondern in nativer Technologie auf meinem Laptop.

### Speicherverbrauch zur Laufzeit

In den ersten Sekunden nach dem Start des Lasttests sieht man in beiden Fällen, dass der Speicherverbrauch ansteigt. Nach wenigen Sekunden hat er sich dann „eingependelt“ und steigt nicht mehr weiter.

Speicherverbrauch (Memory):
- Kotlin: 226 MB
- Rust: 5,8 MB

### Antwortzeitverhalten

Bei der reinen Antwortzeit gibt es so gut wie keinen Unterschied. Die Messwerte schwanken zwischen 1 msek und im Maximum 100 msek, mit einem Durchschnitt von 5,8 msek und einem Median von 5 msek. Selbst das 99er Percentil liegt unter 20 msek.

Ich vermute, dass die Zeit im Wesentlichen in der Datenbank und nicht im Backend verbraucht wird.

### CPU-Verbrauch zur Laufzeit

Anders sieht es allerdings beim CPU-Verbrauch aus. Die absoluten Zahlen sind sicher nicht aussagekräftig, vermutlich aber die relativen.

CPU-Auslastung:
- Kotlin: 4,5 % (stark schwankend von 3 % bis 7 %)
- Rust: 0,4 % (ziemlich gleich bleibend)

Summe CPU-Zeit über die Ausführung:
- Kotlin 9,43 sek
- Rust: 0,27 sek

Anzahl Threads:
- Kotlin: 47
- Rust: 11

## Die Auswertung

In allen Messwerten hatte die in Rust geschriebene und nativ kompilierte Fassung deutlich die Nase vorn. Hier noch einmal alle Werte im Vergleich:

| |Kotlin|Rust|Prozentsatz|
|---|---|---|---|
|**Dateigröße** (MB)|30|7,7|26 %|
|**Memory** (MB)|226|5,8|3 %|
|**Antwortzeit** (msek)|5|5|100 %|
|**CPU Auslastung** (%)|4,5|0,4|9 %|
|**CPU Zeit** (sek)|9,43|0,27|3 %|
|**Threads**|47|11|23 %|

Auch wenn diese Messwerte sicher nicht absolut zu verstehen sind, so kann man doch daraus folgern, dass ein Backend, das in Rust mit Rocket geschrieben ist, deutlich kleiner ist, viel weniger Speicher und viel weniger CPU verbraucht als ein vergleichbares in JVM-Technik.

## Fazit

Die entsprechende Erfahrung vorausgesetzt, schreibt man eine Web-Anwendung in Rust mit Rocket ähnlich leicht oder schwer wie in Kotlin mit Spring Boot. Auch in puncto Wartbarkeit erscheinen beide Ansätze vergleichbar. Beide Sprachen erzwingen Typsicherheit und automatische Speicherverwaltung. Automatisierte Tests (Unit- und Integrationtests) sind mit von der Partie. Beide Ansätze erlauben es, sichere und robuste Anwendungen zu schreiben.

Die Lernkurve bei Rust ist sicher etwas heftiger als bei Kotlin, aber wenn man die grundsätzlichen Konzepte verstanden hat, geht es auch hier schnell voran, das kann ich aus eigener Erfahrung sagen.

In puncto Laufzeitverhalten trennen beide Ansätze hingegen Welten. Wenn man mehrere Web-Anwendungen in einem Rechenzentrum oder in der Cloud betreibt, so kann man mit Rust vermutlich das drei- bis vierfache an Funktionalität aus derselben Infrastruktur herausholen, vielleicht sogar noch mehr. Das bedeutet, man kann Server sparen. Und Server sparen bedeutet CO2 sparen (neben dem reinen Kostenfaktor).

Mit Rust gibt es (endlich) eine moderne und hinreichend weit verbreitete Programmiersprache, die die Leichtigkeit von Java oder Kotlin mit der Ressourcenschonung von C oder C++ verheiratet. Ein guter Ansatz, um als Softwareentwickler etwas für das Klima zu tun.

Für mehr Nachhaltigkeit – CO2 sparen mit Rust

In diesem Artikel bauen wir gemeinsam eine kleine „Two-Tier“-Web-Anwendung – komplett mit Browser-Frontend und HTTP-Backend. Um den Tech Stack klein zu halten, verwenden wir dafür nur eine Programmiersprache: Rust.
## Warum das Ganze und warum ausgerechnet Rust?

Wer schon einmal in einer modernen Web-Anwendung als Entwicklerin oder Entwickler „full stack“ unterwegs war, also sowohl im Frontend als auch im Backend gearbeitet hat, der weiß, dass der ständige Wechsel zwischen den Technologien anstrengend ist. Nehmen wir als Beispiel einmal einen ziemlichen Standardfall: Das Frontend ist in TypeScript geschrieben mit React als Komponenten-Bibliothek, das Backend in Java oder Kotlin mit Spring Boot als HTTP-Framework.

Bei jedem Wechsel muss man gefühlt das ganze Gehirn austauschen. Alles ist anders:
- die Sprache
- die Standardbibliothek
- das Typsystem
- das Build- und Dependency-System
- alle Librarys, die mir das Leben einfacher machen könnten
- das Paradigma (Beans/Objekte vs Komponenten/Hooks/Funktionen)
- die Art, Tests zu schreiben und auszuführen

und so weiter und so fort …

Obwohl es in vielen Fällen wirklich eine gute Idee ist, Features / Storys vollständig „von vorne bis hinten“ zu implementieren, ist in der Praxis dann doch häufig zu beobachten, dass erst das Backend oder erst das Frontend gebaut wird, und danach der Rest. Die ständigen Wechsel erschweren eine integrativere Arbeitsweise. Auch ist es nicht möglich, Code von der einen Seite zur anderen zu kopieren oder sogar eine selbst geschriebene Sammlung von Funktionen und Datenstrukturen in beiden Welten zu verwenden. Grund genug, sich nach einer Technologie umzusehen, die das kann.

Rust bietet sich hier an. Dass Rust sicher, stabil und schnell ist, wird vermutlich allgemein bekannt sein. Mit Rust ein Web-Backend zu schreiben, ist eine gute Wahl. Aber auch für das Frontend ist Rust bestens gerüstet. Anders als andere Ansätze, die ich mir angesehen habe (z. B. F# in [diesem mehrteiligen Tutorial](https://www.codecentric.de/wissens-hub/blog/tutorial-safe-stack-teil-1)) wird das Frontend nicht nach JavaScript übersetzt. Stattdessen nutzen Web-Frontends in Rust WebAssembly (Wasm).

Anders als die JavaScript Engine eines Browsers ist die Wasm-Runtime deutlich weniger komplex. Sie enthält zum Beispiel keine Garbage Collection – was perfekt zu Rust passt, denn die Sprache erfordert ja keine.

Damit ist Rust die einzige Alternative dazu, alles direkt in JavaScript oder vielleicht TypeScript zu schreiben oder (wie bei ClojureScript, Kotlin/JS oder F#) einen permanenten Spagat zwischen unterschiedlichen Welten machen zu müssen.

Wir werden in den nächsten vier Schritten gemeinsam eine lauffähige Anwendung erstellen, die natürlich nicht sehr viel tut, aber bereits viele Technologien abdeckt, die ihr bei eurer Full-Stack-Web-Anwendung brauchen werdet. Wenn ihr keine Lust habt, jeden Schritt von Hand mitzumachen, könnt ihr euch auch das fertige Projekt aus Github holen: <a href='https://github.com/goetz-markgraf/rust_fullstack_template' target='_blank'>https://github.com/goetz-markgraf/rust_fullstack_template</a>

In diesem Sinne: Let's get our hands rusty!
## Schritt 1: Den Workspace vorbereiten

Wir benötigen drei separate Rust-Projekte:
1. `frontend` – Anwendung 
2. `backend` – Anwendung
3. `shared` – Bibliothek

In der `shared`-Bibliothek werden in jenen Code unterbringen, der sowohl vom Frontend als auch vom Backend benutzt wird. Insbesondere definieren wir darin die „data transfer objects“ (DTOs), sodass Frontend und Backend stets zur Kommunikation untereinander dieselben Datenstrukturen verwenden und nicht auseinanderlaufen können.

Damit wir nicht mit drei losgelösten, einzelnen Projekten hantieren müssen (git, build etc.), erstellen wir einen <a href='https://doc.rust-lang.org/cargo/reference/workspaces.html' target='_blank'>Workspace</a>, in den wir die anderen Verzeichnisse einbetten. Dazu legen wir zunächst ein Verzeichnis für die gesamte Anwendung an:

```sh
mkdir my_awesome_app
cd my_awesome_app
git init
```

Den Namen (`my_awesome_app`) könnt ihr natürlich frei wählen. Sinnvollerweise stellen wir das ganze Projekt unter die Versionskontrolle von `git`.

Als Nächstes legen wir (leider von Hand) eine `Cargo.toml`-Datei in diesem Verzeichnis mit dem folgenden Inhalt an:

```toml
[workspace]
members = [
	"shared",
	"backend",
	"frontend",
	]
resolver = "2"
```

Hiermit sagen wir dem Buildsystem `cargo`, dass es drei Unterverzeichnisse mit Rust-Projekten geben wird. Die Angabe `resolver = "2"` ist notwendig, damit wir die aktuelle Rust-Edition `2021` nutzen können.

Jetzt können wir die drei Projekte anlegen:
```sh
cargo new frontend
cargo new backend
cargo new shared --lib
```

Die erfahrene Rust-Entwicklerin wird feststellen, dass
1. in den jeweiligen Projekten kein `.git`-Unterverzeichnis angelegt wird und
2. es dort auch keine `Cargo.lock`-Datei gibt.

Beides haben wir im Basisverzeichnis unseres Workspaces.

Da wir im Frontend Features verwenden werden, die es nur in der `nightly` Version von Rust gibt, müssen wir diese noch installieren und unser Projekt dafür markieren. Außerdem müssen wir sicherstellen, dass Wasm als target verfügbar ist:

```sh
rustup toolchain install nightly
rustup override set nightly
rustup target add wasm32-unknown-unknown --toolchain nightly
```

Selbst wenn ihr das schon einmal getan habt, dienen diese Befehle auch dazu, die entsprechenden Toolchains auf den aktuellen Stand zu heben.

Als letztes installieren wir noch <a href='https://trunkrs.dev/' target='_blank'>Trunk</a>. Dieses Tool macht das, was `vite` oder `webpack` für JavaScript machen: Zu Entwicklungszwecken stellt es einen Dev-Server (mit Hot-Reload) zur Verfügung, der das Frontend ausspielt. Gleichzeitig dient es auch als Erweiterung des `cargo`-Build-Systems, um später auslieferungsfähige Dateien zu erzeugen (`trunk build --release`).

## Schritt 2: Die einzelnen Projekte konfigurieren

Als Nächstes werden wir die jeweiligen Projekte mit den notwendigen Dependencys ausrüsten, bevor wir dann endlich im Schritt 3 Code schreiben können.

Wir wenden also nacheinander **in den jeweiligen Unterverzeichnissen** die folgenden Schritte an:

### shared/

Wir fangen mit der Bibliothek an, die geteilten Code enthalten soll. Dazu brauchen wir genau eine Dependency:

```sh
cargo add serde --features=derive
```

Die Bibliothek <a href='https://serde.rs/' target='_blank'>serde</a> ist der De-facto-Standard für das Serialisieren und Deserialisieren von Datenstrukturen.

### backend/

Dem Backend fügen wir als erstes die `shared`-Bibliothek hinzu:

```sh
cargo add --path=../shared
```

Dann natürlich `serde` und `serde_json`:

```sh
cargo add serde --features=derive
cargo add serde_json
```

Als letztes benötigen wir noch ein HTTP-Framework. Hier gibt es zum Glück eine große Auswahl. Ich habe mich für <a href='https://rocket.rs/' target='_blank'>Rocket</a> entschieden.

```sh
cargo add rocket --features=json
```

Wer möchte, kann jetzt noch weitere Dependencys hinzufügen, z. B. `anyhow`, aber für dieses Tutorial brauchen wir das nicht.

### frontend/

Im Frontend fügen wir auch zunächst die `shared`-Bibliothek sowie das bereits bekannte `serde` hinzu:

```sh
cargo add --path=../shared
cargo add serde --features=derive
cargo add serde_json
```

Dann brauchen wir ein Komponenten-Framework. Auch hier gibt es viel Auswahl. Sehr bekannt ist <a href='https://yew.rs/' target='_blank'>Yew</a>, das sich an `react` anlehnt. Eine Alternative ist <a href='https://leptos.dev/' target='_blank'>Leptos</a>, das in seiner Logik eher `solid.js` ähnelt. Ich habe mich für `leptos` entschieden:

```sh
cargo add leptos --features=csr,nightly
```

Was hat es mit dem `csr` auf sich? `Leptos` bietet im Feature `ssr`, ähnlich wie `next.js`, serverseitiges Rendering mit anschließender Hydration des Frontends. Da wir das aber für unser Beispiel nicht brauchen, haben wir das Feature-Set als "client side rendering" (`csr`) festgelegt. Das Feature `nightly` erlaubt uns, eine schönere Syntax zu verwenden, die es (noch) nur im `nightly` Rust gibt.

Als Letztes brauchen wir noch eine Möglichkeit, vom Frontend aus mit dem Backend zu sprechen, also einen HTTP-Client. Dazu nutzen wir `reqwest`. Und da es bei jedem Aufruf externer Ressourcen zu Fehlern kommen kann, fügen wir gleich noch `anyhow` hinzu, das das Fehlerhandling etwas einfacher macht:

```sh
cargo add reqwest
cargo add anyhow
```

## Schritt 3: Let's code!

Zeit, Rust-Code zu schreiben.

Zunächst bauen wir ein „frei fliegendes“ Frontend auf, also ein Frontend, das noch nicht auf das Backend zugreift. Das tun wir, um die Arbeit im Frontend in kleinere Häppchen zu zerteilen:

### Einfaches Frontend

Wir bauen eine erste, einfache Basis-Komponente. Dafür erzeugen wir die Datei `frontend/src/app.rs`:

```rust
use leptos::*;

#[component]
pub fn App() -> impl IntoView {
 view! {
 <div>
 <h1>{ "Hello, World!" }</h1>
 </div>
 }
}
```

Die Funktion `App` (ja, mit Großbuchstaben!) erstellt das DOM, das gleich in die Webseite eingefügt wird. Durch das Attribut `#[component]` wird alles Notwendige dafür bereitgestellt. Das `view!`-Makro hilft, HTML-Elemente zu erzeugen. Wer schon einmal mit `react` oder `solid.js` gearbeitet hat, der wird das Pattern wiedererkennen.

Dann müssen wir in der Datei `frontend/src/main.rs` unsere Basis-Komponente in das DOM einhängen:

```rust
use leptos::*;

mod app;

fn main() {
 mount_to_body(app::App)
}
```

Jetzt brauchen wir noch eine (weitgehend leere) HTML-Seite, in die unsere wunderbare Anwendung auch eingehängt werden kann. Dazu erstellen wir `frontend/index.html`:

```html
<!DOCTYPE html>
<html lang="en">
<head>
 <title>Rust Frontend</title>
 <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body></body>
</html>
```

Jetzt könnt ihr diesen Teil schon einmal ausprobieren. Aus dem `frontend/`-Verzeichnis heraus startet ihr einen Dev-Server mit:

```sh
trunk serve
```

Wenn alles richtig war, dann könnt ihr in einem Browser <a href='http://localhost:8080' target='_blank'>http://localhost:8080</a> öffnen. Dort findet ihr das allseits bekannte „Hello, World!“

![tutorial-rust-full-stack-hello-world.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/AhxkgdjjSMaynaoLgkGt)

Ändert gerne mal den Text und seht, dass beim Speichern direkt die neue Version angezeigt wird (Hot-Reload).

### Shared-Bibliothek

Jetzt fangen wir an, unser minimales Frontend mit dem Backend zu verknüpfen. Dazu brauchen wir als „Contract“ die Definition unseres DTOs. Das machen wir direkt in der Datei `shared/src/lib.rs`:

```rust
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
pub struct MessageDto {
 pub text: String,
}
```

Nichts Spannendes hier: Wir erstellen eine Datenstruktur mit einem (public) Field und sorgen über das Attribut dafür, dass `serde` daraus später JSON machen kann.

### Backend

Im Backend ersetzen wir den Inhalt der Datei: `backend/src/main.rs`:

```rust
extern crate rocket;

use rocket::{get, launch, routes};
use rocket::serde::json::Json;

use shared::MessageDto;

#[get("/api/message")]
fn index() -> Json<MessageDto> {
 Json(MessageDto { text: "Hello from Backend".to_string() })
}

#[launch]
fn rocket() -> _ {
 rocket::build().mount("/", routes![index])
}
```

Die Funktion `rocket()` ersetzt die `main()` Funktion (dafür sorgt das `#[launch]`-Attribut), in der unser HTTP-Backend konfiguriert und gestartet wird. Das Wichtigste hier ist das `routes!`-Makro, das unsere Handlerfunktion `index` erhält.

Bei `index()` sorgt das Attribut `#[get...]` dafür, dass eine bestimmte Route mit einer bestimmten Methode hier ankommt. Als Ergebnis der Funktion nutzen wir den `Rocket`-Datentyp `Json` (daher das `json`-Feature bei `Rocket`), und geben statisch eine Instanz unseres DTOs zurück. `Rocket` kümmert sich um das Umwandeln – unter Zuhilfenahme von `serde`.

Starten kann man das Backend wie bei Rust gewohnt mit `cargo run`. Das Backend hört auf den Port `8000`, was sich freundlicherweise nicht mit dem Frontend beißt.

Schaut gerne man auf die URL: `http://localhost:8000/api/message`.

Fertig ist das Backend, auf zur letzten Runde ...

### Erweitertes Frontend

Als Erstes sorgen wir dafür, dass der `trunk`-Dev-Server bestimmte Anfragen an das Backend weiterleitet. Dazu legen wir eine Konfigurationsdatei an: `frontend/Trunk.toml`:

```toml
[[proxy]]
backend = "http://localhost:8000/api"
```
(Ja, mit zwei `[[]]`! Warum, weiß ich nicht.)

Alle Anfragen, die der Dev-Server erhält und die mit `/api` beginnen, werden ab jetzt an unser Backend weitergeleitet.

Alles Weitere erfolgt in unserer `App`-Komponente (`frontend/src/app.rs`).

Wir brauchen zunächst eine Funktion, die unser Backend aufruft:

```rust
use anyhow::{anyhow, Result};

fn get_path_for(endpoint: &str) -> Result<String> {
 let window = web_sys::window()
 .ok_or(anyhow!("cannot retrieve window object"))?;
 let host = window.location().origin()
 .map_err(|_| anyhow!("cannot get origin"))?;
 Ok(format!("{}/{}", host, endpoint.trim_start_matches('/')))
}

async fn fetch_message() -> Result<String> {
 let response = reqwest::get(get_path_for("/api/message")?).await?;
 if response.status() != 200 {
 return Err(anyhow!("Failed to fetch message, error code {}.",
 response.status().as_str())
 );
 }
 let body = response.text().await?;
 let body = serde_json::from_str::<shared::MessageDto>(&body)?;
 Ok(body.text)
}
```

Die Funktion `fetch_message` ist dabei die entscheidende. Sie nutzt `reqwest`, um einen Call ans Backend abzusetzen. Damit wir die URL `localhost:8080` nicht hart kodieren müssen (die wäre ja in Produktion auch eine ganz andere), nutzen wir die Wasm-DOM-Bridge (`web_sys`) und holen uns in der Funktion `get_path_for` die gerade aktuelle URL, wie wir das in JavaScript auch tun können (`window.location.origin`).

Hier sieht man die Stärke von Rust: Damit zur Laufzeit keine Nullpointer-Exceptions auftreten können, die einem die Konsole zukleistern, muss man diese Fälle stets im Code abhandeln. Durch `anyhow` und die Verwendung von `?` können wir elegant die Fehler von unten nach oben weiterreichen. `ok_or` ist dabei der Wechsel von `Option` auf `Result` und mit `map_err` verwandeln wir einen Fehler in einen anderen, der für uns einfacher zu behandeln ist.

Jetzt müssen wir „nur noch“ diese Funktion aufrufen. `Leptos` kennt dafür das Konzept der Resource. Wir ersetzen also unsere `App()`-Funktion:

```rust
#[component]
pub fn App() -> impl IntoView {
 let message = create_resource(|| (), |_| async {
 fetch_message().await.map_err(|e| e.to_string())
 });

 view! {
 <div>
 <h1>{ "Hello, World!" }</h1>
 </div>
 <Suspense fallback=move || view!{ "Loading..." }>
 { move || match message()
 .unwrap_or(Ok("Loading ...".to_string())) {
 Ok(text) => view!{ { text } },
 Err(e) => view!{ { e } },
 }}
 </Suspense>
 }
}

```

Die Funktion `create_resource` nimmt zwei Parameter. Der erste ist eigentlich ein veränderlicher Wert, der für die eigentliche Ressource entscheidend ist. Das könnte z. B. eine eingegebene ID sein, zu der ein Datensatz geladen werden soll. Ändert sich die ID, wird der Request neu ausgeführt. Wir rufen unser Backend aber nur einmal auf, also geben wir ein leeres Lambda an: (`|| ()`).

Das zweite Lambda enthält den (asynchronen) Aufruf unserer `fetch_message`-Funktion und ein bisschen Fehlerhandling. Insbesondere machen wir mit `map_err` den Fehler lesbar, mehr brauchen wir aktuell nicht.

In der Variablen `message` haben wir jetzt ein Objekt vom Typ `Resource<(), Result<String,String>>`.

Innerhalb des `view!`-Makros können wir dann mit `message()` auf den Inhalt zugreifen. Die Ressource liefert uns dabei ein `Option<Result<...>>`, weil es ja sein kann, dass der `async` Call noch nicht zurück ist. Das entpacken wir mit `unwrap_or` und prüfen dann, ob wir einen Fehler oder eine richtige Antwort bekommen haben.

Das Ganze ist dann noch mit einem `<Suspense>`-Tag eingerahmt. Dieser dient dazu, dass, wenn die Resource noch nicht da ist, der `fallback` angezeigt wird. Das heißt, dass wir beim Entpacken der `Option` auch einfach `unwrap()` hätten nutzen können – aber sich `unwrap()` komplett oder zumindest weitgehend abzugewöhnen, ist sicher keine schlechte Übung.
## Schritt 4: Alles starten

Die Anwendung ist fertig, wir können starten. Für diejenigen, die nur das <a href='https://github.com/goetz-markgraf/rust_fullstack_template' target='_blank'>GitHub-Repo</a> ausgecheckt haben, hier noch einmal die Befehle zum Starten.

Im Ordner `frontend/`:
```sh
trunk serve
```

Im Ordner `backend/`:
```sh
cargo run
```

Dann Browser öffnen unter <a href='http://localhost:8080' target='_blank'>http://localhost:8080</a>:

![tutorial-rust-full-stack-full-application.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Gk1iCAHSRa6s1YwO53Qb)

Herzlichen Glückwunsch.

Wenn ihr eine Fehlermeldung sehen möchtet, dann stoppt das Backend und refresht das Frontend.
## Zusammenfassung

Wir haben gesehen, wie man mit wenigen Schritten eine Full-Stack-Basis aufbauen kann, die dazu geeignet ist, zu einer großen Anwendung erweitert zu werden.

Der Tech Stack ist kleiner als normalerweise, da man sowohl im Frontend als auch im Backend mit nur einer Sprache und einem Ökosystem unterwegs ist. Natürlich muss man die Besonderheiten von `Leptos` oder `Rocket` lernen, aber trotzdem sind Frontend und Backend ähnlicher, als das bei TypeScript und Kotlin der Fall wäre.

Und noch etwas: Ändert doch einmal in `shared/src/lib.rs` in der Struktur `MessageDto` den Namen des Feldes `text`. Ihr werdet sehen, dass euch der Compiler sowohl das Frontend als auch das Backend als fehlerhaft markiert, bis ihr überall auf die Änderung reagiert habt. Wer schon einmal lange suchen musste, nur um festzustellen, dass die Datentypen im Frontend und Backend nicht mehr passen, der weiß das zu schätzen.

Die Verwendung einer sicheren, schnellen, stabilen und leistungsfähigen Technologie (in diesem Fall Rust) in Frontend und Backend gemeinsam kann die Entwicklung moderner Software deutlich vereinfachen.

Viel Spaß mit Rust!

Tutorial: Full Stack Web App in Rust

**Kann man mit KI wirklich Anwendungen erzeugen, ohne selbst coden zu können, mit einem Bruchteil des Aufwands und der Zeit?**

"Gib dich dem *Vibe* hin! Erstelle Software nur mit natürlicher Sprache! GenAI ist der *Builder*. Hör auf, dich zu beschweren und fang mit builden an!" So oder so ähnlich liest man es neuerdings in den Sozialen Medien. 

Was ist dran an dem "vibe coding"? 

Der Begriff "vibe coding" wurde von [Andrej Karpathy in einem Tweet Anfang Februar 2025](https://x.com/karpathy/status/1886192184808149383) geprägt. Andrej war Direktor für Künstliche Intelligenz bei Tesla und hat davor und danach für OpenAI an ChatGPT gearbeitet. Sicher weiß der Mann, wovon er spricht.

In seinem Tweet beschreibt er, was er mit "vibe coding" meint: Sich nicht um den Code kümmern, sondern ausschließlich KI-gestützte Werkzeuge nutzen. Alle Vorschläge der KI immer annehmen, Fehlermeldungen 1:1 einfach an die KI geben und diese den Fehler beheben lassen. Er beschreibt diese Art, Software zu entwickeln, begeistert und in leuchtenden Farben.

Wichtig ist, den Begriff "vibe coding" abzugrenzen: Nicht jeder Einsatz von Generativer KI (GenAI oder einfach nur KI) ist "vibe coding". Wer Copilot, ChatGPT, Claude, aber auch Cursor oder Windsurf und so weiter nur als eines von vielen Werkzeugen nutzt, um Code zu schreiben, zu verändern oder zu verstehen, der ist noch lange kein "vibe coder". Mit diesem speziellen Begriff ist ausschließlich eine Arbeitsweise mit GenAI gemeint, bei der man sich gar nicht oder fast gar nicht um den erzeugten Code kümmert. Das ist dann die Aufgabe der KI.

Seit dem Tweet von Andrej Karpathy ist der Begriff “vibe coding” überall im Netz zu finden. Allerdings sind die Reaktionen häufig nicht besonders positiv. Die Memes reichen von Witzen:


![vibe-coding-meme1.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cm8kf56lwwnsv07up1g7z0psv)

bis zu eher katastrophalen Meldungen:

![vibe-coding-meme2.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cm8kf766mvs3g07un67a6fipb)

Wie kann das sein? Wieso kann etwas, das ein echter Profi derartig anpreist, eine so ablehnende Reaktion hervorrufen oder gar katastrophale Wirkung haben? Kommen diese Memes nur von Entwicklern, die um ihren Job fürchten?

Schauen wir einmal an dem Hype vorbei und werfen einen Blick darauf, welche Werkzeuge es gibt, was KI-gestützte Softwareentwicklung kann und was sie vielleicht auch (noch) nicht kann.

### Die Agenten kommen

GenAI à la ChatGPT – also einfach einen Prompt eingeben und eine Antwort erhalten – war gestern. Die nächste Generation von KI-Tools sind sogenannte Agentensysteme. Das sind Lösungen, die KI nutzen, um einen Plan zu erstellen, der dann Schritt für Schritt durch "klassische Tools" und auch KI abgearbeitet wird. Prominente Vertreter dieser Gattung für Softwareentwicklung sind [Cursor](https://www.cursor.com/), [Windsurf](https://codeium.com/windsurf) oder auch [V0](https://v0.dev/) und seit Neuestem auf [Github Copilot](https://github.com/features/copilot) mit dem Agenten-Modus.

Derartige Agenten-KI-Tools können selbstständig Programmcode lesen, Vereinbarungen in der Architekturdokumentation nachschlagen, Code entsprechend der Vorgaben erstellen oder ändern, Compile-Fehler korrigieren und auch Tests schreiben und ausführen.

Zwar kann eine solche Aktion etliche Minuten dauern (und viele Token in den KI verbrauchen, die viele Euro kosten), liefert dann aber bedeutend hochwertigere Lösungen als der "einfache" Dialog mit einer KI. Das kann im Einzelfall die Arbeit von Stunden oder vielleicht sogar Tagen ersetzen.

Ich persönlich erwarte, dass sich die Qualität der eigentlichen KI-Modelle (ChatGPT, Claude etc.) in der näheren Zukunft nicht deutlich weiter steigern wird, wohl aber die Qualität der Agenten, die KI mit klassischer Automatisierung kombinieren.

### Die Stärken und Schwächen von GenAI in der Softwareentwicklung

Ich arbeite seit über einem Jahr in Kundenprojekten mit Github Copilot und habe in meiner Freizeit bereits eine Menge an (Agenten-) KI-Werkzeugen ausprobiert. Daneben habe ich mich mit meinen Kolleginnen und Kollegen ausgetauscht, die ebenfalls Erfahrungen mit KI-unterstützter Entwicklung haben. Die Bilder decken sich:

Zu den **Stärken von GenAI / KI in der Softwareentwicklung** gehören demnach:

- **Übernehmen von repetitiven Aufgaben** Beispiele sind das wiederholte Füllen von Datenstrukturen oder Durchführen von Mappings, sowie das Aufsetzen von Grundgerüsten für Softwarekomponenten.
- **Zugriff auf gelöste Probleme** Damit ist gemeint, dass es in vielen Fällen schneller und nützlicher ist, eine KI nach einer Lösung für ein Problem zu fragen, als die Suchmaschine der Wahl anzuwerfen oder in Stackoverflow nachzuschauen. Besonders, wenn die KI Zugriff auf den eigenen Code hat (als Plugin in der IDE), ist die Lösung häufig besser auf die eigene Situation zugeschnitten als alles, was man im Netz finden kann.
- **Erzeugen von kreativen Lösungen** Manchmal liefert die KI für eine Aufgabe eine besonders effektive oder effiziente Lösung, an die man selbst gar nicht gedacht hätte. Mit dem oben vorgestellten V0 kann man sich z. B. Vorschläge für UI oder sogar ganze UX Flows erzeugen lassen.
- **Erstellen einzelner Module oder Funktionen** Ist eine gewünschte Funktionalität einfach und vollständig zu beschreiben, können KI-Lösungen hier eine Menge hilfreicher Programmzeilen bauen.

Das liest sich beeindruckend und das ist es auch. Generative KI ist in den letzten zwei Jahren extrem gut geworden – auch im Rahmen der Softwareentwicklung. Ist also der Hype um "vibe coding" gerechtfertigt? Ersetzt die KI im Agentensystem die Softwareentwickler?

Nun, um diese Frage zu beantworten, müssen wir auch einen Blick auf die Schwächen von KI werfen. Diese Liste gilt auch für Agentensysteme:

- **Beherrschen von Komplexität.** Wenn eine Software wächst, steigt die Menge an Informationen, Regeln, Absprachen etc., die berücksichtigt werden müssen, in der Regel nicht linear, sondern nahezu exponentiell. Eine KI kann diese Menge irgendwann nicht mehr berücksichtigen und beachten. Diese Schwäche gleichen die o. g. Tools durch immer größere Kontexte aus, sowie durch spezielle Dateien, die im Projekt liegen können, in denen man z. B. Coding Richtlinien hinterlegen kann. Komplexität ist also im Moment noch ein Problem, aber es kann in der Zukunft kleiner werden. Ich persönlich bin aber nicht davon überzeugt, dass an dieser Stelle KI den Menschen überholen wird. Mal sehen.
- **Korrekte Funktionsweise sicherstellen** KI versteht nicht, was sie selbst tut. Im Kern wird immer nur das nächste Wort oder das nächste Stück Code erzeugt. KI kann also niemals vollständig verhindern, dass Aktionen unerwünschte Nebenwirkungen haben. Je komplexer eine Anwendung aber ist, desto aufwändiger und fehleranfälliger ist es, manuell die korrekte Funktionsweise sicherzustellen. Automatisierte Tests können hier helfen, aber man muss in einem solchen Fall die Tests anders schreiben, als man es derzeit tut, um den selbst geschriebenen und damit bekannten Code zu testen.
- **Der Output von KI ist nicht deterministisch.** Die große Stärke von KI, nämlich die (gefühlte) Kreativität, ist gleichzeitig eine große Schwäche. Wie weiter oben gesagt, kann KI z. B. das Grundgerüst für neue Komponenten erstellen. Dabei ist es aber möglich bis wahrscheinlich, dass manche dieser Komponenten unterschiedlich strukturiert werden. Zwar funktionieren sie, aber sie sind nicht miteinander vergleichbar. Je öfter man dann diesen Code ändern lässt (z. B. durch neue Anforderungen), desto mehr driften die unterschiedlichen Code-Teile auseinander.
- **Wartbarkeit** Eng mit dem Punkt davor verbunden ist zunehmend auffällig, dass KI-generierter Code schwerer wartbar ist als Code, der einen vernünftigen 4-Augen-Review-Prozess durchlaufen hat. Das hat zur Folge, dass es nach dem "vibe coding" schwerer ist, die Anwendung zu ändern oder zu erweitern.
- **Berücksichtigung von Qualitätsanforderungen wie z. B. Betriebssicherheit, IT-Sicherheit, vernünftiger Umgang mit Ressourcen etc.** KI-Systeme haben anhand von Code aus dem Internet "programmieren gelernt". Ein großer Teil dieses Codes berücksichtigt die oben genannten Qualitätsanforderungen nicht (ausreichend) und die KI demnach auch nicht. Das liegt daran, dass ein Großteil des Programmierwissens der KIs aus Tutorials oder Anleitungen gezogen wird. Und in denen ist IT-Security oder ressourcenschonender Umfang häufig kein Thema. Besonders kritisch wird es, wenn jemand, der oder die selbst keine Ahnung von IT hat, eine Lösung ins Netz stellt, die genau diese Anforderungen nicht berücksichtigt hat. Potenzielle Angreifer haben so leichten Zugriff auf unsichere Systeme; die Folgen sind nicht abzuschätzen, aber möglicherweise gravierend. Das zweite oben dargestellte Meme zeigt dieses Problem deutlich. (Ich hoffe sehr, dass das nicht wirklich passiert ist.)

## Was ist denn nun richtig? KI einsetzen oder nicht?

Die vorherige Gegenüberstellung zeigt das aktuelle Dilemma. Manch einer sieht vor allem die Stärken und proklamiert den Untergang des Berufsstandes der Softwareentwickler, andere möchten KI am liebsten überhaupt nicht nutzen.

Ich denke, in beiden Standpunkten liegt ein Kern der Wahrheit. Ich persönlich würde folgende Bewertung vornehmen:

- Mithilfe von KI kann man sehr schnell und effizient *bestimmten* Code erzeugen.
- Es ist erstaunlich, wie gut und kreativ die Lösungen manchmal sind.
- Es macht Spaß, mit diesen Werkzeugen zu arbeiten, wenn man den Umgang einmal gelernt hat.

Aber: 

- Gerade bei großen Anwendungen (also eigentlich alle, die wir im Kundenauftrag erstellen) gerät man sehr schnell an Grenzen, wo die KI nur noch wenig helfen kann oder sogar Schaden anrichtet.
- Kaum jemand würde den Code 1:1 in Produktion übernehmen. In jedem Fall muss man sich den Code sehr gründlich und kritisch anschauen – kritischer, als man den Code einer Kollegin oder eines Kollegen prüfen würde.

## Hat Andrej Karpathy also unrecht?

Nein, hat er nicht. Denn die meisten Leute übersehen einen sehr wichtigen Satz in seinem Tweet: "*It's not too bad for throwaway weekend projects, but still quite amusing.*" Er selbst beschreibt "vibe coding" also als Methode und Werkzeug für **Wegwerfprojekte am Wochenende**. Kein Satz darüber, dass er hier an den echten, produktiven Einsatz denkt.

Das entgeht vielen offenbar.

Beachtet man die vorgenannten Risiken des vibe codings, sehe ich persönlich durchaus ein paar professionelle Einsatzgebiete:


- **Rapid prototyping** 
Mit Agenten-KI kann man sehr leicht Beispielanwendungen bauen, die viel mehr sind als reine Klick-Dummys. Man kann sie für Anwendertests einsetzen oder um Stakeholdern “anfassbare” Lösungsansätze zu präsentieren, nicht aber, um sie in Produktion zu bringen.
- **Ideen generieren** Gerade Tools, die auch UIs erzeugen, können sehr hilfreich sein, um in der Discovery Phase die Lösung iterativ zu erkunden.
- **Erstellen einzelner Code-Blöcke und Module** Gerade, wenn etwas mit ein paar Sätzen vollständig beschreibbar ist, können solche Tools auch produktiven Code erzeugen. Nur muss man ihn gründlich prüfen.

Und was ist mit den kühnen Behauptungen, dass KI die Softwareentwickler überflüssig macht?

Um die Frage zu beantworten schaue man sich am besten an, *wer* solche Behauptungen aufstellt und welche Ziele die Person verfolgt: Sind es es Toolhersteller, die das nächste KI-Werkzeug verkaufen wollen (wobei die meisten von ihnen mittlerweile vorsichtiger argumentieren)? Ist es die Geschäftsleitung, die einen Personalabbau begründen will? Sind es Menschen im Fachbereich, die von KI gehört haben, und die Lösungen eher morgen als übermorgen haben möchten? Oder sind es Anfänger in der Softwareentwicklung, die meinen, man könnte die Lernkurve auf diese Weise abkürzen?

Bisher jedenfalls habe ich keine solche Behauptung von einem erfahrenen Softwareentwickler oder einer Softwareentwicklerin gehört.

Nun könnte man sagen, das seien ja auch genau diejenigen, die ersetzt werden sollen. Das stimmt prinzipiell. Aber es sind auch die einzigen, die eine professionelle Einschätzung geben können. Und – nicht zu vergessen: Die meisten meiner Kolleginnen und Kollegen nutzen die KI-Tools oft und gerne. Wir fühlen uns nicht bedroht durch die Technik. Die Bedrohung kommt – wenn überhaupt – von Entscheidungsträgern, die den überzogenen Behauptungen mehr glauben als ihren eigenen Kolleginnen und Kollegen.

## Fazit

Ich schließe mich Andrej Kaparthy an, "vibe coding" kann eine spannende und lustige Wochenendbeschäftigung und – manchmal – in kleinen Dosen auch im professionellen Umfang nützlich sein.

Niemals allerdings würde ich damit eine Anwendung live setzen. Mein Geld, meine Reputation und meine Sicherheit wären mir dafür viel zu kostbar.

Vibe coding – Was nun?

Why SwiftUI is a really cool UI framework

<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RlxMAaZpST6tm9J7VGrq"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RlxMAaZpST6tm9J7VGrq" alt="Store Pillars in the sea" width="800" height="235" /></a> (https://unsplash.com/photos/tRxA9tpnbKM)Let’s face it:Every company’s IT infrastructure can and will be the target of hacking. It is not a question of if it will happen, it is a question of when and how.There are far too many threat actors out there, starting with automatic bots that scan every IP address and port, trying to find general vulnerabilities. These attacks may not even be targeted directly at you; hitting your company might be collateral damage. The best – or worst – example is the hacking of the <a href="https://www.uniklinik-duesseldorf.de/ueber-uns/pressemitteilungen/detail/it-ausfall-an-der-uniklinik-duesseldorf" target="_blank">Uniklinik Düsseldorf (UKD) in September 2020</a> – a hacking case with deadly consequences that was aimed at another target altogether.Apart from automatic bots, there are several persons and groups with many different kinds of malicious intent. From the thrill or fun of breaking into a network, to the usage of computing power to mine digital currencies like Bitcoins, to direct financial gain (e. g. data theft or ransom), to espionage, to crippling or destroying competitors with denial of service attacks (DoS), up to nation state actors with political agendas – everything is possible.Some say there are only two kinds of companies: Companies that have been hacked – and companies that don’t know that they have been hacked.The threat is real.And since nearly every company today depends on a working and interconnected IT infrastructure, one would expect that everyone takes the necessary steps towards security, right?But that is obviously not the case, as we must see in our daily work.<h2>Why are companies not preparing?</h2>Most managers would agree, when asked, that IT security is highly important. But in contrast to that, a lot of companies don’t have the measures needed to respond to an attack, or even detect it at all.The probably most important reason: money. IT security costs a lot of money. For a large medium-sized company with an upper four-digit amount of employees, yearly costs will easily exceed one million euros. A fully equipped Security Operation Center (SOC) needs at least 9 to 12 people 24/7, and that is <a href="https://expel.io/blog/how-much-does-it-cost-to-build-a-24x7-soc/" target="_blank">not the end of it</a> .There are other costs for which a company is willing to pay much more than that. Why is IT security oftentimes neglected? Why do IT departments not implement the necessary means to be prepared?I am sure that it is not a technical problem. The solutions, the answers to threats, exist.<h2>It is mostly a management problem</h2>First of all: A lot of managers don’t really understand the severity of the threat. They simply don’t have the technical experience. So they stick to platitudes they repeat without really believing in them. Or they do understand, but do not want to accept the usability implications which IT security often brings, if not astutely applied. Having to use a complex password with multi-factor authentication (MFA) is much harder than just typing “1234” or “admin123” to log into a device.<h2>This behaviour is dangerous</h2>A successful adversary attack on a company’s environment can be very expensive. The cost of a major data breach can easily sum up to a 6, 7 or even 8-digit figure. Not counting in the possible fines from violating GDPR or other regulations. The attack can even cripple the IT infrastructure to the extent of taking the company completely out of business. Just ask yourself – right now while you’re reading: How long can your business processes continue only supported by paper?<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IPxMSuETpanIHAi0RrAQ"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IPxMSuETpanIHAi0RrAQ" alt="Masked Hacker" width="800" height="250" /></a> (https://unsplash.com/photos/dYEuFB8KQJk)In extreme cases, the impact of an attack can even literally kill someone, as mentioned above. No one in a company wants to deal with law enforcement and courts. You must do something.But IT security cannot simply be added to an existing infrastructure. It’s not a product you can just buy and install. “Please make all the features first, we can add security later”, isn’t going to work. Not at all.<h2>The five pillars of IT security</h2>Instead, IT security must be integrated into an organization to be effective. It cannot just be an additive.Good IT security must consist at least of these five elements:<h2>Visibility</h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/8qhgV5tzSviM593HoJGr"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/8qhgV5tzSviM593HoJGr" alt="Binoculars looking at the countryside" width="800" height="270" /></a> (https://unsplash.com/photos/rP163xbayY4)A company must be able to detect and trace an inflight or ongoing attack. That means, the complete technical infrastructure must be attached to a sensory system. Oftentimes, this means having software agents running on every laptop, desktop computer, server, firewall, router, switch, and all the other components that make up your network. Each system must be able to detect abnormal behaviour and report everything that is going on. Interestingly enough, Windows 10 has lots of it already built in. But most of the switches are set to “off”. Maybe because of compatibility issues, I don’t know.All log files, events and reportings should then be consolidated in a system that is called a SIEM (Security Information and Event Management). A SIEM can correlate logs and detect further abnormal behaviour that would go undetected when only observing a single machine.You can imagine, a SIEM requires a lot of storage. Collecting the log files of every computer and storing them for days or weeks sums to multiple Terabytes. But it’s worth it.Of course, you also need people that watch these systems around the clock. In a Security Operations Center (SOC) this is normally called SOC Level I and consists of at least three shifts of trained personnel that monitor the alerting systems and do first investigations.<h2>Investigation</h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/MNGNnv6HTG6gUPyaQ5jA"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/MNGNnv6HTG6gUPyaQ5jA" alt="Magnifying glas" width="800" height="264" /></a> (https://unsplash.com/photos/d9ILr-dbEdg)In case of a finding, someone must assess the situation. A SOC normally sees much more false alerts than real ones. The “false positives” must be identified and closed. This is called triage.If the SOC detects a real attack, they switch to incident response mode. That means analyzing and understanding the behaviour of the attacker and taking action against them.This is called SOC Level II. It requires a lot of security knowledge combined with deep insights into the company’s IT systems. A SOC needs to know which systems are critical and which aren’t, what can be turned off easily and what must be protected at all costs. For that, a SOC needs a <a href="https://www.bcm-news.de/wp-content/uploads/kochbuch-fuer-eine-bia.pdf" target="_blank">BIA (Business Impact Analysis)</a> ready at hand.<h2>Fulfillment</h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/L3gIBlw2RPW3dOujgXgC"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/L3gIBlw2RPW3dOujgXgC" alt="Cup with label &quot;Begin&quot;" width="800" height="310" /></a> (https://unsplash.com/photos/IuLgi9PWETU)One could think, SOC I and SOC II seem to be sufficient organizational groups for an incident. But every SOC can only be as effective as its plans are actionable by the IT department. If the SOC orders to cut the organization from the internet, there must be other people who can execute that order, know all access points, and switch them off. If the SOC needs, for example, critical information about the usage of a system or an image from a computer to investigate, the service fulfillment must be able to deliver quickly.Without a functioning service desk a SOC can do nothing. A company needs a working ticket system, prioritization rules and trained personnel available to execute the tasks.<h2>Governance</h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UMsyzGsPRJ2kpBIksVoE"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UMsyzGsPRJ2kpBIksVoE" alt="People discussion at a whiteboard" width="800" height="352" /></a> (https://unsplash.com/photos/Oalh2MojUuk)Personally, I don’t like that word a lot. So let’s rephrase it: IT security must have a prominent place within the company – and not only within the IT department. A Chief Information Security Officer (CISO) must be installed, having lots of experience and an equal lot of power to decide and act. A CISO cannot always ask the board for approval – in case of an attack, there might be no time for that.Additionally there must be security rules of how to protect the company. Which systems shall be configured how? What communication protocols do we need and what protocols shall be blocked? Into which segments will the network be divided? Does an employee in accounting need to access Powershell on a Windows system at all?It is very important that a company does not simply install IT security as a “department of NO”. It’s not meant to be a gatekeeper who simply denies (insecure) solutions. Instead, a company needs to have an appropriate consulting team that helps everyone in IT (management, development, network and operations …) with their tasks. IT security departments and consultants are enablers – helping colleagues and projects to improve.Finally, awareness for IT security is crucial. Every single employee must know the risks of phishing emails and how to detect them. Humans are still and will probably remain the single weakest link in the chain. A company needs to invest in them as well.<h2>Threat hunting</h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RcahH80YQwetWW5LWFUT"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RcahH80YQwetWW5LWFUT" alt="Many laptops on a table" width="800" height="359" /></a> (https://unsplash.com/photos/SYTO3xs06fU)So, with the above in place – you are able to detect abnormalities, you actively investigate and take remediation action, you have guidelines and rules in place to comply with – it’s hunting season!Time to establish an IT security threat hunting team! This team is often called SOC Level III. A SOC III looks actively and without current evidence for vulnerabilities and undetected threats. The goal is to constantly improve detection and mitigation, for example by testing established playbook strategies.They perform, for example, penetration tests on the outside facing infrastructure, scan the internal network for wrongly configured machines or investigate access rights to find ways for lateral movement – paths that adversaries like to follow. A threat hunting team assumes the role of an adversary or malicious hacker to find weak spots before real hackers do.<h2>IT security is an organizational issue</h2>Every organization has to deal with the five elements mentioned above in one way or the other. No institution can afford to let IT security remain a non-critical aspect. It is business critical and it cannot just be added to an otherwise unchanged system. Instead, it must be woven into it.Yes, it does cost a lot of money. But IT security is here “to protect and serve”. Having an alert SOC and an agile fulfillment organization can make the difference. They may prevent the hacking right at the beginning, instead of having hackers walking freely through your network, stealing data to put it on sale on the darknet and encrypting your servers to extort a ransom.The earlier an organization begins establishing IT security, the more ahead of possible hackers they can be. In the end, it could save a lot of money.In IT security incident response it’s like in classical business: TIME IS MONEY.

How to integrate IT security in a company, or: The five pillars of IT security

Contact Us | Fragen an Mitarbeiter

Lass uns austauschen!

Zeitgemäße User-Experience-Techniken in der Praxis mit codecentric AG

User Experience Specialist

IT Consultant

WEBINAR on demand

UX/UI

Zeitgemäße User-Experience-Techniken in der Praxis | codecentric AG 

Stefan Spittank bringt dir in mehreren Praxis-Schulungen die wichtigsten UX-Konzepte bei, die du für deine tägliche Arbeit brauchst.

Softwerker Vol.21 – Das Magazin der codecentric AG

WISSENS-HUB

Der Softwerker Vol. 21

Wenn Kunden Königinnen und Könige sind, sind Entwicklende dann Königsmacher?  Das wollen wir herausfinden und widmen uns in Vol. 21 voll und ganz der „customercentric" – UX inbegriffen!

Hier gibt's noch mehr spannende Infos von uns für euch

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Schreibt in Zukunft nur noch KI unsere Software?

Aus dem Inhalt:

Hier gibt's noch mehr spannende Infos von uns für euch

Zeitgemäße User-Experience-Techniken in der Praxis | codecentric AG

Der Softwerker Vol. 21

Jetzt für unseren Newsletter anmelden