{"id":25893,"date":"2023-09-15T20:22:16","date_gmt":"2023-09-15T18:22:16","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=25893"},"modified":"2023-09-15T20:22:18","modified_gmt":"2023-09-15T18:22:18","slug":"entwickeln-einer-edge-anwendung-mit-cloudflare","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/09\/15\/entwickeln-einer-edge-anwendung-mit-cloudflare\/","title":{"rendered":"Entwickeln einer Edge-Anwendung mit Cloudflare"},"content":{"rendered":"\n

Einleitung<\/h1>\n\n\n\n

Englisch spielt eine gro\u00dfe Rolle in meinem Beruf und Alltag, doch immer noch passieren mir Grammatikfehler. Um meine Englischkenntnisse zu verbessern, habe ich eine kleine Webseite entwickelt, auf der das Schreiben von englischen S\u00e4tzen ge\u00fcbt werden kann. Dem Nutzer wird ein Satz pr\u00e4sentiert, der dann in die festgelegte Sprache \u00fcbersetzt werden muss. Satzteile, die fehlerhaft \u00fcbersetzt wurden, werden rot makiert. Alle absolvierten Aufgaben werden auf einer \u00dcbersichtsseite gespeichert. Aufgaben k\u00f6nnen zudem favorisiert werden, was einen besseren \u00dcberblick \u00fcber eigene Fehler erm\u00f6glicht.<\/p>\n\n\n\n

Ziel des Projektes<\/h1>\n\n\n\n

Ein zentrales Ziel dieses Projekts bestand darin, den Nutzern eine hohe Performance zu bieten. Zudem war es mir pers\u00f6nlich wichtig, mein Wissen \u00fcber neue Technologien zu erweitern. Deshalb lag das Hauptziel des Projekts auf das Verwenden einer Edge-Umgebung. Ich wollte lernen, was es bedeutet eine App auf einer Edge Umgebung zu deployen und welche Vor- und Nachteile dies mit sich bringt.<\/p>\n\n\n\n

Die Anwendung<\/h1>\n\n\n\n

Die Webseite kann unter dem folgendem Link gefunden werden: https:\/\/language-trainer.pages.dev<\/a><\/p>\n\n\n\n

Als erstes muss ein Account erstellt werden, um die Anwendung benutzen zu k\u00f6nnen.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Im n\u00e4chsten Schritt muss dann die E-Mail-Adresse best\u00e4tigt werden.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Dann ist man angemeldet und kann beginnen, mein Englisch zu \u00fcben. In der Mitte der Webseite wird der zu \u00fcbersetzende Satz angezeigt. Direkt unter diesem Satz befindet sich das Antwortfeld, in das die \u00dcbersetzung eingegeben wird. Anschlie\u00dfend muss nur noch die Eingabetaste gedr\u00fcckt oder auf den “Submit”-Knopf geklickt werden, um die Aufgabe einzureichen.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Wenn die Aufgabe eingereicht wurde, erscheint nach kurzer Zeit die L\u00f6sung oberhalb der Aufgabenbox. So kann sofort gesehen werden, ob die \u00dcbersetzung korrekt war. Dazu k\u00f6nnen L\u00f6sungen durch das Klicken auf den Stern favorisiert werden. <\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Auf der rechten Seite kann die Sprache eingestellt werden. Dabei kann durch einen Klick auf den mittleren Knopf, die Frage mit der Eingabe Sprache gewechselt werden.<\/p>\n\n\n\n

Auf der linken Seite befindet sich das Navigationsmen\u00fc. Von dort aus kann zu den Seiten “History” und “Favorites” navigiert werden.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Ganz unten auf der linken Seite wird die E-Mail-Adresse des angemeldeten Accounts angezeigt. Durch einen Klick \u00f6ffnet sich ein Dropdown-Men\u00fc, \u00fcber das sich der Benutzer ausloggen kann.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Verwendete Technologien<\/h1>\n\n\n\n

Die Anwendung setzt sich aus einem Next.js-Frontend, einem Hono.js-Backend und einer SQLite-Datenbank zusammen.<\/p>\n\n\n\n

Als Basis f\u00fcr das Frontend dient Next.js, das aufgrund seiner F\u00e4higkeit, die Seiten im Voraus zu rendern, hervorragend geeignet ist. Dies erm\u00f6glicht die statische Generierung aller Seiten w\u00e4hrend des Build-Schritts, die bei jedem Seitenaufruf wiederverwendet werden. Dadurch eliminiert es die Generierung auf der Client-Seite, was zu wesentlich k\u00fcrzeren Ladezeiten f\u00fchrt.<\/p>\n\n\n\n

Das Backend nutzt Hono.js, da es sich um ein schnelles, kleines Backend-Framework handelt, welches f\u00fcr die Nutzung in Edge-Umgebungen entwickelt wurde. Ein weiterer Vorteil von Hono.js ist die Verf\u00fcgbarkeit zahlreicher zus\u00e4tzlicher Middlewares f\u00fcr eine Vielzahl von Funktionen. So habe ich die CORS-Middleware implementiert, um sicherzustellen, dass ausschlie\u00dflich mein Frontend Zugriff auf das Backend hat.<\/p>\n\n\n\n

Um Fehler zu vermeiden, wurde auf eine vollst\u00e4ndige typsichere Entwicklung geachtet. Hierzu wurde TypeScript im Frontend sowie im Backend eingesetzt. F\u00fcr die Datenbank wurde das Drizzle ORM verwendet.
Es ist type safe und generiert Types f\u00fcr die Datenbanktabellen. Sollten die Daten nicht dem erwarteten Schema entsprechen, wird die Abfrage rot unterstrichen und es wird angezeigt, was korrigiert werden muss. DrizzleORM ist zudem ein leichtes und schnelles ORM, das problemlos in der EDGE-Umgebung ausgef\u00fchrt werden kann.<\/p>\n\n\n\n

Die Kommunikation zwischen Frontend und Backend wird \u00fcber tRPC realisiert, um eine vollst\u00e4ndig typsichere API-Kommunikation zu erm\u00f6glichen. Das bedeutet, dass im Frontend ersichtlich ist, welche Daten das Backend ben\u00f6tigt und welche es bereitstellt. Um die Eingabedaten zu validieren, nutze ich die Bibliothek Zod.
Dazu habe ich die TanStack Query Bibliothek auf dem Client verwendet, um Daten abzurufen und zu senden. Sie bietet zahlreiche hilfreiche Hooks, die den Abrufprozess erleichtert. Beispielsweise werden Daten automatisch erneut abgerufen, wenn sie veraltet sind. Des Weiteren sind Caching und State Management integriert. Ein zus\u00e4tzlicher Vorteil ist der \u201cuseInfiniteQuery\u201d Hook, der die Implementierung von unendlichem Scrollen in der Historie und bei den Favoriten erheblich erleichterte.<\/p>\n\n\n\n

Da Frontend und Backend als separate Projekte sind, habe ich ein Monorepo mit Turborepo erstellt. Turborepo ist ein Build-System, das f\u00fcr die Verwaltung von Monorepos konzipiert wurde. Es bestimmt, welche Elemente bereits gebaut wurden und welche \u00c4nderungen erfordern, um nur die ben\u00f6tigten Aspekte zu erstellen. Ich nutze Turborepo haupts\u00e4chlich zur Einrichtung eines Monorepos, sodass ich sowohl Backend als auch Frontend gleichzeitig starten kann. Hierf\u00fcr richtete ich die Packages “Apps” und “Packages” ein. In “Apps” befindet sich die Nextjs-Anwendung und unter “Packages” das API-Backend mit dem Hono.js-Backend. Turborepo erkennt diese Projekte anhand der in den Verzeichnissen enthaltenen package.json-Dateien. Wird das folgende Package.json-Script im Hauptprojekt ausgef\u00fchrt, starten Frontend und Backend gleichzeitig.<\/p>\n\n\n\n

"dev": "turbo dev --parallel --filter={next-app,api}"<\/code><\/pre>\n\n\n\n
Hierbei stehen “next-app” und “api” f\u00fcr die Namen in der package.json-Datei. Turborepo f\u00fchrt dann jeweils das Dev-Skript f\u00fcr “next-app” und “api” aus. Somit laufen dann Backend und Frontend in einem Terminal, was einen \u00fcbersichtlichen Einblick \u00fcber die Logs bietet.<\/p>\n\n\n\n
Ein weiterer Vorteil von Turborepo ist seine Effizienz bei der Installation: Es erstellt nur ein node_modules-Verzeichnis im Hauptordner, das alle Pakete aller Anwendungen enth\u00e4lt. Dies ist besonders praktisch, wenn Front- und Backend dieselben Pakete verwenden. In diesem Fall wird jedes Paket nur einmal installiert.<\/p>\n\n\n\n
Infrastruktur<\/h1>\n\n\n\n
Mit den verwendeten Technologien musste ich dann das Hono.js-Backend, Next.js-Frontend und eine SQLite Datenbank deployen.<\/p>\n\n\n\n
Zuerst habe ich dar\u00fcber Gadanken gemacht, wie ich das Backend deployen sollte. Die Wahl fiel dabei auf Cloudflare Workers, da diese recht bekannt f\u00fcr ihre Serverless Edge-Umgebung sind.<\/p>\n\n\n\n
Serverless bedeutet, dass die Anwendung automatisch skaliert und der Entwickler sich keine Sorgen dar\u00fcber machen muss. Ein typisches Problem von Serverless-Architekturen besteht in sogenannte “Cold Starts”, bei denen die erste Anfrage einige Sekunden ben\u00f6tigen kann, bevor der Server antwortet. Das liegt daran, dass die Serverinstanz erst gestartet werden muss, was die Benutzererfahrung beeintr\u00e4chtigen kann. Bei Cloudflare Workers gibt es allerdings keine solchen “Cold Starts”. Edge bedeutet, dass die Anwendung so nahe wie m\u00f6glich beim Nutzer ausgef\u00fchrt wird. Je nach Standort des Nutzers erfolgt der Zugriff daher immer auf den n\u00e4chstgelegenen Server, was zu einer niedrigen Latenz und kurze Ladezeiten f\u00fchrt.<\/p>\n\n\n\n
Beim Next.js-Frontend ist Vercel, der Ersteller des Frameworks, eine beliebte Wahl f\u00fcr das Deployment der App. Ich hatte damit aber bereits schon Erfahrung und da bereits Cloudflare f\u00fcr das Backend verwendet hatte, beschloss ich, auch f\u00fcr das Frontend auf Cloudflare zu setzen. Hier kam Cloudflare Pages ins Spiel, das viele Frameworks unterst\u00fctzt, darunter auch Next.js und ebenfalls in einer Edge-Umgebung l\u00e4uft.<\/p>\n\n\n\n
F\u00fcr die Datenbank erw\u00e4gte ich zun\u00e4chst Neon oder Planetscale als Deployment-Optionen, da beide einen Serverless-Treiber anbieten, der in einer Edge-Umgebung ausgef\u00fchrt werden kann. Bei Neon w\u00e4re es eine PostgreSQL-Datenbank gewesen und bei Planetscale eine MySQL-Datenbank. Obwohl ich normalerweise PostgreSQL bevorzuge, wurde ich auf die Datenbankoption Cloudflare D1 aufmerksam.<\/p>\n\n\n\n
Ein Vorteil von Cloudflare D1 besteht darin, dass die Datenbank einfach an den Worker gebunden werden kann. Zudem ist Cloudflare D1 im Vergleich zu anderen Anbietern PostgreSQL relativ schnell.<\/p>\n\n\n\n
\"\"<\/a>
https:\/\/blog.cloudflare.com\/d1-turning-it-up-to-11\/<\/figcaption><\/figure>\n\n\n\n
In Zukunft soll es noch m\u00f6glich sein, schreibgesch\u00fctzte Replikate \u00fcber das globale Cloudflare-Netzwerk zu verteilen. Daraus w\u00fcrde resultieren, dass die Daten so nah wie m\u00f6glich beim Nutzer gespeichert werden, was die Datenladegeschwindigkeit noch weiter verbessern k\u00f6nnte. Aktuell befindet sich Cloudflare D1 noch in der Alpha-Version, was bedeutet, dass die Speicherkapazit\u00e4t der Datenbank auf 500 MB begrenzt ist.<\/p>\n\n\n\n
Da bei der Durchf\u00fchrung von \u00dcbersetzungsaufgaben die L\u00f6sungen zum Nutzer gespeichert werden, musste zus\u00e4tzlich eine Authentifizierung implementiert werden.<\/p>\n\n\n\n
Hierbei entschied ich mich f\u00fcr Supabase Auth, da es durch den Auth-Client einfach einzurichten ist und ich mich nicht um die Speicherung kritischer Authentifizierungsdaten k\u00fcmmern muss.<\/p>\n\n\n\n
Deployement<\/h1>\n\n\n\n
Frontend<\/h2>\n\n\n\n
Das Next.js-Frontend wurde mittels einer Github Action auf Cloudflare Pages deployt. Damit die Github Action die Next.js Anwendung auf Cloudflare Pages deployen kann, m\u00fcssen die Variablen “CF_API_TOKEN”, “CF_ACCOUNT_ID” und “CF_PROJECT_NAME” als Secrets auf Github hinterlegt sein.

Die Github Action besitzt die folgenden Stages:<\/p>\n\n\n\n
Checkout code:<\/strong> Um das Github-Repository auszuchecken.
Setup Node.js environment:<\/strong> Um die Node-Version 18 festzulegen.
Monorepo install:<\/strong> Hier habe ich diese Composite github action<\/a> verwendet. Diese bringt den Vorteil mit, dass der Cache erhalten bleibt. Dadurch kann das Projekt schneller installiert werden.
Build:<\/strong> Zun\u00e4chst wird das Arbeitsverzeichnis auf Next.js ge\u00e4ndert. Anschlie\u00dfend werden die Umgebungsvariablen exportiert. Abschlie\u00dfend wird ein Cloudflare-CLI-Tool f\u00fcr Next.js ausgef\u00fchrt, um die Anwendung zu bauen.
Publish to Cloudflare Pages:<\/strong> Im letzen Stage wird das zuvor erstellte Build auf Cloudflare deployt mit den Umgebungsvariablen die auf Github abgespeichert wurden.<\/p>\n\n\n\n
Somit wird sichergestellt, dass das Next.js-Frontend erfolgreich auf Cloudflare Pages deployt wird.<\/p>\n\n\n\n
Backend<\/h2>\n\n\n\n
Das Backend habe ich \u00fcber Cloudflare Wrangler CLI deployt. Dies hat sich als leichter herausgestellt als ich es mir vorgestellt habe.<\/p>\n\n\n\n
Als erstes musste ich das Deployment vorbereiten. Dazu musste ich als erstes die ben\u00f6tigten Umgebungsvariablen in das Projekt auf Cloudflare abspeichern. Mit dem folgendem CLI-Befehl konnte ich die Umgebungsvariablen zu dem Projekt hochladen. Sofern noch kein Cloudflare-Worker mit dem “PROJECT_NAME” existiert, wird ein neues Projekt erstellt.<\/p>\n\n\n\n
echo <VALUE> | wrangler secret put <NAME> -- name <PROJECT_NAME><\/code><\/pre>\n\n\n\n
Da das Backend auch eine Datenbank ben\u00f6tigt, habe ich als n\u00e4chsten Schritt eine Datenbank erstellt, indem ich den folgenden Befehl verwendet habe.<\/p>\n\n\n\n
wrangler d1 create <DB_NAME><\/code><\/pre>\n\n\n\n
Das Ergebnis sieht dann wie folgt aus.<\/p>\n\n\n\n
\u2705 Successfully created DB 'example' in region WEUR\nCreated your database using D1's new storage backend. The new storage backend is\nnot yet recommended for production workloads, but backs up your data via\npoint-in-time restore.\n\n[[d1_databases]]\nbinding = "DB" # i.e. available in your Worker on env.DB\ndatabase_name = "example"\ndatabase_id = "8a6819bc-51a0-4fc2-9ae6-9014ac78f2a7"<\/code><\/pre>\n\n\n\n
Das Ende des Terminal-Outputs ist wichtig, da diese Information ben\u00f6tigt wird, um den Worker mit der Datenbank zu verkn\u00fcpfen.<\/p>\n\n\n\n
Im n\u00e4chsten Schritt muss dann eine wrangler.toml-Datei erstellt werden. Dies ist die Konfigurationsdatei, die f\u00fcr das Deployment ben\u00f6tigt wird.<\/p>\n\n\n\n
In dieser Datei muss unter “name” den Projektnamen definiert werden, sowie den “compatibility_date”, die “account_id” und die Bindings f\u00fcr die Datenbank eingeben werden. Es ist wichtig, dass der gleiche Projektname wie bei der Speicherung Umgebungsvariablen verwendet wird. Das Ganze sollte dann in etwa so aussehen:<\/p>\n\n\n\n
name = "language-trainer"\ncompatibility_date = "2023-01-01"\nsend_metrics = false\naccount_id = "..."\n\n[[d1_databases]]\nbinding = "DB"\ndatabase_name = "example"\ndatabase_id = "8a6819bc-51a0-4fc2-9ae6-9014ac78f2a7"\nmigrations_dir = "migrations"<\/code><\/pre>\n\n\n\n
Jetzt muss das Backend noch deployt werden. Dazu muss der folgende Befehl eingegeben werden.<\/p>\n\n\n\n
wrangler deploy <Main Entry File><\/code><\/pre>\n\n\n\n
Zum Abschluss muss noch eine Migration auf die Datenbank angewendet werden. Sollte noch keine Migration vorhanden sein, kann mit dem folgenden Befehl eine Migration erstellt werden.<\/p>\n\n\n\n
pnpm generate<\/code><\/pre>\n\n\n\n
Die erstellte Migration muss dann noch mit folgendem Befehl angewendet werden.<\/p>\n\n\n\n
wrangler d1 migrations apply <DB_NAME><\/code><\/pre>\n\n\n\n
Probleme und L\u00f6sungen<\/h1>\n\n\n\n
Das Frontend \u00fcber die Cloudflare-Webseite deployen<\/h2>\n\n\n\n
Als ich versuchte, das Next.js-Frontend \u00fcber die Cloudflare-Webseite zu deployen, erhielt ich st\u00e4ndig Build-Fehler. Interessanterweise traten diese Fehler nicht auf, wenn ich das Cloudflare CLI f\u00fcr Next.js lokal ausgef\u00fchrt habe.<\/p>\n\n\n\n
Das machte es ziemlich schwierig, den Fehler zu finden. Der erste Fehler weist darauf hin, dass tRPC den Typ “favorites” nicht besitzt.<\/p>\n\n\n\n
| 21:43:48.962 | \u25b2  Type error: Property 'favorites' does not exist on type '"The property 'useContext' in your router collides with a built-in method, rename this router or procedure on your backend." | "The property 'withTRPC' in your router collides with a built-in method, rename this router or procedure on your backend." | "The property 'useQueries' in your router collides with a built-i...'. |\n| 21:43:48.962 | \u25b2  Property 'favorites' does not exist on type '"The property 'useContext' in your router collides with a built-in method, rename this router or procedure on your backend."'. |\n| 21:43:48.962 | \u25b2   |\n| 21:43:48.963 | \u25b2     8 |  |\n| 21:43:48.963 | \u25b2     9 |   const { data, isSuccess, fetchNextPage, hasNextPage, isFetching, isFetchingNextPage, refetch } = |\n| 21:43:48.963 | \u25b2  **> 10 |     trpc.favorites.getFavorites.useInfiniteQuery(** |\n| 21:43:48.963 | \u25b2       |          **^** |\n| 21:43:48.963 | \u25b2    11 |       { |\n| 21:43:48.963 | \u25b2    12 |         limit: LIMIT, |\n| 21:43:48.964 | \u25b2    13 |       }, |\n| 21:43:49.041 | \u25b2  ELIFECYCLE\u2009 Command failed with exit code 1. |<\/code><\/pre>\n\n\n\n
Bei der Erstellung des tRPC-Clients gebe ich den importierten “AppRouter”-Typ aus dem Backend an.<\/p>\n\n\n\n
import type { AppRouter } from 'api\/src\/router';\n\nexport const trpc = createTRPCNext<AppRouter>({\n  ...\n})<\/code><\/pre>\n\n\n\n
Somit sollte das Frontend eigentlich wissen, dass der App-Router den “favorites”-Router enth\u00e4lt.<\/p>\n\n\n\n
import { favoritesRouter } from '.\/routes\/favorites';\n\nexport const appRouter = router({\n  favorites: favoritesRouter,\n});\n\nexport type AppRouter = typeof appRouter;<\/code><\/pre>\n\n\n\n
Bei der Erstellung des tRPC-Clients importiere ich den “AppRouter”-Typ vom Backend. Doch ich hatte den Pfad des Next.js-Projekts als Root-Ordner angegeben, was m\u00f6glicherweise das Problem verursachte, da der Typ vom Backend dann m\u00f6glicherweise nicht importiert werden konnte.
Deshalb habe ich nach alternativen Wegen gesucht, das Frontend zu deployen und habe letztendlich Github Actions daf\u00fcr eingesetzt. Damit funktionierte es dann. Im Nachhinein stellte ich fest, dass es \u00fcber die Cloudflare Webseite funktioniert h\u00e4tte, wenn ich in der Next.js-Konfiguration die TypeScript-Build-Fehler ignoriert h\u00e4tte.<\/p>\n\n\n\n
typescript: {\n      ignoreBuildErrors: true,\n    },<\/code><\/pre>\n\n\n\n
Das w\u00e4re sicherlich nicht eine optimale L\u00f6sung gewesen, gegangen w\u00e4re es.<\/p>\n\n\n\n
Port-Konflikt<\/h2>\n\n\n\n
Bei der Bearbeitung einer Mutation im Backend war ich mir unsicher, ob diese so funktioniert wie gedacht. Ich konnte zwar durch die Browser-Console sehen, dass ein Request und eine Response  stattfanden, doch die Daten in der Response waren “null”. Um zu \u00fcberpr\u00fcfen, ob alles richtig funktionierte, f\u00fcgte ich einige console.logs im Backend hinzu. Allerdings erhielt ich keine Ausgaben.<\/p>\n\n\n\n
Nach einem Blick in die Dokumentation des Backend-Frameworks stellte ich fest, dass es eine Logging-Middleware gibt. Diese hatte ich dann implementiert, aber wieder wurden keine Ausgaben im Terminal angezeigt. Nach einigen Neustarts bemerkte ich, dass das Backend jedes Mal auf einem anderen Port startete anstatt den vorgegebenen Port zu verwenden.<\/p>\n\n\n\n
Nachdem ich die laufenden Ports \u00fcberpr\u00fcft hatte, fiel mir auf, dass es zwei offene Ports mit dem Namen “Workerd” gab, was f\u00fcr den Cloudflare-Worker steht. Nachdem ich beide Ports geschlossen und das Projekt neu gestartet hatte, funktionierte der Code wie erwartet und die Logs wurden ausgegeben.<\/p>\n\n\n\n
Es stellte sich also heraus, dass mein Frontend das Backend von einem \u00e4lteren Code-Stand anfragte und nicht den aktuellen Code, an dem ich gerade arbeitete.<\/p>\n\n\n\n
Gitignore<\/h2>\n\n\n\n
W\u00e4hrend der Entwicklung erstellte ich einige Types und speicherte diese im “types”-Ordner ab. Als ich jedoch versuchte, das Projekt zu deployen, trat pl\u00f6tzlich ein Fehler beim Import der Types auf: Angeblich konnte der Pfad nicht gefunden werden. Ich \u00fcberpr\u00fcfte als Erstes den Pfad und war \u00fcber den Fehler verwundert, da alles korrekt aussah. Dann bemerkte ich jedoch, dass der “types”-Ordner im GitHub-Repository fehlte. Somit war dann klar, dass dieser Ordner aufgrund der Gitignore-Datei nicht committet wurde.
<\/p>\n\n\n\n
CORS Error<\/h2>\n\n\n\n
Als das Backend und das Frontend deployt waren, konnte das Frontend aufgrund eines CORS-Fehlers nicht auf das Backend zugreifen.<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Der Fehler entstand dadurch, dass ich die URL des Backends aus der Browser-Suchleiste kopierte und dabei ein Slash am Ende der URL hinzuf\u00fcgt war.<\/p>\n\n\n\n
Learnings<\/h2>\n\n\n\n