Frontend und Backend verbinden

Frontend und Backend verbinden

0:00 Bis hierher war Klarpfad eine hübsche leere Hülle. Heute bekommt die App zum ersten Mal echte Daten — und damit stellt sich eine Frage, die in jeder Anwendung auftaucht, hier aber besonders klar beantwortet werden kann: Wo läuft eigentlich was, und wem darf man glauben? Forge zieht diese Grenze ungewöhnlich deutlich. Vor der Grenze sitzt der Browser, hinter ihr die Plattform.

0:21 Wer diese Linie einmal sauber im Kopf hat, macht in den nächsten Jahren die meisten Sicherheitsfehler nicht mehr, über die wir morgen sprechen werden.

APIs, Resolver und Datenhaltung

0:30 Der dritte Tag hat zwei Hälften, die eng zusammengehören. Am Vormittag geht es um die Verbindung: Wie kommt die Oberfläche an Daten aus Jira, und wie ruft sie eigenen Backend-Code auf. Am Nachmittag geht es um die Frage, was mit diesen Daten passiert — wo sie liegen dürfen und in welcher Form. Am Ende des Tages speichert Klarpfad zum ersten Mal wirklich etwas, das auch nach dem Neuladen noch da ist.

Forge Bridge im Frontend

0:53 Fangen wir vorne an, in der Oberfläche — und mit dem einzigen Weg, der von dort nach draußen führt. Die Bridge ist genau das, was der Name sagt: eine Brücke. Sie verbindet die Oberfläche mit der Plattform, und sie ist der einzige Weg. Es gibt kein fetch auf eine beliebige Adresse, keinen direkten Zugriff auf irgendetwas.

1:13 Über diese Brücke laufen vier Arten von Verkehr: eigene Backend-Funktionen aufrufen, Produkt-APIs ansprechen, Kontext lesen und Rückmeldungen anzeigen. Und der wichtigste Satz steht am Ende: Alles, was über die Bridge geht, läuft im Namen der Nutzerin. Die App selbst hat hier keine Stimme. Sechs Einträge, und dahinter steckt eine klare Ordnung. Die ersten beiden gehen nach außen — zur eigenen Funktion oder zur Produkt-API.

1:39 Die mittleren betreffen die Ansicht selbst: Kontext lesen, ein Modal schließen, eine Eingabe übergeben. Die letzten beiden sind Komfort für Rückmeldung und Navigation. Der eigentliche Merksatz steht wieder in der Fußzeile: Die Bridge kennt kein Handeln im Namen der App. Wenn Sie also etwas brauchen, das die Nutzerin selbst nicht darf, führt kein Weg an einem Resolver vorbei. Das ist keine Einschränkung, sondern eine sehr bewusste Konstruktion.

2:07 Vier Zeilen, und sie sehen aus wie ein gewöhnlicher API-Aufruf. Genau das sind sie auch, mit einem Unterschied: Authentifizierung müssen Sie nicht anfassen. Die Plattform setzt die Identität der angemeldeten Nutzerin ein. Worauf es ankommt, steht in der Fußzeile — fehlt dieser Person das Recht, antwortet die API mit einem Fehler.

2:27 Und das ist ausdrücklich gewollt. Ihre App kann niemandem mehr zeigen, als er ohnehin sehen dürfte. Das erspart Ihnen eine ganze Klasse von Sicherheitsüberlegungen, solange Sie im Nutzerkontext bleiben. Der erste Punkt ist handwerklich: Die Antwort wird verwendet, ohne den Statuscode zu prüfen. Bei einem Fehler bekommen Sie dann kein Objekt, sondern etwas ganz anderes — und der Fehler zeigt sich drei Zeilen später an einer unverständlichen Stelle.

2:54 Der zweite ist der, den wir gerade besprochen haben: Ein App-Zugriff wird im Frontend erwartet. Und der dritte ist eine Erinnerung an gestern — ein Aufruf direkt im Rendervorgang statt in einem Effekt feuert bei jedem Rendern erneut.

Resolver im Backend

3:08 Damit sind wir auf der anderen Seite der Brücke — beim Resolver, dem Ort, an dem Ihre App eigene Rechte und eigene Regeln hat. Ein Resolver ist im Grunde eine Telefonzentrale. Das Frontend ruft an und nennt einen Namen; die Zentrale verbindet zur passenden Funktion. Jede dieser Funktionen bekommt zwei Dinge: die Nutzlast aus dem Frontend — also das, was der Anrufer sagt — und den Kontext von der Plattform — also das, was über den Anrufer bekannt ist.

3:36 Diese Unterscheidung ist der Kern des ganzen Tages. Das eine ist eine Behauptung, das andere eine Tatsache. Das Muster ist schnell erzählt: Zentrale anlegen, unter einem Namen eine Funktion hinterlegen, am Ende die Definitionen exportieren — und dieser Export ist genau der Einstiegspunkt, den wir am ersten Tag im Manifest eingetragen haben.

3:57 Im Frontend rufen Sie dann denselben Namen auf und übergeben die Nutzlast, wie die Fußzeile zeigt. Worauf es ankommt: Der Name ist der Vertrag zwischen beiden Seiten. Er steht an zwei Stellen im Code und nirgendwo sonst — ein Tippfehler fällt erst zur Laufzeit auf. Typisierte Varianten gibt es, und in größeren Apps lohnen sie sich schnell.

4:17 Diese vier Punkte sind die Entscheidungshilfe für die Frage, die Sie in jedem Projekt hundertmal stellen werden. Jeder Zugriff auf Speicher und externe Dienste gehört nach hinten. Alles, was App-Rechte braucht, ohnehin. Fachliche Regeln, die verbindlich sein sollen — und das Wort verbindlich ist hier entscheidend. Und alles, was Geheimnisse berührt oder Kosten auslöst. Die Faustregel dahinter: Was jemand mit den Entwicklerwerkzeugen umgehen könnte, darf nicht die letzte Instanz sein.

4:46 Der erste Punkt ist ein Architekturfehler mit Spätfolgen: Ein Resolver gibt rohe API-Antworten einfach durch. Dann hängt Ihre Oberfläche an der Struktur einer fremden API, und deren nächste Änderung ist Ihr Problem. Der zweite ist das andere Extrem — für jeden Klick ein eigener Schlüssel, bis niemand mehr weiß, welcher wozu gehört.

5:05 Und der dritte ist der Klassiker vom ersten Tag: Der Handler-Eintrag im Manifest passt nicht zum Dateipfad, und die Fehlermeldung ist weniger gesprächig, als man hoffen würde.

Eingaben an Funktionsgrenzen prüfen

5:16 Jetzt zu der Stelle, an der aus einer funktionierenden App eine belastbare wird: der Prüfung an der Grenze. Hier ist der Satz, den ich Ihnen mitgeben möchte: Was aus dem Frontend kommt, ist ein Vorschlag. Die Nutzlast eines Aufrufs lässt sich im Browser verändern — nicht theoretisch, sondern mit zwei Handgriffen in den Entwicklerwerkzeugen.

5:36 Ihr Resolver prüft deshalb jede Eingabe selbst: Pflichtfelder, Länge, Wertebereiche, erlaubte Statuswerte. Und er gibt Ergebnisse und Fehler in einer einheitlichen Form zurück, damit die Oberfläche damit sinnvoll umgehen kann. Das klingt nach Doppelarbeit zum Formular von gestern. Ist es auch — mit dem Unterschied, dass nur eine der beiden Prüfungen zählt.

5:58 Achten Sie auf zwei Dinge. Erstens die feste Liste erlaubter Statuswerte ganz oben: Aufzählungen prüft man gegen eine Liste, nicht gegen Hoffnung. Zweitens die Form der Rückgabe — ein Merker, ob es geklappt hat, und im Fehlerfall ein Grund. Die Fußzeile nennt den Zweck: Damit lässt sich ein fachlicher Fehler von einem technischen unterscheiden.

6:18 Ein zu langer Titel ist kein Systemfehler, und er sollte auch nicht so aussehen. Die Oberfläche kann aus dem Grund eine präzise Meldung machen — und genau daran scheitern die meisten Apps. Der rote Faden: erst festlegen, was erwartet wird, dann alles andere abweisen. Die Schritte zwei und drei sind Handwerk. Schritt vier ist eine Architekturentscheidung, die sich auszahlt — Fachfehler als Ergebnis zurückgeben, nicht als Ausnahme werfen.

6:45 Ausnahmen sind für das Unerwartete da, und ein leeres Pflichtfeld ist nicht unerwartet. Und Schritt fünf schließt den Kreis zur Oberfläche: je Grund eine eigene Meldung. Sonst haben Sie zwar sauber geprüft, aber die Nutzerin sieht wieder nur „Es ist ein Fehler aufgetreten". Der erste Punkt ist der wichtigste des ganzen Kapitels: Geprüft wird nur im Formular, und der Resolver vertraut.

7:08 Das funktioniert, solange niemand auf die Idee kommt, es zu versuchen. Der zweite verwandelt jeden Tippfehler in einen Systemfehler — inklusive roter Meldung und unnötigem Anruf beim Support. Und der dritte ist der, den ich in echten Projekten am häufigsten sehe: Die Prüfregeln stehen doppelt, vorne und hinten, und laufen mit der Zeit auseinander.

7:29 Eine gemeinsame Funktion für beide Seiten löst das elegant.

Nutzerkontext und Berechtigungen im Zugriff

7:33 Und damit zur Vertrauensfrage — dem Kapitel, das morgen den ganzen Sicherheitstag trägt. Der Unterschied ist einfach und folgenreich. Der Kontext, den ein Resolver bekommt, stammt von der Plattform. Er ist geprüft und lässt sich nicht verändern — auf ihn dürfen Sie Autorisierungsentscheidungen stützen. Die Kontextangaben, die die Oberfläche über die Bridge liest, sind für die Anzeige gedacht. Sie liegen im Browser und lassen sich dort verändern.

8:00 Die Dokumentation ist an dieser Stelle ungewöhnlich deutlich, und das aus gutem Grund: Wer im Browser entscheidet, wer etwas darf, hat nichts entschieden. Sehen Sie sich die zweite Zeile genau an. Die Kennung der Nutzerin kommt aus dem Kontext — nicht aus der Nutzlast. Das ist der ganze Unterschied zwischen einer geprüften und einer scheinbar geprüften App. Danach wird der Eintrag geladen und verglichen, wer ihn erfasst hat.

8:26 Passt es nicht, gibt es eine Ablehnung mit Grund, kein stilles Ignorieren. Worauf es ankommt: Diese Prüfung steht vor der Änderung, nicht daneben. Und sie steht im Resolver, nicht in der Komponente, die den Knopf zeichnet. Vier Glieder, und in der Mitte verläuft die Linie, um die es heute geht. Browser und Bridge liegen davor: Alles, was von dort kommt, ist eine Behauptung — das Formular, die Nutzlast, die Kontextangaben zur Anzeige.

8:53 Resolver und Plattform liegen dahinter: Was dort ankommt, ist plattformseitig belegt. Wenn Sie bei einer Code-Stelle unsicher sind, fragen Sie sich schlicht, auf welcher Seite der Linie sie steht. Die Antwort sagt Ihnen, ob Sie prüfen müssen oder prüfen dürfen. Alle drei sind Varianten derselben Verwechslung. Die Kennung wird aus der Nutzlast gelesen statt aus dem Kontext — damit kann sich jeder als jeder ausgeben.

9:18 Die Oberfläche blendet eine Schaltfläche aus, aber das Backend prüft nicht; das ist Sicherheit durch Unsichtbarkeit, und sie hält genau so lange, bis jemand den Aufruf direkt schickt. Und der dritte ist der häufigste in echten Apps: Lesen ist abgesichert, Schreiben nicht. Weil Lesen zuerst gebaut wurde und beim Schreiben die Zeit knapp war.

Übung

9:38 In der Übung ziehen Sie diese Linie zum ersten Mal selbst — und testen sie anschließend mit einem manipulierten Aufruf. Klarpfad bekommt jetzt echte Daten. Der Vorgang liefert den Titel über die Produkt-API, die Entscheidungen kommen über einen Resolver. Gespeichert wird zunächst in einer einfachen Ablage im Backend — welche Art von Speicher wirklich passt, klären wir heute Nachmittag.

10:01 Diese Trennung ist Absicht: Erst die Verbindung und die Vertrauensgrenze sauber bauen, dann über die Ablage nachdenken. Wer beides gleichzeitig entscheidet, entscheidet meistens beides schlecht. Das Erfolgskriterium hat drei Teile, und der dritte ist der eigentliche Lernmoment: Eine manipulierte Nutzlast wird vom Resolver abgewiesen.

10:20 Bauen Sie das wirklich nach — ändern Sie die Nutzlast in den Entwicklerwerkzeugen, schicken Sie einen fremden Eintrag zur Änderung, und sehen Sie, wie Ihr Backend reagiert. Dieses eine Experiment erklärt mehr über die Architektur als jede Folie. Wer früh fertig ist, ergänzt eine kurze Rückmeldung nach dem Speichern — eine App, die schweigt, wirkt kaputt, auch wenn sie funktioniert.

10:43 Die Reihenfolge führt von vorne nach hinten und dann zurück: Vorgangsdaten holen, Resolver definieren und im Manifest verbinden, Eingaben prüfen, Berechtigung prüfen, und dann der Angriffsversuch. Nehmen Sie sich für Schritt drei wirklich Zeit — die einheitliche Rückgabeform zahlt sich in jedem weiteren Kapitel aus. Und Schritt fünf ist kein Extra: Eine Prüfung, die man nicht ausprobiert hat, ist eine Vermutung. Genau dasselbe gilt morgen für alles, was wir über Sicherheit sagen werden.

11:12 Drei Muster zum Mitnehmen. Die Prüfung wandert in die Oberfläche, weil dort die Meldung entsteht — und hinten bleibt nichts übrig. Der Resolver gibt bei jedem Fehler dieselbe Meldung zurück, womit die ganze Mühe mit dem Grund verpufft. Und die Liste wird nach dem Speichern nicht aktualisiert, sodass der neue Eintrag erst nach dem Neuladen auftaucht — ein kleiner Fehler mit großer Wirkung, weil Nutzende dann ein zweites Mal absenden.

11:36 Und damit sind wir beim Thema des Nachmittags: Wo landen diese Daten eigentlich?