Serverless Webapp Tooling auf AWS (2/2)
Im ersten Teil dieser Blogpostserie haben wir vorgestellt, welche Tools es braucht, um eine Fullstack Webapp Serverless zu entwickeln und auf AWS einzurichten. Im zweiten Teil bringen wir diese Tools zu einem Serverless-Techstack zusammen und zeigen auf, wie damit eine Webapplikation entwickelt werden kann.
Einleitung zur Webapp
Um eine Webapp Serverless zu bauen, gibt es viele verschiedene Ansätze. Die statische Webseite, die für den Client ausgeliefert werden soll, kann bei AWS auf Cloudfront und S3 gehostet werden. Wenn Serverlogik gebraucht wird, kommen die Serverless Lambda Functions von AWS zum Einsatz. Diese bieten bereits eine Runtime und es muss nur noch die Applikationslogik beigesteuert werden. Für einfache Applikationen reicht es, die Applikationslogik in Lambda Functions und Endpunkte zu unterteilen und eine Statische SPA als Frontend zu bauen. Es gibt aber auch Frameworks wie Nextjs, Astro und Remixjs, die eine Fullstacklösung bieten. Sie kümmern sich um das Codesplitting zwischen Server und Client. Dies führt zu einer stärkeren Kopplung, kann aber Redundanzen und Boilerplatecode verhindern.
Stack Übersicht
Im Serverlessumfeld wurden viele verschiede Technologien und Tools mit dem Versprechen entwickelt, bestimmte Aufgaben zu vereinfachen. In diesem Abschnitt stellen wir die Tools, die wir für unsere interne Applikation verwendet haben, vor.
Fullstack Webapp
Nextjs ist ein Framework basierend auf React.js, das nicht nur Client, sondern auch seitens Server rendert. Dies hat einige Vorteile wie z.B. schnellere Ladezeiten und SEO-Optimierung. Das Framework ist für den Serverlessbetrieb auf Vercel ausgelegt. Es kommt mit vielen Mechanismen, um das Rendern zu optimieren sowie Cachingstrategien, die die Wartezeiten und den Resourcenverbrauch reduzieren sollen. Weil Nextjs serverseitig agiert, sind Datenbankinteraktionen, serverseitige Authentifizierung und andere Backendaufgaben auch innerhalb der Webapplikation möglich. Dadurch wird ein zusätzliches Backend überflüssig.
Mögliche Alternativen sind Astro und Remix. Auch sie erlauben einen Serverlessbetrieb und serverseitiges Rendern.
Infrastruktur as Code
SST ist ein Code as Config Framework, das die AWS Cloudformation Configuration abstrahiert und die Interaktion mit der Infrastruktur vereinfacht. Konfiguriert wird in Typescript. Dies bietet auch den Vorteil, dass die konfigurierten Objekte Typesafe sind und schon im Voraus Fehler aufgedeckt werden können. Erstellen und Interagieren mit S3 Buckets, Secrets und Tabellen sind in der Regel nur kleine Konfigurationen. Ein weiterer grosser Vorteil ist das lokale Entwickeln. SST bietet eine Art Proxy an, um die AWS-Dienste lokal anzusprechen und integriert das mit dem Hotreloading der Applikation. Dies erfordert für das Entwickeln einen AWS-Account als Entwicklungsumgebung, bietet aber den Vorteil, dass die Applikation sich genau so verhält wie in der Produktion.
SST bietet nicht nur die Konfiguration an, sondern auch eine CLI, mit der man in einem Befehl Umgebungen erstellen und wieder entfernen kann. Das Serverless Deployment von Nextjs benötigt durch das Static und Dynamic Rendering eine komplexere Architektur, um alle Features zu unterstützten. Beim Deployment auf Vercel (ihre eigene Infrastruktur) wird dies übernommen. Wenn ein anderer Cloudanbieter wie z.B. AWS benutzt werden soll, müssen diese Funktionen selbstständig beim jeweiligen Cloudanbieter konfiguriert werden. Die Community hat für diesen Schritt das OpenNext Projekt entwickelt, welches diese Aufgabe für das AWS Deployment übernimmt. Das komplette Setup kann in Figure 2 betrachtet werden und ist ein anschauliches Beispiel für die Unterschiede zu einer eher traditionelleren Architektur mit einem Backend, dass all diese Funktionalitäten verkörpert.
Einige Alternativen, die wir in Betracht gezogen haben, sind Terraform und Serverless Framework. Das Zusammenspiel mit Nextjs hat sich aber als sinnvoller erwiesen.
Datenbank
Um Daten für die Webapplikation speichern zu können, gibt es mehrere mögliche Datenbanken. Unser Anspruch an die Datenbanklösung war das On-Demand Zahlungsmodell. Wir wollen Fixkosten vermeiden und eine durchgänge Serverlesslösung. Wir haben uns für das On-Demand verteilte Datanbanksystem DynamoDB von AWS entschieden. Dies vereinfacht das Monitoring und Tooling, da die DynamoDB ebenfalls mit SST verwaltet werden kann. Eine Alternative währe z.B. Mongodb mit ihrem Atlas Serverless Modell.
Um in unserer Nextjs App mit der DynamoDB zu interagieren, haben wir uns für das ElectroDB Framework entschieden. Es hilft, optimierte „Single Table“ Tabellen zu verwalten, übernimmt ORM Aufgaben und ermöglicht so einen schnellen und einfachen Workflow mit der DynamoDB.
Authentifizierung
NextAuth ist eine konkurrenzlose Lösung im Nextjs Ökosystem. Sie bietet für alle State of the Art Authentifizierungslösungen einen standardisierten Adapter und eine Server- und Clientseitige Sessionverwaltung durch secured Cookies. Wir haben sie innerhalb weniger Schritte erfolgreich an unser bestehendes Keycloak SSO System angebunden. In unserer Applikation können wir nun auf die Nutzerrollen und Berechtigungen reagieren. Falls kein SSO und IAM wie z.B. Keycloak vorhanden ist, kann der Cognito Service von AWS eine mögliche Lösung sein, um Benutzer:innen zentral und unabhängig von der Applikation zu verwalten.
Diskussion
In diesem Blog haben wir uns mit verschieden Problemstellungen und Lösungen beschäftigt, die sich bei der Erstellung einer Serverless Webapp ergeben. Da die Integration und Kombination auch eine gewisse Komplexität in sich birgt, sollte der Einsatz der Tools immer abhängig von der Nutzung abgewogen werden.
Die Idee vom Serverless Computing ist die Trennung von den einzelnen Abläufen in Funktionen. Diese werden dann bei einem Event gestartet und verarbeiten die Anfrage. Diese eventbasierte Architektur unterscheidet sich stark von einer monolithischen Applikation und erfordert ein Umdenken. Die grossen Vorteile von Serverless sind die Clouddienste, die einfach verknüpft werden, automatisch skalieren und sich reaktiv ergänzen. Das zwingt den/die Anwender:in dazu, die Serverlesssoftware stark an den/die Clouddienstleister:in zu knüpfen. Dies bringt zwar eine Ersparnis an Zeit, Aufwänden und Fixkosten mit sich. Eine Migration zu einem/einer anderen Anbieter:in wird aber stark erschwert. Bei einem plattformagnostischen Ansatz gehen deshalb viele Vorteile von Serverless verloren. Falls dies doch gewünscht wird, sollte vielleicht ein anderes Paradigma gewählt werden, da das Serverlessökosystem stark von dem/der Cloudanbieter:in abhängt.
Möchtest du mehr zu unserer Webapp AWS Serverless Lösung wissen? Melde dich bei uns, wir beraten dich gerne.
