Was ist eine Webanwendungsarchitektur?<\/h2>\n
Um die Diskussion zu beginnen, wollen wir mit der Definition der Webanwendungsarchitektur beginnen.<\/p>\n
Einfach ausgedr\u00fcckt, ist die Architektur einer Webanwendung eine \u00dcbersicht dar\u00fcber, wie die verschiedenen Komponenten deiner Webanwendung miteinander interagieren.<\/p>\n
Sie kann so einfach sein wie die Definition der Beziehung zwischen dem Client und dem Server. Sie kann aber auch so komplex sein, dass sie die Beziehungen zwischen einem Schwarm von Container-Backend-Servern, Load Balancern, API-Gateways und benutzerorientierten Single-Page-Frontends definiert.<\/p>\n
Dabei geht es selten um die Wahl der Programmiersprache<\/a>, in der du deinen Code schreibst.<\/p>\n Die Art und Weise, wie du deine Webanwendung gestaltest, spielt sowohl f\u00fcr die Benutzerfreundlichkeit als auch f\u00fcr deine Kostenoptimierung eine wichtige Rolle. Hier siehst du ein Beispiel f\u00fcr die Architektur einer Web-App auf dem Papier:<\/p>\n Die Architektur einer Webanwendung ist zweifelsohne einer der wichtigsten Bestandteile deiner Webanwendung. Wenn du dich bei der Entwicklung deiner Webanwendung f\u00fcr eine bestimmte Architektur entscheidest, hast du viele Vorteile, wenn es um die Wartung und Weiterentwicklung deiner Anwendung geht.<\/p>\n Durch die Wahl der richtigen Architektur werden diese Vorteile jedoch noch verst\u00e4rkt.<\/p>\n Hier sind einige der wichtigsten Gr\u00fcnde, warum du die Einf\u00fchrung einer Webanwendungsarchitektur ernsthaft in Betracht ziehen solltest.<\/p>\n Deine App ist ein wichtiges Tor zu deinem Unternehmen, und die Bed\u00fcrfnisse deines Unternehmens entwickeln sich mit dem sich ver\u00e4ndernden Markt. Wenn du mithalten willst, muss deine App flexibel genug sein, um sich an die sich \u00e4ndernden Anforderungen deines Unternehmens anzupassen. Wenn du eine App entwickelst, ohne an die eingebaute Flexibilit\u00e4t zu denken, wirst du zwangsl\u00e4ufig immer mehr Zeit und M\u00fche aufwenden m\u00fcssen, um kleine Anpassungen in deiner App vorzunehmen.<\/p>\n Die richtige Architektur einer Webanwendung ber\u00fccksichtigt bereits einige der \u00c4nderungen, die dein Unternehmen in Zukunft brauchen k\u00f6nnte. Wenn du zum Beispiel wei\u00dft, dass du eine E-Commerce-Anwendung baust, die skalierbar ist und eines Tages eine Vielzahl von Diensten f\u00fcr eine gro\u00dfe Anzahl von Kunden bereitstellen soll, bietet dir eine Microservices-Architektur mehr Flexibilit\u00e4t als eine monolithische.<\/p>\n Wenn du hingegen eine interne Anwendung f\u00fcr dein Unternehmen mit nur ein oder zwei festen Anforderungen entwickelst, kannst du dich f\u00fcr einen einfacheren Monolithen entscheiden, um die Entwicklung zu beschleunigen und deine Codebasis sauber zu halten.<\/p>\n Wie bereits erw\u00e4hnt, bietet dir die richtige Web-App-Architektur einen bequemeren Fahrplan f\u00fcr die Entwicklung. Die Architektur sorgt f\u00fcr gen\u00fcgend Modularit\u00e4t in deinem System, um Komponenten bei Bedarf zu isolieren, und du hast die Freiheit, die richtige Projektstruktur f\u00fcr jedes deiner Module und Komponenten zu w\u00e4hlen.<\/p>\n Wenn du dich in die App-Entwicklung st\u00fcrzt, ohne eine Architektur im Kopf zu haben, l\u00e4ufst du Gefahr, Zeit und Geld damit zu verschwenden, deine Komponenten neu zu organisieren und neue Regeln aufzustellen, um die Zusammenarbeit zwischen deinen Teammitgliedern<\/a> zu erleichtern – Zeit und Geld, die du anderweitig h\u00e4ttest verwenden k\u00f6nnen.<\/p>\n Du schreibst nicht nur den Code deiner App, sondern verbringst auch viel Zeit damit, ihn zu verwalten. Das Organisieren deiner Projektdateien, das Aufteilen deiner App in Module und das Einrichten benutzerdefinierter Pipelines sind nur einige der Aufgaben, die f\u00fcr eine reibungslose Entwicklung aktiv gepflegt werden m\u00fcssen.<\/p>\n Die richtige Web-App-Architektur macht es dir leicht, \u00c4nderungen vorzunehmen. Du kannst komponentenspezifische Best Practices implementieren, die Schwachstellen deiner App voneinander trennen und die einzelnen Funktionen unabh\u00e4ngig und lose gekoppelt halten. Es ist nicht so, dass diese Dinge nicht auch ohne Architektur m\u00f6glich w\u00e4ren, aber die richtige Architektur macht das alles viel einfacher.<\/p>\n Wenn du dich an eine vordefinierte Architektur h\u00e4ltst, kannst du deine Anwendungen auch schneller entwickeln. Die richtige Architektur in Kombination mit einer soliden Versionskontrollstrategie<\/a> erm\u00f6glicht es deinen Entwicklern, parallel zueinander zu arbeiten und Funktionen schneller zu entwickeln.<\/p>\n Eine Web-App-Architektur macht deine Anwendung auch zukunftssicher. Sobald du eine solide Strategie f\u00fcr die Organisation der Komponenten deiner Anwendung festgelegt hast, kannst du diese Komponenten problemlos nach und nach auf neuere Technologien umstellen, ohne deine gesamte Anwendung neu entwickeln zu m\u00fcssen.<\/p>\n Die meisten Web-App-Architekturen ber\u00fccksichtigen bei der Strukturierung der Komponenten auch die Sicherheit. Entwickler\/innen k\u00f6nnen im Voraus Ma\u00dfnahmen und Praktiken planen, um die Sicherheit der App zu verbessern<\/a>, bevor sie an die Nutzer\/innen ausgeliefert wird.<\/p>\n Der Aufbau einer OTT-Video-Streaming-App<\/a>, die sowohl kostenpflichtige als auch kostenlose Inhalte anbietet, ist zum Beispiel mit Microservices sinnvoller, da die Microservices-Architektur es dir erm\u00f6glicht, deine App in gesch\u00e4ftsfreundliche Komponenten aufzuteilen, wie z. B. die Benutzerauthentifizierung<\/a> und das Streaming von kostenlosen oder kostenpflichtigen Inhalten. Wenn dein Benutzerauthentifizierungsmodul ausf\u00e4llt, kannst du deine App so konfigurieren, dass der Zugriff auf das Modul f\u00fcr kostenpflichtige Inhalte eingeschr\u00e4nkt<\/a> wird, bis die Benutzerauthentifizierung wieder funktioniert, w\u00e4hrend das Modul f\u00fcr kostenlose Inhalte f\u00fcr deine Benutzer weiterhin verf\u00fcgbar ist.<\/p>\n In einem anderen Fall, in dem dieselbe Anwendung als eng gekoppelter Monolith konzipiert wurde, w\u00fcrde ein Ausfall des Authentifizierungsdienstes entweder einen Ausfall der Anwendung<\/a> oder die kostenlose Bereitstellung von kostenpflichtigen Inhalten bedeuten – ein Ergebnis, das du um jeden Preis vermeiden willst.<\/p>\n Bevor wir dar\u00fcber sprechen, wie die Architektur von Webanwendungen funktioniert, ist es wichtig zu verstehen, wie eine einfache Website funktioniert:<\/p>\n Wenn du ein bisschen tiefer eintauchst, siehst du, wie eine Webanwendung<\/em> eine Anfrage bearbeitet:<\/p>\n Nachdem du nun eine grundlegende Vorstellung davon hast, was eine Webanwendungsarchitektur ist, werfen wir einen detaillierten Blick auf einige der beliebtesten Arten von Webanwendungsarchitekturen, die im Internet verwendet werden.<\/p>\n Die Architektur einer Single-Page-Anwendung (SPA) ist so einfach wie ihr Name: Die gesamte Anwendung basiert auf einer einzigen Seite. Sobald der Nutzer deine Anwendung aufruft, muss er nicht mehr zu anderen Webseiten navigieren. Die App ist so dynamisch gestaltet, dass sie die Bildschirme abruft und darstellt, die den Anforderungen der Nutzer\/innen entsprechen, w\u00e4hrend sie durch die App navigieren.<\/p>\n SPAs sind gro\u00dfartig, wenn es darum geht, den Endnutzern oder Verbrauchern ein schnelles und nahtloses Erlebnis zu bieten. Allerdings fehlt ihnen der Touch einer traditionellen Website, und sie lassen sich nur schwer f\u00fcr SEO optimieren<\/a>.<\/p>\n Zu den Vorteilen der SPA-Architektur geh\u00f6ren:<\/p>\n Einige der Nachteile der SPA-Architektur sind:<\/p>\n Die Progressive Web Application (PWA)-Architektur baut auf der Single Page Architecture auf und bietet Offline-Funktionen f\u00fcr deine Webanwendung. Technologien wie Capacitor und Ionic werden verwendet, um PWAs zu erstellen, die den Nutzern auf allen Plattformen ein einheitliches Erlebnis bieten<\/a>.<\/p>\n \u00c4hnlich wie SPAs sind PWAs reibungslos und nahtlos. Mit der zus\u00e4tzlichen M\u00f6glichkeit, auf den Ger\u00e4ten der Nutzer\/innen installiert zu werden (\u00fcber Service Worker), erhalten deine Nutzer\/innen eine einheitlichere Erfahrung mit deiner Anwendung.<\/p>\n Gleichzeitig kann es schwierig sein, solche Apps f\u00fcr SEO zu optimieren, und Updates f\u00fcr installierte Apps lassen sich nur schwer einspielen.<\/p>\n Es gibt viele Vorteile der PWA-Architektur, darunter:<\/p>\n Einige der Nachteile der PWA-Architektur k\u00f6nnen sein:<\/p>\n Beim serverseitigen Rendering (SSR) werden die Frontend-Webseiten auf einem Backend-Server gerendert, nachdem sie vom Nutzer angefordert wurden. Dies tr\u00e4gt dazu bei, die Last auf dem Client-Ger\u00e4t zu verringern, da es eine statische HTML-, CSS- und JS-Webseite erh\u00e4lt.<\/p>\n SSR-Apps sind bei Blogs und E-Commerce-Websites sehr beliebt. Das liegt daran, dass sie Linkmanagement und SEO ganz einfach machen. Au\u00dferdem ist der erste Rendervorgang bei SSR-Apps recht schnell, da der Client keinen JS-Code verarbeiten muss, um die Bildschirme zu rendern.<\/p>\n Einige der Vorteile der SSR-Architektur werden im Folgenden aufgef\u00fchrt:<\/p>\n Zu den Nachteilen der SSR-Architektur geh\u00f6ren:<\/p>\n Die Architektur f\u00fcr vorgerenderte Anwendungen ist auch als statische Website-Generierungsarchitektur bekannt. Bei dieser Architektur werden die Frontend-Webseiten der Anwendung vorgeneriert und als einfache HTML-, CSS- und JS-Dateien auf dem Server gespeichert. Sobald ein Nutzer eine Seite anfordert, wird sie direkt abgerufen und angezeigt. Das macht die Web-App sehr schnell, mit minimalen Ladezeiten. Allerdings verl\u00e4ngert diese Architektur auch die Entwicklungszeit der App, da die Webseiten w\u00e4hrend des Entwicklungsprozesses gerendert werden.<\/p>\n Vorgerenderte Web-Apps sind ideal, wenn du statische Inhalte wie Blogs oder Produktdetails erstellen willst, die sich nicht oft \u00e4ndern. Du kannst auch Vorlagen verwenden, um dein Webseitendesign zu vereinfachen. Allerdings ist es fast unm\u00f6glich, mit dieser Architektur dynamische Webanwendungen zu erstellen. Wenn du eine Suchseite erstellen willst, die die Suchanfrage in ihren Pfad aufnimmt (so etwas wie Da jede m\u00f6gliche Route der App w\u00e4hrend des Build-Prozesses vorgerendert wird, ist es unm\u00f6glich, dynamische Routen wie oben beschrieben zu erstellen, da es unendlich viele M\u00f6glichkeiten gibt, die w\u00e4hrend des Build-Prozesses nicht vorgerendert werden k\u00f6nnen (und es macht auch keinen Sinn, dies zu tun).<\/p>\n Einige der wichtigsten Vorteile einer vorgerenderten Anwendungsarchitektur sind:<\/p>\n Wie jedes Architekturmodell hat auch die vorgerenderte Architektur ihre Nachteile:<\/p>\n Isomorphe Anwendungen sind eine Mischung aus serverseitig gerenderten Anwendungen und SPAs. Das bedeutet, dass solche Apps zun\u00e4chst auf dem Server als normale serverseitig gerenderte App gerendert werden. Sobald sie vom Client empfangen werden, hydratisiert sich die App selbst und f\u00fcgt das virtuelle DOM f\u00fcr eine schnellere und effizientere Client-Verarbeitung hinzu. Dadurch wird die App im Wesentlichen zu einer Single-Page-Anwendung.<\/p>\n Isomorph bringt das Beste aus beiden Welten zusammen. Dank der SPA erh\u00e4ltst du eine superschnelle Verarbeitung und Benutzeroberfl\u00e4che auf dem Client. Dank des serverseitigen Renderings erh\u00e4ltst du au\u00dferdem eine schnelle Darstellung und umfassende Unterst\u00fctzung f\u00fcr SEO und Verlinkung.<\/p>\n Hier sind nur einige der Vorteile der isomorphen Anwendungsarchitektur:<\/p>\n Einige der Nachteile einer isomorphen Anwendungsarchitektur k\u00f6nnen sein:<\/p>\n Die serviceorientierte Architektur ist eine der beliebtesten Alternativen zum traditionellen monolithischen Aufbau von Anwendungen. Bei dieser Architektur werden die Webanwendungen in Dienste unterteilt, die jeweils eine funktionale Einheit des Unternehmens darstellen. Diese Dienste sind lose miteinander gekoppelt und interagieren \u00fcber das Medium der Nachrichten\u00fcbermittlung miteinander.<\/p>\n Eine serviceorientierte Architektur erh\u00f6ht die Stabilit\u00e4t und Skalierbarkeit deiner Anwendung. Allerdings ist die Gr\u00f6\u00dfe der Dienste in der SOA nicht klar definiert und in der Regel an gesch\u00e4ftliche und nicht an technische Komponenten gebunden, so dass die Wartung manchmal ein Problem darstellen kann.<\/p>\n Zu den wichtigsten Vorteilen einer serviceorientierten Architektur geh\u00f6ren:<\/p>\n Hier ist eine Liste mit m\u00f6glichen Nachteilen der serviceorientierten Architektur:<\/p>\n Die Microservices-Architektur wurde entwickelt, um die Probleme der serviceorientierten Architektur zu l\u00f6sen. Microservices sind noch mehr modulare Komponenten, die zu einer Webanwendung zusammengef\u00fcgt werden. Der Schwerpunkt von Microservices liegt jedoch darauf, jede Komponente klein und in einem begrenzten Kontext zu halten. Bounded Context bedeutet im Wesentlichen, dass der Code und die Daten jedes Microservices mit minimalen Abh\u00e4ngigkeiten von anderen Microservices gekoppelt sind.<\/p>\n Die Microservices-Architektur ist wahrscheinlich die beste Architektur, um Anwendungen zu entwickeln, die eines Tages auf Tausende und Millionen von Nutzern skalieren sollen. Jede Komponente ist belastbar, skalierbar und einfach zu warten. Allerdings erfordert die Aufrechterhaltung des DevOps-Lebenszyklus f\u00fcr eine Microservices-basierte App zus\u00e4tzlichen Aufwand, weshalb sie f\u00fcr kleinere Anwendungsf\u00e4lle m\u00f6glicherweise nicht geeignet ist.<\/p>\n Einige Vorteile der Microservices-Architektur sind:<\/p>\n Ein Nachteil der Microservices-Architektur kann sein:<\/p>\n Die serverlose Architektur ist ein weiterer hei\u00dfer Kandidat in der Welt der Web-App-Architekturen. Bei dieser Architektur geht es darum, deine Anwendung in die Funktionen zu zerlegen, die sie ausf\u00fchren soll. Diese Funktionen werden dann auf FaaS-Plattformen (Function-as-a-Service) als Funktionen gehostet, die aufgerufen werden, wenn Anfragen eingehen.<\/p>\n Im Gegensatz zu den meisten anderen Architekturen auf dieser Liste laufen Apps, die mit der serverlosen Architektur entwickelt wurden, nicht die ganze Zeit \u00fcber. Sie verhalten sich wie Funktionen – sie warten darauf, dass sie aufgerufen werden, und wenn sie aufgerufen werden, f\u00fchren sie den definierten Prozess aus und geben ein Ergebnis zur\u00fcck. Dadurch reduzieren sie die Wartungskosten und sind ohne gro\u00dfen Aufwand hoch skalierbar. Allerdings ist es schwierig, mit solchen Komponenten langwierige Tasks auszuf\u00fchren.<\/p>\n Hier sind die wichtigsten Vorteile der serverlosen Architektur:<\/p>\n Nachfolgend sind einige Nachteile der serverlosen Architektur aufgef\u00fchrt:<\/p>\n Die Architekturen der Webanwendungen, die du oben gesehen hast, sehen zwar alle recht unterschiedlich aus, aber ihre Komponenten lassen sich logisch in bestimmte Schichten einteilen, die dabei helfen, ein Gesch\u00e4ftsziel zu erreichen.<\/p>\n Die Pr\u00e4sentationsschicht umfasst alle Elemente einer Webanwendung, die f\u00fcr die Endnutzer sichtbar sind. In erster Linie besteht die Pr\u00e4sentationsschicht aus dem Frontend-Client. Sie enth\u00e4lt aber auch die Logik, die du in deinem Backend geschrieben hast, um dein Frontend dynamisch zu machen. So hast du die M\u00f6glichkeit, deinen Nutzern eine auf ihr Profil und ihre Bed\u00fcrfnisse zugeschnittene Benutzeroberfl\u00e4che zu bieten.<\/p>\n Drei grundlegende Technologien werden zum Aufbau dieser Schicht verwendet: HTML, CSS und JavaScript. HTML entwirft dein Frontend, CSS gestaltet es und JS haucht Leben hinein (d.h. steuert das Verhalten, wenn die Nutzer\/innen damit interagieren). Zus\u00e4tzlich zu diesen drei Technologien kannst du jede Art von Framework<\/a> verwenden, um die Entwicklung zu vereinfachen. Einige g\u00e4ngige Frontend-Frameworks sind Laravel<\/a>, React, NextJS, Vue, GatsbyJS, etc.<\/p>\n Die Business-Schicht ist f\u00fcr die Arbeitslogik deiner App verantwortlich und verwaltet sie. In der Regel handelt es sich um einen Backend-Dienst, der Anfragen vom Kunden entgegennimmt und verarbeitet. Sie kontrolliert, worauf der Nutzer zugreifen kann und bestimmt, wie die Infrastruktur genutzt wird, um Nutzeranfragen zu bedienen.<\/p>\n Im Fall einer Hotelbuchungs-App dient deine Client-App als Portal, in das die Nutzer Hotelnamen und andere relevante Daten eingeben k\u00f6nnen. Sobald der Nutzer jedoch auf die Suchschaltfl\u00e4che klickt, erh\u00e4lt die Business-Schicht die Anfrage und startet die Logik f\u00fcr die Suche nach verf\u00fcgbaren Hotelzimmern, die deinen Anforderungen entsprechen. Der Kunde erh\u00e4lt dann einfach eine Liste von Hotelzimmern, ohne zu wissen, wie diese Liste erstellt wurde oder warum die Listenelemente so angeordnet sind, wie sie gesendet wurden.<\/p>\n Das Vorhandensein einer solchen Schicht stellt sicher, dass deine Gesch\u00e4ftslogik f\u00fcr deinen Kunden und letztendlich f\u00fcr die Nutzer nicht sichtbar ist. Die Isolierung der Gesch\u00e4ftslogik ist bei sensiblen Vorg\u00e4ngen wie der Zahlungsabwicklung oder der Verwaltung von Gesundheitsdaten sehr hilfreich.<\/p>\n Die Persistenzschicht ist f\u00fcr die Kontrolle des Zugriffs auf deine Datenspeicher zust\u00e4ndig. Sie fungiert als zus\u00e4tzliche Abstraktionsebene zwischen deinen Datenspeichern und deiner Business-Schicht. Sie nimmt alle datenbezogenen Aufrufe von den Business-Schichten entgegen und verarbeitet sie, indem sie sichere Verbindungen zur Datenbank herstellt.<\/p>\n Diese Schicht besteht normalerweise aus einem Datenbankserver<\/a>. Du kannst diese Schicht selbst einrichten, indem du eine Datenbank und einen Datenbankserver in deiner On-Prem-Infrastruktur bereitstellst, oder du entscheidest dich f\u00fcr eine ferngesteuerte\/verwaltete L\u00f6sung von einem der f\u00fchrenden Cloud-Infrastrukturanbieter wie AWS, GCP, Microsoft Azure usw.<\/p>\n Nachdem du nun wei\u00dft, was eine Webanwendungsarchitektur ausmacht, wollen wir uns die einzelnen Komponenten einer Webanwendung genauer ansehen. Wir gliedern diese Diskussion in zwei gro\u00dfe Bereiche: serverseitige Komponenten und clientseitige Komponenten, oder Backend- und Frontend-Komponenten<\/a>.<\/p>\n Serverseitige Komponenten sind die Komponenten, die sich im Backend deiner Webanwendung befinden. Sie sind f\u00fcr die Nutzer nicht direkt sichtbar und enthalten die wichtigste Gesch\u00e4ftslogik und Ressourcen f\u00fcr deine Webanwendung.<\/p>\n DNS ist daf\u00fcr verantwortlich, zu kontrollieren, wie deine Anwendung im Web dargestellt wird. DNS-Eintr\u00e4ge werden von HTTP-Clients (das kann auch ein Browser sein) verwendet, um die Komponenten deiner App zu finden und Anfragen an sie zu senden. DNS wird auch intern von deinen Frontend-Clients verwendet, um den Standort deiner Webserver und API-Endpunkte aufzul\u00f6sen, um Anfragen zu senden und Benutzeraktionen zu verarbeiten.<\/p>\n Der Load Balancer ist eine weitere beliebte Komponente der Architektur von Webanwendungen. Ein Load Balancer wird verwendet, um HTTP-Anfragen auf mehrere identische Webserver zu verteilen. Mehrere Webserver dienen der Redundanz, um die Fehlertoleranz zu erh\u00f6hen und den Datenverkehr so zu verteilen, dass die Leistung hoch bleibt.<\/p>\n API-Endpunkte werden verwendet, um Backend-Dienste f\u00fcr die Frontend-Anwendung bereitzustellen. Sie erleichtern die Kommunikation zwischen dem Client und dem Server und manchmal sogar zwischen mehreren Servern.<\/p>\n Die Datenspeicherung ist ein wichtiger Bestandteil der meisten modernen Anwendungen, denn es gibt immer einige Anwendungsdaten, die \u00fcber mehrere Benutzersitzungen hinweg aufbewahrt werden m\u00fcssen. Es gibt zwei Arten der Datenspeicherung:<\/p>\n Caching ist eine optionale Funktion, die oft in Web-App-Architekturen implementiert wird, um Inhalte schneller an die Nutzer\/innen zu liefern. Ein gro\u00dfer Teil der App-Inhalte wiederholt sich oft f\u00fcr eine gewisse Zeit, wenn auch nicht immer. Anstatt sie aus einem Datenspeicher abzurufen und zu verarbeiten, bevor sie an den Nutzer zur\u00fcckgeschickt werden, werden sie oft zwischengespeichert. Hier sind die beiden beliebtesten Arten des Cachings, die in Webanwendungen verwendet werden:<\/p>\n Neben der Benutzeroberfl\u00e4che (Frontend) und der Bearbeitung von Anfragen (Backend) gibt es eine weitere, etwas weniger beliebte Kategorie von Webanwendungskomponenten. Jobs sind oft Hintergrunddienste, die Aufgaben erledigen sollen, die nicht zeitkritisch oder synchron sind.<\/p>\n CRON-Jobs sind Jobs, die in einem bestimmten Zeitraum immer wieder ausgef\u00fchrt werden. Diese Jobs werden im Backend geplant, um Wartungsroutinen automatisch zu bestimmten Zeiten auszuf\u00fchren. Einige h\u00e4ufige Anwendungsf\u00e4lle sind das L\u00f6schen von Duplikaten\/alten Datens\u00e4tzen aus der Datenbank, das Versenden von Erinnerungs-E-Mails an Kunden usw.<\/p>\n Clientseitige Komponenten sind diejenigen, die entweder direkt oder indirekt f\u00fcr deine Nutzer\/innen sichtbar sind.<\/p>\n Es gibt haupts\u00e4chlich zwei Arten von Komponenten in dieser Kategorie.<\/p>\n Die Benutzeroberfl\u00e4che ist der visuelle Aspekt deiner Anwendung. Sie ist das, was deine Nutzer sehen und womit sie interagieren, um auf deine Dienste zuzugreifen.<\/p>\n Die Frontend-Benutzeroberfl\u00e4che basiert meist auf drei g\u00e4ngigen Technologien: HTML, CSS und JavaScript<\/a>. Die Frontend-Benutzeroberfl\u00e4che kann eine eigenst\u00e4ndige Anwendung mit einem eigenen Softwareentwicklungszyklus sein.<\/p>\n Diese Benutzeroberfl\u00e4chen enthalten nicht viel von deiner Gesch\u00e4ftslogik, da sie direkt f\u00fcr deine Benutzer sichtbar sind. Wenn ein b\u00f6swilliger Benutzer versucht, deine Frontend-Anwendung zur\u00fcckzuentwickeln, kann er Informationen \u00fcber die Funktionsweise deines Unternehmens erhalten und illegale Aktivit\u00e4ten wie Markenimitation<\/a> und Datendiebstahl durchf\u00fchren.<\/p>\n Da die Benutzeroberfl\u00e4che des Frontends den Nutzern direkt zug\u00e4nglich ist, solltest du sie so optimieren, dass sie m\u00f6glichst schnell l\u00e4dt<\/a> und schnell reagiert. Manchmal kann dies dazu beitragen, dass du deinen Nutzern ein besseres Erlebnis bietest und dadurch dein Gesch\u00e4ftswachstum steigerst.<\/p>\n Manchmal musst du vielleicht einen Teil deiner Gesch\u00e4ftslogik auf deinem Client speichern, um einfachere Vorg\u00e4nge schnell ausf\u00fchren zu k\u00f6nnen. Clientseitige Logik, die sich normalerweise in deiner Frontend-Anwendung befindet, kann dir helfen, den Weg zum Server zu \u00fcberspringen und deinen Nutzern ein schnelleres Erlebnis zu bieten.<\/p>\n Dies ist eine optionale Funktion der clientseitigen Komponenten. In manchen F\u00e4llen wird die Gesch\u00e4ftslogik der App vollst\u00e4ndig auf der Client-Seite gespeichert (vor allem, wenn du ohne einen traditionellen Backend-Server<\/a> arbeitest). Mit modernen L\u00f6sungen wie BaaS kannst du in deiner Frontend-App von unterwegs aus auf g\u00e4ngige Vorg\u00e4nge wie Authentifizierung, Datenspeicherung, Dateispeicherung usw. zugreifen.<\/p>\n Es gibt M\u00f6glichkeiten, diesen Code zu verschleiern oder zu verkleinern<\/a>, bevor du ihn deinen Nutzern zur Verf\u00fcgung stellst, um das Risiko eines Reverse-Engineerings zu minimieren.<\/p>\n Es gibt mehrere Modelle von Webanwendungsarchitekturen, die jeweils darauf basieren, wie Webserver mit ihren Datenspeichern verbunden sind.<\/p>\n Das einfachste Modell ist ein Webserver, der eine Verbindung zu einer Datenbankinstanz herstellt. Ein solches Modell ist einfach zu implementieren und zu warten und kann ohne gro\u00dfen Aufwand in die Produktion \u00fcbernommen werden.<\/p>\n Aufgrund seiner Einfachheit eignet sich dieses Modell zum Lernen und f\u00fcr kleine experimentelle Anwendungen, die keinem hohen Datenverkehr ausgesetzt sind. Neulinge k\u00f6nnen diese Anwendungen leicht einrichten und ausprobieren, um die Grundlagen der Web-App-Entwicklung<\/a> zu erlernen.<\/p>\n Allerdings sollte dieses Modell nicht in der Produktion eingesetzt werden, da es sehr unzuverl\u00e4ssig ist. Ein Problem mit dem Server oder der Datenbank kann zu Ausfallzeiten und Gesch\u00e4ftseinbu\u00dfen f\u00fchren.<\/p>\n Bei diesem Modell wird die Anwendung mit mehreren Servern und einer gemeinsamen Datenbank redundant ausgelegt.<\/p>\n Da mehrere Webserver gleichzeitig auf die Datenbank zugreifen, kann es zu Inkonsistenzen kommen. Um dies zu vermeiden, sind die Webserver zustandslos. Das bedeutet, dass die Server die Daten nicht \u00fcber mehrere Sitzungen hinweg aufbewahren, sondern sie lediglich verarbeiten und in der Datenbank speichern.<\/p>\n Apps, die mit diesem Modell erstellt werden, sind mit Sicherheit zuverl\u00e4ssiger als die mit dem vorherigen Modell, da das Vorhandensein mehrerer Webserver die Fehlertoleranz der Web-App erh\u00f6ht. Da die Datenbank jedoch immer noch eine gemeinsame Instanz ist, ist sie das schw\u00e4chste Glied in der Architektur und kann eine Fehlerquelle sein.<\/p>\n Dieses Modell ist eines der g\u00e4ngigsten, traditionellen Modelle f\u00fcr die Entwicklung von Webanwendungen.<\/p>\n In diesem Fall stellst du deine Anwendungslogik auf mehreren identischen Webserver-Instanzen bereit, die hinter einem Load Balancer zusammengeschlossen sind. Dein Datenspeicher wird ebenfalls \u00fcber mehrere Datenbankinstanzen verwaltet, um die Fehlertoleranz zu erh\u00f6hen.<\/p>\n Du kannst deine Datenbank auch auf die verf\u00fcgbaren Instanzen aufteilen, um die Leistung zu verbessern, oder Duplikate des gesamten Datenspeichers zur Redundanz vorhalten. In jedem Fall f\u00fchrt der Ausfall einer einzelnen Datenbankinstanz nicht zu einem kompletten Ausfall der Anwendung.<\/p>\n Dieses Modell wird wegen seiner Zuverl\u00e4ssigkeit und Skalierbarkeit sehr gesch\u00e4tzt. Die Entwicklung und Wartung von Anwendungen nach diesem Modell ist jedoch relativ kompliziert und erfordert teure, erfahrene Entwickler\/innen<\/a>. Daher wird dieses Modell nur empfohlen, wenn du in gro\u00dfem Ma\u00dfstab entwickelst.<\/p>\n W\u00e4hrend die drei oben genannten Modelle gut f\u00fcr monolithische Anwendungen geeignet sind, gibt es ein weiteres Modell f\u00fcr modulare Anwendungen.<\/p>\n Das Modell der Anwendungsdienste unterteilt eine Anwendung in kleinere Module, die auf Gesch\u00e4ftsfunktionen basieren. Diese Module k\u00f6nnen so klein wie eine Funktion oder so gro\u00df wie ein Dienst sein.<\/p>\n Die Idee dahinter ist, dass jede Gesch\u00e4ftsfunktion unabh\u00e4ngig und skalierbar ist. Jedes dieser Module kann sich eigenst\u00e4ndig mit der Datenbank verbinden. Du kannst sogar eigene Datenbankinstanzen einrichten, um die Skalierbarkeit deines Moduls zu gew\u00e4hrleisten.<\/p>\n Bei nicht-monolithischen Anwendungen ist dieses Modell sehr beliebt. \u00c4ltere monolithische Anwendungen werden oft auf dieses Modell migriert, um die Vorteile der Skalierbarkeit und Modularit\u00e4t zu nutzen. Die Verwaltung von Anwendungen, die nach einem solchen Modell aufgebaut sind, erfordert jedoch oft erfahrene Entwickler\/innen<\/a>, vor allem mit Erfahrung in DevOps und CI\/CD.<\/p>\n Hier sind einige Best Practices, die du in deinem Webanwendungsprojekt umsetzen kannst, um das Beste aus deiner gew\u00e4hlten Webanwendungsarchitektur herauszuholen.<\/p>\n Das kann nicht oft genug betont werden: Strebe immer responsive Frontends<\/a> an. Egal wie gro\u00df und komplex deine Webanwendung intern ist, deine Nutzerinnen und Nutzer bekommen alles \u00fcber die Frontend-Webseiten, Apps und Bildschirme zu sehen.<\/p>\n Wenn deine Nutzer diese Bildschirme als unintuitiv oder langsam empfinden, werden sie nicht lange genug bleiben, um das technische Wunderwerk, das deine Webanwendung ist, wertsch\u00e4tzen zu k\u00f6nnen.<\/p>\n Deshalb ist es sehr wichtig, leicht zug\u00e4ngliche, benutzerfreundliche und schlanke Frontends zu entwickeln.<\/p>\n Im Internet gibt es zahlreiche UI\/UX Best Practices<\/a>, die dir dabei helfen, herauszufinden, was f\u00fcr deine Nutzer\/innen am besten funktioniert. Hier findest du Fachleute, die sich mit benutzerfreundlichen Designs und Architekturen auskennen, die es deinen Nutzern erm\u00f6glichen, das Beste aus deinen Apps herauszuholen.<\/p>\n Wir raten dir, dir \u00fcber die Reaktionsf\u00e4higkeit deines Frontends Gedanken zu machen, bevor du dein Produkt f\u00fcr deine Nutzer\/innen bereitstellst.<\/p>\n Deine Frontends m\u00fcssen nicht nur leicht verst\u00e4ndlich sein, sondern auch schnell laden<\/a>.<\/p>\n Laut Portent<\/a> werden die h\u00f6chsten Konversionsraten im E-Commerce auf Seiten mit Ladezeiten zwischen 0 und 2 Sekunden erzielt, und laut Unbounce<\/a> geben rund 70 % der Verbraucher zu, dass die Ladezeit einer Seite ein wichtiger Faktor bei ihrer Entscheidung f\u00fcr einen Kauf bei einem Online-H\u00e4ndler ist.<\/p>\n Wenn du mobile-native Anwendungen entwickelst, kannst du dir in der Regel nicht sicher sein, welche Spezifikationen die Ger\u00e4te deiner Nutzer\/innen haben. Jedes Ger\u00e4t, das die Anforderungen deiner App nicht erf\u00fcllt, wird in der Regel als nicht geeignet f\u00fcr die App erkl\u00e4rt.<\/p>\n Im Web ist das jedoch ganz anders.<\/p>\n Wenn es um Webanwendungen geht, k\u00f6nnen deine Nutzer\/innen vom neuesten Apple Macbook M1 Pro bis hin zu alten Blackberry- und Nokia-Telefonen alles benutzen, um deine App anzusehen. Die Optimierung deines Frontends f\u00fcr eine so gro\u00dfe Bandbreite von Nutzern kann manchmal schwierig sein.<\/p>\n Dienste wie LightHouse und Google PageSpeed<\/a> fallen ein, wenn es um die Leistung deines Frontends geht. Du solltest solche Tools nutzen<\/a>, um deine Frontend-App zu testen, bevor du sie in die Produktion \u00fcberf\u00fchrst. Die meisten dieser Tools liefern dir eine Liste mit umsetzbaren Tipps, mit denen du die Leistung deiner App so weit wie m\u00f6glich verbessern kannst.<\/p>\n Die letzten 5-10% der App-Leistung sind in der Regel spezifisch f\u00fcr deinen Anwendungsfall und k\u00f6nnen nur von jemandem behoben werden, der deine App und ihre Technologien gut kennt. Es kann nie schaden, in die Web-Performance zu investieren<\/a>!<\/p>\n Wie bereits erw\u00e4hnt, sind PWAs die Designs der Zukunft. Sie eignen sich f\u00fcr die meisten Anwendungsf\u00e4lle und bieten das einheitlichste Erlebnis auf allen wichtigen Plattformen.<\/p>\n Du solltest so oft wie m\u00f6glich PWA f\u00fcr deine App verwenden. Das native Erlebnis im Web und auf dem Handy ist f\u00fcr deine Nutzerinnen und Nutzer von gro\u00dfer Bedeutung und kann auch deinen eigenen Arbeitsaufwand reduzieren.<\/p>\n PWAs laden au\u00dferdem schnell, sind einfach zu optimieren und schnell zu erstellen. Wenn du dich f\u00fcr PWAs entscheidest, kannst du deinen Fokus fr\u00fchzeitig von der Entwicklung auf das Gesch\u00e4ft verlagern.<\/p>\n Eine saubere Codebasis kann dir helfen, die meisten Probleme zu erkennen und zu l\u00f6sen, bevor sie Schaden anrichten. Hier sind einige Tipps, die du befolgen kannst, um sicherzustellen, dass deine Codebasis dir nicht mehr Probleme bereitet, als sie sollte.<\/p>\n CI\/CD steht f\u00fcr Continuous Integration\/Continuous Deployment (kontinuierliche Integration\/kontinuierliche Bereitstellung). CI\/CD-Prozesse sind entscheidend f\u00fcr die Entwicklung deiner Anwendung, da sie dir helfen, dein Projekt einfach zu erstellen, zu testen und zu verteilen.<\/p>\n Du willst sie aber nicht jedes Mal manuell ausf\u00fchren m\u00fcssen. Du solltest stattdessen Pipelines einrichten, die automatisch auf der Grundlage der Aktivit\u00e4ten deines Projekts ausgel\u00f6st werden. Du k\u00f6nntest zum Beispiel eine Pipeline einrichten, die deine Tests automatisch ausf\u00fchrt, wenn du deinen Code in dein Versionskontrollsystem<\/a> eintr\u00e4gst. Es gibt auch viele komplexere Anwendungsf\u00e4lle, wie z. B. das Erzeugen von plattform\u00fcbergreifenden Artefakten aus deinem Code-Repository, wenn ein Release erstellt wird.<\/p>\n Die M\u00f6glichkeiten sind endlos, es liegt also an dir, herauszufinden, wie du das Beste aus deinen CI\/CD-Pipelines herausholen kannst.<\/p>\n Die meisten modernen Apps bestehen aus mehreren Komponenten. Nimm die folgende App als Beispiel:<\/p>\n Client-Anfragen werden \u00fcber ein API-Gateway an die App weitergeleitet. Dieses erlaubt derzeit nur direkte Anfragen an das Home-Modul der App, aber in Zukunft k\u00f6nnte es den Zugriff auf weitere Komponenten erm\u00f6glichen, ohne den Umweg \u00fcber das Home-Modul.<\/p>\n Als N\u00e4chstes pr\u00fcft das Home-Modul eine externe Authentifizierungs-BaaS, bevor es den Zugriff erlaubt. Sobald der Kunde authentifiziert ist, kann er die Seiten „Profil aktualisieren“ oder „Profil anzeigen“ aufrufen. Diese beiden Seiten interagieren mit einer gemeinsamen, verwalteten Datenbankl\u00f6sung, die die Profildaten verwaltet.<\/p>\n Wie du siehst, sieht die Anwendung wie eine sehr einfache und minimale Version eines Online-Personenverzeichnisses<\/a> aus. Du kannst dein eigenes Profil hinzuf\u00fcgen\/aktualisieren oder andere verf\u00fcgbare Profile ansehen.<\/p>\n Hier ist eine kurze Legende zu den verschiedenen Komponenten der Architektur:<\/p>\n Die Komponenten in jeder der oben genannten Farben sind f\u00fcr verschiedene Arten von Sicherheitsbedrohungen anf\u00e4llig. Hier sind einige Sicherheitsvorkehrungen, die du treffen kannst, um dein Risiko zu minimieren:<\/p>\n Dies sind zwar nur eine Handvoll Vorschl\u00e4ge, aber sie machen deutlich, dass die Sicherheit von Apps kompliziert ist und es in deiner Verantwortung liegt, daf\u00fcr zu sorgen, dass du keine losen Enden hinterl\u00e4sst, die Angreifer f\u00fcr sich nutzen k\u00f6nnen. Du kannst dich nicht auf eine zentrale Sicherheitskomponente verlassen, um dein Unternehmen zu sch\u00fctzen; die App-Sicherheit ist \u00fcber deine gesamte App-Architektur verteilt.<\/p>\n Nutzerfeedback<\/a> ist ein wichtiges Instrument, um zu verstehen, wie gut deine App in Bezug auf die gesch\u00e4ftliche und technische Leistung abschneidet. Du kannst die leichteste und reibungsloseste App der Welt bauen, aber wenn sie deinen Nutzern nicht das bietet, was sie erwarten, sind alle deine Bem\u00fchungen umsonst.<\/p>\n Es gibt verschiedene M\u00f6glichkeiten, Nutzerfeedback zu sammeln. Die herk\u00f6mmliche Methode ist eine schnelle und anonymisierte Umfrage<\/a>. Du kannst aber auch eine ausgefeiltere L\u00f6sung w\u00e4hlen, wie z. B. eine Heatmap der Aktivit\u00e4ten deiner Nutzer\/innen.<\/p>\n![\"Das](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/10\/web-app-architecture-components.jpg\")
Warum ist die Architektur von Webanwendungen wichtig?<\/h2>\n
Leichte Anpassung an gesch\u00e4ftliche Erfordernisse<\/h3>\n
Organisierte Entwicklung<\/h3>\n
Besseres Codebase-Management<\/h3>\n
Verbesserte Sicherheit<\/h3>\n
Wie funktioniert die Webanwendungsarchitektur?<\/h2>\n
\n
\n
Arten der Webanwendungsarchitektur<\/h2>\n
Single-Page-Architektur<\/h3>\n
Vorteile der SPA-Architektur<\/h4>\n
\n
Nachteile der SPA-Architektur<\/h4>\n
\n
Progressive Webanwendungsarchitektur<\/h3>\n
Vorteile der PWA-Architektur<\/h4>\n
\n
Nachteile der PWA-Architektur<\/h4>\n
\n
Serverseitig gerenderte Architektur<\/h3>\n
Vorteile der SSR-Architektur<\/h4>\n
\n
Nachteile der SSR-Architektur<\/h4>\n
\n
Vorgerenderte Anwendungsarchitektur<\/h3>\n
https:\/\/myapp.com\/search\/foo+bar<\/code>), bist du hier an der\u00a0 falschen Adresse.<\/p>\nVorteile einer vorgerenderten Architektur<\/h4>\n
\n
Nachteile der vorgerenderten Architektur<\/h4>\n
\n
Isomorphe Anwendungsarchitektur<\/h3>\n
Vorteile der isomorphen Architektur<\/h4>\n
\n
Nachteile der isomorphen Architektur<\/h4>\n
\n
Serviceorientierte Architektur<\/h3>\n
Vorteile der serviceorientierten Architektur<\/h4>\n
\n
Nachteile der serviceorientierten Architektur<\/h4>\n
\n
Microservices-Architektur<\/h3>\n
Vorteile der Microservices-Architektur<\/h4>\n
\n
Nachteile der Microservices-Architektur<\/h4>\n
\n
Serverlose Architektur<\/h3>\n
Vorteile der serverlosen Architektur<\/h4>\n
\n
Nachteile der serverlosen Architektur<\/h4>\n
\n
Schichten der Webanwendungsarchitektur<\/h2>\n
Pr\u00e4sentationsschicht<\/h3>\n
Business-Schicht<\/h3>\n
Persistenzschicht<\/h3>\n
Komponenten der Webanwendung<\/h2>\n
Serverseitige Komponenten<\/h3>\n
DNS & Routing<\/h4>\n
Datenspeicherung<\/h4>\n
\n
Caching<\/h4>\n
\n
Jobs und Dienste<\/h4>\n
Clientseitige Komponenten<\/h3>\n
Frontend-Benutzeroberfl\u00e4che<\/h4>\n
Clientseitige Gesch\u00e4ftslogik<\/h4>\n
Modelle von Webanwendungskomponenten<\/h3>\n
Ein Server, eine Datenbank<\/h4>\n
Mehrere Server, eine Datenbank<\/h4>\n
Mehrere Server, mehrere Datenbanken<\/h4>\n
Anwendungsdienste<\/h4>\n
Best Practices f\u00fcr die Architektur von Webanwendungen<\/h2>\n
1. Mach dein Frontend reaktionsf\u00e4hig<\/h3>\n
2. Ladezeiten \u00fcberwachen<\/h3>\n
3. Bevorzuge PWAs, wo immer m\u00f6glich<\/h3>\n
4. Halte deine Codebasis sauber und pr\u00e4gnant<\/h3>\n
\n
5. Automatisiere deine CI\/CD-Prozesse<\/h3>\n
6. Sicherheitsfunktionen einbinden<\/h3>\n
![\"Das](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/example-serverless-architecture.png\")
\n
\n
\n
\n
\n
\n
7. Sammle Nutzerfeedback<\/h3>\n