Frontend anhand eines Ultra-Large-Scale Systems wie Uber

Diese Arbeit wurde im Rahmen der Vorlesungsveranstaltung „Ultra Large Scale Systems“ erstellt.

Abstract

Ultra-Large-Scale Systems (ULSS) wie Uber stellen aufgrund ihrer hohen Nutzerzahlen, globalen Verteilung, großen Datenmengen und kontinuierlichen Weiterentwicklung besondere Anforderungen an die Frontend-Architektur. Diese Arbeit untersucht zentrale Architekturentscheidungen für das Frontend einer Uber-ähnlichen Anwendung. Dabei werden Component-based Architecture, Single-Page Applications, Rendering-Strategien, State Management, Backend-Integration sowie Monolith- und Micro-Frontend-Ansätze betrachtet.

Auf Basis dieser Analyse werden separate monolithische Frontends als geeigneter Ansatz für das betrachtete Szenario ausgewählt. Ergänzend wird ein hybrider Rendering-Ansatz mit einer Kombination aus Client-Side Rendering, Server-Side Rendering, Static Site Generation und Edge Rendering sowie eine Trennung von Client State und Server State empfohlen. Durch eine API-Gateway- und Backend-for-Frontend-Schicht werden die Frontends von der Backend-Komplexität entkoppelt, während WebSockets die erforderliche Echtzeitkommunikation ermöglichen. Zusätzlich unterstützt ein zentrales Designsystem die Konsistenz sowie Wiederverwendbarkeit von UI-Komponenten und ermöglicht somit eine einheitliche User Experience (UX). Die Untersuchung zeigt, dass eine geeignete Frontend‑Architektur für ein ULSS durch eine gezielte Abstimmung zentraler Architekturentscheidungen auf beherrschbare Komplexität, einheitliches State‑Management und konsistente UX‑Flows entsteht.

1. Einleitung

In der heutigen Zeit werden Anwendungen wie soziale Medien, Streaming-Plattformen oder Online-Marktplätze von Millionen von Menschen genutzt [1]. Bei diesen Anwendungen handelt es sich häufig um Ultra-Large-Scale Systems (ULSS), also softwareintensive Systeme, die sich durch enorme Größenordnungen hinsichtlich Hardware, Umfang des Quellcodes, Anzahl der Nutzer sowie des verarbeiteten Datenvolumens auszeichnen [2]. Weitere Eigenschaften von ULSSs umfassen eine dezentrale Datenhaltung sowie dezentrale Entwicklungs-, Weiterentwicklungs- und Betriebskontrollprozesse [2]. Zudem enthalten sie heterogene, inkonsistente und sich kontinuierlich verändernde Elemente und entwickeln sich während des Betriebs stetig weiter [2].

Ein Beispiel für ein System dieser Größenordnung ist Uber[3], eine weit verbreitete Ride-Hailing-Plattform, die Fahrgäste mit Fahrern verbindet [4]. Die Plattform ermöglicht es Fahrgästen, Fahrten zu buchen, während Fahrer Fahrten annehmen und verwalten können [3]. Neben diesen funktionalen Anforderungen muss Uber zahlreiche nicht-funktionale Anforderungen erfüllen. Dazu gehören unter anderem geringe Latenz und hohe Performance, hohe Verfügbarkeit, Skalierbarkeit, globale Verteilung, Echtzeitfähigkeit sowie eine responsive User Interface (UI) und Unterstützung verschiedener Plattformen [4].

Damit Nutzer Uber effizient und komfortabel verwenden können, muss insbesondere das Frontend eine benutzerfreundliche und reaktionsschnelle Nutzererfahrung gewährleisten [4]. Die Bedeutung des Frontends in ULSSs ist besonders hoch, da es den direkten Interaktionspunkt zwischen dem Unternehmen und den Nutzern darstellt [5]. Es beeinflusst unter anderem maßgeblich die User Experience (UX), Suchmaschinenoptimierung (SEO), Performance sowie die Markenwahrnehmung [5].

Daraus ergibt sich die Forschungsfrage, wie ein Frontend für ein ULSS wie Uber architektonisch gestaltet werden sollte.

Da der Fokus dieser Arbeit auf der Frontend-Architektur liegt, wird primär ein Web-Frontend betrachtet. Mobile Anwendungen sowie infrastrukturelle und fachliche Aspekte wie Cloud-Infrastruktur, Security, Payment, Matching oder Pricing werden nicht behandelt. Diese Eingrenzung ermöglicht eine gezielte Untersuchung zentraler Frontend-Architekturthemen wie Rendering, State Management und Frontend-Architekturmodelle.

Basis der Arbeit bilden die im Vorlesungsmodell “Ultra-Large-Scale System” erarbeitete Architecture Inception Canvas [6] sowie die dort erarbeiteten funktionalen und nicht funktionalen Anforderungen für ein ULSS im Uber-Kontext [7].

Zur Beantwortung der vorher genannten Forschungsfrage werden zunächst in Abschnitt 2 grundlegende Konzepte moderner Frontend-Architekturen, wie die Component-Based Architecture (CBA) und Single-Page Applications (SPA), sowie verschiedene Ansätze für Rendering und State Management betrachtet und miteinander verglichen. Darüber hinaus werden in Abschnitt 3 Technologien für einen möglichen Frontend-Stack vorgestellt. Anschließend werden verschiedene Ansätze zur Backend-Integration in Abschnitt 4 sowie verschiedene Frontend-Architekturmodelle in Abschnitt 5 analysiert und verglichen. Darauf aufbauend wird in Abschnitt 6 ein geeignetes Frontend-Architekturmodell für ein ULSS im Kontext von Uber ausgewählt und in Abschnitt 7 konzeptionell dargestellt. In Abschnitt 8 wird das Designsystem von Uber vorgestellt und als geeigneter Ansatz für die Gestaltung des Frontends des betrachteten ULSSs eingeordnet. Anschließend erfolgt in Abschnitt 9 die Diskussion der Ergebnisse und relevanten Themen. Den Abschluss bilden das Fazit in Abschnitt 10 sowie der Ausblick auf zukünftige Entwicklungen in Abschnitt 11.

2. Grundlagen der Frontend Architektur

Um die Grundlage für die späteren Architekturentscheidungen zu schaffen, werden in diesem Abschnitt die grundlegenden Konzepte moderner Frontend-Architekturen erläutert.

2.1. Architekturkonzepte für moderne Frontend-Anwendungen

Moderne Frontend-Anwendungen basieren auf verschiedenen Architekturkonzepten, welche die Struktur eines Systems maßgeblich beeinflussen. Im Folgenden werden die Architekturkonzepte Component-based Architecture (CBA) und Single-Page Application (SPA) erläutert, da sie die Grundlage vieler moderner Webanwendungen und damit auch des betrachteten ULSSs darstellen.

2.1.1. Component-based Architecture

In der Component-based Architecture (CBA) besteht die Software aus wiederverwendbaren, klar abgegrenzten Komponenten. Dabei kapseln die Komponenten bestimmte Funktionalitäten, Daten und Verhalten sowie klar definierte Schnittstellen. Dank dieser Konstellation wird die Wiederverwendbarkeit von Komponenten gefördert und die allgemeine Wartbarkeit, Skalierbarkeit sowie Flexibilität des Systems verbessert. Zudem wird dadurch auch die parallele Entwicklung im Team erleichtert [8].

Allerdings ist zu beachten, dass mit steigender Anzahl an Komponenten die Komplexität der Verwaltung ihrer gegenseitigen Abhängigkeiten erheblich zunimmt. Zudem muss die passende Granularität der Komponenten bestimmt werden: Während eine zu feine Granularität durch zusätzliche Kommunikation und Verwaltungsaufwand zu Performance Overhead führen kann, reduziert eine zu grobe Granularität die Wiederverwendbarkeit und Flexibilität der Komponenten [8].

2.1.2. Single Page Application

Bei der Single Page Application (SPA) wird in einer Webanwendung zunächst nur ein einzelnes Web-Dokument geladen [9]. Anschließend werden die benötigten Inhalte auf Basis von Nutzerinteraktionen dynamisch nachgeladen und aktualisiert, sodass auf ein vollständiges Neuladen der Seite verzichtet werden kann [10].

Auf diese Weise wird eine schnellere Interaktion nach dem initialen Laden der Seite ermöglicht und die Performance durch den Verzicht auf vollständige Seiten-Neuladungen verbessert. Zudem können gezielte Datenabfragen die Übertragung unnötiger Daten reduzieren und dadurch die Effizienz der Anwendung erhöhen. Dafür verlangsamt der initiale Ladeprozess zunächst den ersten Seitenaufbau. Auch kann der hohe Anteil an JavaScript bei dynamischen Inhalten möglicherweise zu Schwierigkeiten bei der SEO führen [10].

Zusammenfassend lässt sich feststellen, dass SPAs geeignet für interaktive Webanwendungen sind, die unter anderem Echtzeit- oder dynamische Daten beinhalten [10].

2.2 Rendering

Das Rendering beschreibt den Prozess der Erzeugung und Darstellung der einer Webanwendung im Browser [11]. Die Wahl der Rendering-Strategie beeinflusst dabei wesentliche Eigenschaften des Frontends, insbesondere die initiale Ladezeit, Performance, Interaktivität sowie SEO [12]. Abhängig von den Anforderungen einer Anwendung können unterschiedliche Rendering-Methoden eingesetzt oder kombiniert werden. Folglich werden im Folgenden übliche Rendering-Methoden vorgestellt.

2.2.1. Server-Side Rendering

Ein klassischer Ansatz bildet das Server-Side Rendering (SSR), bei dem das HTML-Dokument bei jeder Anfrage serverseitig erzeugt wird. Beim Aufruf einer Webseite wird eine Anfrage an den Server gesendet. Der Server verarbeitet diese Anfrage, lädt die benötigten Daten und rendert daraus das HTML-Dokument. Anschließend wird die generierte Seite an den Browser übertragen [12].

SSR eignet sich besonders gut für Webseiten, bei denen eine schnelle initiale Auslieferung und eine gute SEO wichtig sind. Bei stark dynamischen Webanwendungen kann SSR jedoch aufgrund häufiger Serververarbeitung und erneuter Seitengenerierung an Grenzen stoßen [12].

2.2.2. Client-Side Rendering

Durch die steigenden Anforderungen an die Interaktivität moderner Webanwendungen entstand das Client-Side Rendering (CSR). Dabei übernimmt der Browser die Verarbeitung und Darstellung der Inhalte. CSR bildet die Grundlage vieler moderner SPAs, beispielsweise Anwendungen auf Basis von React oder Vue.

Ähnlich wie bei SPAs lädt der Browser zunächst ein grundlegendes HTML-Dokument, anschließend die benötigten JavaScript-Dateien und führt diese aus. Dadurch wird die UI clientseitig aufgebaut, sodass Inhalte dynamisch geladen und dargestellt werden können.

Dank CSR können UI-Aktualisierungen ohne vollständiges Neuladen der Seite erfolgen. Allerdings ergeben sich ähnliche Herausforderungen wie bei klassischen SPAs, insbesondere hinsichtlich der lange Initialladezeiten und der SEO, da dynamisch erzeugte Inhalte für Suchmaschinen schwieriger zu indexieren sein können [12].

2.2.3. Static Site Generation

Zur Förderung schnellerer Ladezeiten werden bei der Static Site Generation (SSG) Webseiten bereits während des Build-Prozesses erzeugt und nicht erst bei einer Anfrage serverseitig generiert. Die erzeugten statischen Dateien können anschließend in einem Content Delivery Network (CDN) gespeichert werden. Ein CDN beschreibt ein Netzwerk aus geografisch verteilten Servern zur effizienten und schnellen Auslieferung von Webinhalten [13].

Nutzer erhalten dadurch die fertigen Seiten direkt von einem geografisch nahegelegenen CDN-Server. Allerdings besteht der Nachteil von SSG darin, dass Inhalte statisch sind und sich erst durch einen erneuten Build-Prozess aktualisieren. Daher ist dieser Ansatz weniger geeignet für Anwendungen mit häufig wechselnden oder Echtzeitdaten [12].

2.2.4. Incremental Static Regeneration

Eine Kombination aus SSG und dynamischen Aktualisierungen bildet die Incremental Static Regeneration (ISR). Dabei werden Seiten zunächst statisch während des Build-Prozesses erzeugt und anschließend automatisch in definierten Intervallen aktualisiert. Hierfür wird eine Revalidierungszeit festgelegt, nach deren Ablauf die Seite bei einer Nutzeranfrage im Hintergrund neu generiert wird. Während dieses Prozesses wird weiterhin die bestehende Version aus dem Cache ausgeliefert (Cached Page Delivery), wodurch eine hohe Verfügbarkeit gewährleistet wird. Dadurch können Inhalte jedoch für einen begrenzten Zeitraum veraltet sein. Zudem führt ISR insbesondere bei ULSSs zu einer höheren technischen Komplexität [12].

2.2.5. Edge Rendering

Für das Rendering von Webanwendungen auf globaler Ebene spielt das Edge Rendering eine wichtige Rolle. Dabei erfolgt das Rendering nicht zentral auf einem einzelnen Server, sondern auf Edge-Servern (auch Edge-Nodes genannt), die Teil eines verteilten Edge-Netzwerks sind und sich geografisch näher am Nutzer befinden. Dadurch kann eine Nutzeranfrage an einem geeigneten, möglichst nahegelegenen Edge-Server verarbeitet werden. Dort wird die Rendering-Logik ausgeführt und das erzeugte HTML-Dokument direkt an den Nutzer zurückgegeben [14].

Im Unterschied zu einem CDN werden beim Edge Rendering nicht ausschließlich bereits erzeugte statische Inhalte verteilt. Während ein CDN hauptsächlich zur Zwischenspeicherung und Auslieferung vorhandener Inhalte dient, können beim Edge Rendering Inhalte dynamisch zur Laufzeit an der Edge erzeugt und anschließend ausgeliefert werden [13].

2.2.6. Hybrid Rendering

Um die Kombination verschiedener Rendering-Methoden innerhalb derselben Anwendung zu ermöglichen, existiert das Hybrid Rendering[15]. Dabei können unterschiedliche Seiten oder Routen innerhalb derselben Anwendung mit unterschiedlichen Rendering-Strategien umgesetzt werden. Ein möglicher Ansatz besteht darin, die initiale Seite serverseitig zu rendern (siehe SSR in Abschnitt 2.2.1) und als fertiges HTML-Dokument auszuliefern, um eine schnelle initiale Darstellung sowie eine verbesserte SEO-Eignung zu erreichen. Anschließend übernimmt der Browser die Ausführung von JavaScript und führt die sogenannte Hydration durch, wodurch die statisch ausgelieferte Seite interaktiv wird [15][16].

Die Hydration beschreibt den Prozess, bei dem ein bereits serverseitig erzeugtes HTML-Dokument im Browser durch JavaScript mit interaktiver Logik und Event-Handlern erweitert wird [16].

Anschließend können CSR-Mechanismen oder SPA-Ansätze für dynamische und flüssige Interaktionen genutzt werden, ohne dass ein vollständiges Neuladen der Seite erforderlich ist [15].

2.2.7. Auswahl eines Rendering-Ansatzes für das Web-Frontend im Uber-Kontext

Auf Basis der zuvor erläuterten Rendering-Methoden werden geeignete Ansätze für ein Web-Frontend im Uber-Kontext ausgewählt. Da keine einzelne Rendering-Methode alle Anforderungen des Systems vollständig erfüllt, wird ein Ansatz des Hybrid Renderings verfolgt. Dabei basiert die Hauptanwendung auf einer SPA-Architektur in Kombination mit CSR, während statische und einstiegsorientierte Seiten durch SSR und SSG ergänzt werden. Die Auswahl und Zuordnung der Rendering-Methoden für die einzelnen Anwendungsbereiche sind in Tabelle 1 dargestellt. Dabei wird ISR ausgeschlossen, da das Verfahren aufgrund der Revalidierungszeiten keine mit CSR vergleichbare Echtzeitfähigkeit ermöglicht und zudem in ULSSs zu einer erhöhten technischen Komplexität führt (siehe Abschnitt 2.2.4).

2.3. State Management

Ein State bezeichnet im Frontend den aktuellen Zustand einer Anwendung und umfasst alle Daten, die sich während der Programmausführung ändern können, beispielsweise Benutzereingaben, UI-Zustände oder Anwendungsdaten. Mit zunehmender Größe und Komplexität einer Anwendung wird die Verwaltung dieser Zustände jedoch anspruchsvoller [17].

Aus diesem Grund kommen Verfahren des State Managements zum Einsatz, die eine strukturierte Verwaltung und Aktualisierung von States ermöglichen. State Management legt fest, wo sich ein State befindet, wie er verändert wird und wie Änderungen innerhalb der Anwendung propagiert werden. Dadurch kann der Datenfluss vorhersehbarer gestaltet sowie die Nachvollziehbarkeit, Wartbarkeit und Skalierbarkeit einer Anwendung verbessert werden. Gleichzeitig wird das Risiko inkonsistenter Zustände und daraus resultierender Fehler reduziert [17].

Grundsätzlich lassen sich verschiedene Arten von States unterscheiden [18][17]:

• Local State: Zustände, die ausschließlich innerhalb einer einzelnen Komponente oder Funktion verwaltet werden und nicht global verfügbar sind. Beispiele sind Eingaben in Suchfeldern, der Zoom einer Karte oder die Auswahl von UI-Elementen.
• Global State: Zustände, die von mehreren Komponenten gemeinsam genutzt werden und daher anwendungsweit verfügbar sind. Beispiele hierfür sind der Login-Status eines Benutzers, der Fahrerstatus oder die ausgewählte Sprache.
• Derived State: Zustände, die aus anderen vorhandenen Daten berechnet werden und daher nicht explizit gespeichert werden müssen. Beispiele sind ETA, Entfernungen oder berechnete Preise.
• Server State: Daten, deren Quelle sich auf einem Server befindet und die zwischen Client und Backend synchronisiert werden müssen. Beispiele sind Benutzerkonten, Fahrhistorien oder Zahlungsinformationen.

Zur Verwaltung dieser verschiedenen Arten von States stehen unterschiedliche State-Management-Bibliotheken und -Lösungen zur Verfügung. Im Folgenden werden drei verbreitete Ansätze in Tabelle 2 verglichen.

2.3.1. Auswahl eines State-Management-Konzepts für das Web-Frontend im Uber-Kontext

Aufgrund der hohen Systemkomplexität von Uber ist eine Trennung verschiedener State-Arten notwendig. Unterschiedliche Anforderungen an API-Daten, UI-State und Realtime-Daten machen eine getrennte Verwaltung sinnvoll. Dadurch werden widersprüchliche Zustände vermieden und die Skalierung vereinfacht.

Local UI State: React intern

Lokale Komponenten-Zustände wie Inputs, UI-Toggles und lokale Interaktionen werden mit React-internem State umgesetzt. Diese Zustände sind nur lokal relevant und benötigen keine globale Synchronisation.

Global Client State: Redux Toolkit

Der globale App-State, beispielsweise Login-Status, UI-Zustände und die aktuelle Fahrt, wird mit Redux Toolkit verwaltet. Gründe hierfür sind komplexe Zustände, viele Screens, hohe Konsistenzanforderungen und die Skalierbarkeit für große Teams.

Derived State: Berechnung aus vorhandenem State

Abgeleitete Zustände wie die geschätzte Ankunftszeit (ETA), Entfernungen oder berechnete Preise werden nicht separat gespeichert. Stattdessen werden sie bei Bedarf aus Local, Global oder Server State berechnet, wodurch redundante Datenhaltung und inkonsistente Zustände vermieden werden.

Server State: TanStack Query

Für API-Daten wie Nutzer, Fahrten, Fahrer und Preise wird TanStack Query verwendet. Die Entscheidung basiert auf der großen Menge serverseitiger Daten sowie der Notwendigkeit von häufigen Updates, Caching und Synchronisation.

3. Frontend-Technologie-Stack im Uber-Kontext

In diesem Abschnitt wird ein möglicher Frontend-Technologie-Stack für ein ULSS im Uber-Kontext vorgestellt. Neben den im Abschnitt 2.3.1 ausgewählten Technologien Redux und TanStack Query für das State Management umfasst der Frontend-Technologie-Stack auch die Technologien React, Fusion.js und Node.js, wobei jede Technologie eine spezifische Rolle innerhalb der Anwendungsarchitektur übernimmt.

3.1. React

React ist eine JavaScript-Bibliothek zur Erstellung von UIs. Durch die komponentenbasierte Entwicklung ermöglicht React die Erstellung wiederverwendbarer UI-Module und rendert die deklarativ auf Basis von Datenzuständen [24].

3.2. Fusion.js

Fusion.js ist ein von Uber entwickeltes Web-Framework für React-Anwendungen. Es verbindet Server- und Client-Code innerhalb einer gemeinsamen Architektur und übernimmt die Orchestrierung der gesamten Web-Anwendung [25][26]. Fusion.js definiert Architekturregeln, integriert Backend-for-Frontend-(BFF)-Logik und unterstützt Funktionen wie SSR, Routing, Hot Module Reloading und Code-Splitting. Dadurch wird eine skalierbare Struktur für große Entwicklungsteams ermöglicht [26].

3.3. Node.js

Node.js dient als serverseitige JavaScript-Laufzeitumgebung und bildet die technische Ausführungsumgebung der Anwendung. Zusätzlich übernimmt Node.js die Aggregation und Aufbereitung von API-Daten für die Anforderungen der UI im Backend-for-Frontend [27].

3.4. Zusammenspiel der Technologien im Frontend-Stack

Zusammen bilden React, Fusion.js und Node.js eine Architektur mit klarer Trennung der Verantwortlichkeiten:

• React: Ist für die Darstellung der UI, Verarbeitung lokaler UI-Zustände sowie Reaktion auf Benutzerinteraktionen zuständig
• Fusion.js: Organisiert die Anwendungsarchitektur und
• Serverlogik
• Node.js: Führt die Fusion.js-Anwendung aus und ermöglicht SSR sowie Backend-for-Frontend-Funktionalitäten

Die Architektur basiert auf komponentenbasierter Entwicklung sowie einer Trennung von UI-, Daten- und Business-Logik. Das Zusammenspiel der State Management Technologien ist im Abschnitt 2.5 ersichtlich.

4. Backend Integration

Um die Gestaltung des Frontends anhand eines ULSSs wie Uber ganzheitlich zu betrachten, muss auch dessen Integration in die Backend-Architektur, die einer Microservice-Architektur entspricht, berücksichtigt werden. Daher werden im Folgenden die wesentlichen Aspekte einer effizienten Kommunikation zwischen Frontend und Backend betrachtet.

4.1. API Gateway

Ein API Gateway dient als zentraler Einstiegspunkt für Clients innerhalb einer Microservice-Architektur und fungiert als Vermittlungsschicht zwischen Client-Anfragen und den dahinterliegenden Backend-Services. Durch den Einsatz eines API Gateways wird die interne Komplexität der Services vor dem Client verborgen, der Zugriff auf Backend-Funktionalitäten vereinheitlicht und die Verwaltung von Skalierung, Sicherheit und Kommunikation zwischen den Systemkomponenten unterstützt [28][29].

Zu den zentralen Aufgaben eines API Gateways gehören unter anderem das Routing eingehender Anfragen an geeignete Microservices, die Aggregation von Antworten mehrerer Services sowie die Umsetzung von Sicherheits- und Zugriffskontrollen wie Authentifizierung, Autorisierung und Rate Limiting [28][29].

Allerdings weisen Web- und Mobile-Clients häufig unterschiedliche Anforderungen hinsichtlich Datenformaten, Antwortzeiten und Performance auf. Ein General-Purpose-API-Gateway kann diese unterschiedlichen Anforderungen nicht immer optimal erfüllen, da eine einheitliche Schnittstelle zu unnötig umfangreichen Antworten oder ineffizienten Anfragen führen kann. Dies kann insbesondere in ULSSs zu potenziellen Performance-Bottlenecks führen [28][29].

4.2. Backend-for-Frontend

Zur Lösung des im vorherigen Abschnitt beschriebenen Problems wird häufig das Backend-for-Frontend (BFF) eingesetzt [30]. Dabei handelt es sich um eine spezialisierte Backend-Schicht, die einem Frontend-Team zugeordnet ist und gezielt auf die Anforderungen einer bestimmten Frontend-Anwendung oder UX ausgerichtet wird [31]. Anstelle eines einzelnen API Gateways können beispielsweise separate BFFs für Web- und Mobile-Clients eingesetzt werden (siehe Abbildung 1)[30]. Die Aufgaben eines BFF umfassen die Integration verschiedener Microservices, die Aggregation und Aufbereitung von Daten für die UI sowie die Anpassung von Datenformaten und Fehlerbehandlung [31]. Dabei ist der Einsatz von BFFs besonders geeignet, wenn eine UI-spezifische Datenaufbereitung und -aggregation erforderlich ist, optimierte und an den jeweiligen Client angepasste APIs bereitgestellt werden sollen oder das Frontend von bestimmten Backend-Komplexitäten entkoppelt werden soll [31][30].

4.3. API Kommunikation

Hinsichtlich der API-Kommunikation werden im Folgenden zwei Ansätze betrachtet:

REST ist ein Architekturstil für Web-APIs und basiert auf einem ressourcenorientierten Modell. Der Zugriff auf Ressourcen erfolgt über URLs und standardisierte HTTP-Methoden wie GET, POST, PUT und DELETE [32].

GraphQL ist eine Abfragesprache für APIs, die typischerweise über einen einzelnen Endpunkt bereitgestellt wird. Dabei definiert der Client die benötigten Datenstrukturen, woraufhin der Server ausschließlich die angeforderten Daten zurückliefert [32].

Während REST besonders für stabile APIs mit standardisierten Strukturen und umfangreichen Caching-Möglichkeiten geeignet ist, bietet GraphQL Vorteile bei datenintensiven Anwendungen mit unterschiedlichen Clients, komplexen Datenanforderungen und dem Bedarf an optimierter Datenübertragung [32].

4.4. Echtzeitkommunikation

Da in ein ULSS im Uber-Kontext die Echtzeitübertragung von Daten eine zentrale Rolle spielt, werden im Folgenden Long Polling und WebSockets als mögliche Ansätze zur Echtzeitkommunikation betrachtet.

Long Polling ist eine HTTP-basierte Technik zur Annäherung an Echtzeitkommunikation zwischen Client und Server. Dabei sendet der Client eine HTTP-Anfrage an den Server, der die Verbindung offen hält, bis neue Daten verfügbar sind oder ein Timeout erreicht wird. Anschließend wird die Verbindung beendet und der Client startet eine neue Anfrage. Der Vorteil von Long Polling liegt in der einfachen Implementierung über bestehende HTTP-Infrastrukturen sowie der hohen Kompatibilität mit älteren Systemen. Allerdings entstehen durch wiederholte Verbindungsaufbauten zusätzliche Overheads, wodurch sich die Technik weniger für hochfrequente Echtzeitaktualisierungen eignet [33].

WebSockets ermöglichen eine dauerhafte, bidirektionale Kommunikation zwischen Client und Server über eine TCP-Verbindung. Nach dem initialen Verbindungsaufbau bleibt die Verbindung geöffnet, sodass Daten ohne wiederholte HTTP-Anfragen übertragen werden können. Dadurch ermöglichen WebSockets geringe Latenzen und eine effiziente Datenübertragung. Gleichzeitig steigt die technische Komplexität insbesondere hinsichtlich Skalierung, Verbindungsverwaltung und Wiederverbindung. WebSockets eignen sich daher besonders für Echtzeitanwendungen wie Live-Updates oder Location-Tracking [33].

4.5. Auswahl der Backend-Integration im Uber-Kontext

Insgesamt sollte die Kommunikation zwischen Client und Backend, welches eine Microservice-Architektur verwendet, wie folgt aufgebaut sein:

Client -> API Gateway -> BFF -> Microservices

Die API-Schicht besteht aus einem API Gateway als zentralem Einstiegspunkt, das zentrale Funktionen wie Routing, Zugriffskontrolle und Sicherheitsmechanismen übernimmt. Darauf aufbauend werden zwei BFFs für Web- und Mobile-Clients eingesetzt, um UI-spezifische Datenaggregation, Optimierung und client-spezifische Anpassungen der APIs zu ermöglichen. Da die BFFs bereits optimierte Schnittstellen für die jeweiligen Clients bereitstellen, ist REST für die Kommunikation mit klassischen CRUD-basierten Services (z. B. Nutzerverwaltung, Payments oder Fahrtenhistorie) ausreichend. GraphQL kann optional für komplexe Datenanforderungen, beispielsweise bei Karten- oder Standortdaten, eingesetzt werden. Für Echtzeitkommunikation werden hingegen WebSockets verwendet, da diese sich aufgrund der bidirektionalen Kommunikation besonders für Anwendungen wie Live-Updates und Location-Tracking eignen (siehe Abschnitt 4.4). Eine architektonische Skizze der Backend-Integration ist in Abbildung 5 enthalten.

5. Frontend-Architekturmodelle

Die Wahl des Frontend-Architekturmodells bestimmt, wie eine Anwendung in funktionale Einheiten gegliedert und entwickelt wird. Im Folgenden werden mit dem monolithischen Frontend und Micro-Frontend zwei verbreitete Ansätze betrachtet.

5.1. Monolithisches Frontend

Monolithisches Frontend bezeichnet eine zentralisierte Frontend-Architektur, bei der alle Bestandteile des Frontends (UI, Komponenten, Styles und Anwendungslogik) in einer einzigen Anwendung gebündelt werden (siehe Abbildung 2). Dadurch sind die einzelnen Teile eng miteinander integriert. Die Entwicklung, das Testing und das Deployment erfolgen typischerweise durch ein gemeinsames Team oder mehrere Teams innerhalb desselben Repositories [34][35][36].

Vorteile eines monolithischen Frontends liegen in der einfachen Entwicklung und Einrichtung, insbesondere für kleinere Teams. Zudem lassen sich States und die Kommunikation zwischen Komponenten einfacher umsetzen, wodurch der Kommunikationsaufwand reduziert werden kann. Eine zentrale Deployment-Pipeline verringert außerdem die Komplexität der Bereitstellung [37][36].

Nachteilig ist jedoch, dass mit zunehmender Größe der Anwendung und der Codebasis die Wartbarkeit und Skalierbarkeit erschwert werden können. Änderungen an einzelnen Komponenten können Auswirkungen auf die gesamte Anwendung haben. Zudem können bei mehreren gleichzeitig entwickelnden Teams vermehrt Abhängigkeiten und Koordinationsaufwände entstehen, wodurch die Feature-Entwicklung langfristig verlangsamt werden kann [37][36].

5.2. Micro-Frontend

Ein Micro-Frontend unterteilt das Frontend in mehrere unabhängige Module, sogenannte Micro-Frontends [39]. Jedes Modul bildet ein fachliches Feature einschließlich UI, Anwendungslogik und State ab. Dadurch können Entwicklung, Testing, Deployment und Skalierung unabhängig voneinander erfolgen [35]. Mögliche Architekturvarianten von Micro-Frontends sind in Abbildung 3 dargestellt.

Der Einsatz von Micro-Frontends verbessert die Modularität und Wartbarkeit der Codebasis und ermöglicht unabhängige Entwicklungen sowie schnellere Releases durch parallele Teamarbeit. Zudem können Technologien je Modul unabhängig gewählt und einzelne Bereiche unabhängig skaliert werden. Darüber hinaus ist eine schrittweise Migration von einem monolithischen Frontend möglich [40][36].

Demgegenüber stehen eine höhere architektonische Komplexität, insbesondere hinsichtlich Routing, Kommunikation und gemeinsamem Zustand, sowie potenzielle Performance-Overheads durch zusätzliche Schnittstellen. Zudem erhöhen sich der Koordinationsaufwand zwischen den Teams und die Einstiegshürde hinsichtlich Architektur und Tooling [37][36].

5.3. Vergleich der Modelle

Monolithische Frontends eignen sich insbesondere für kleine bis mittelgroße Anwendungen mit wenigen Entwicklungsteams und eng gekoppelten Funktionalitäten. Sie ermöglichen eine einfache Entwicklung, zentrale Verwaltung und schnelle Umsetzung, stoßen jedoch mit zunehmender Größe der Anwendung hinsichtlich Wartbarkeit und Skalierbarkeit an ihre Grenzen [35][36][38][39].

Micro-Frontends hingegen sind für große und komplexe Anwendungen mit mehreren autonomen Teams konzipiert. Durch die Aufteilung in unabhängige Module werden Entwicklung, Deployment und Skalierung entkoppelt. Dies erhöht die Flexibilität und Wartbarkeit, führt jedoch zu einer höheren architektonischen Komplexität. Daher lohnt sich der Einsatz von Micro-Frontends vor allem, wenn die Vorteile der Modularisierung den zusätzlichen Aufwand rechtfertigen [35][36][38][39].

6. Frontend-Architekturentscheidung im Uber-Kontext

In diesem Abschnitt wird die Ausgangssituation des Frontends eines ULSSs beschrieben. Darauf aufbauend wird eine geeignete Frontend-Architektur ausgewählt.

6.1. Ausgangssituation

Es wird von drei Client-Anwendungen ausgegangen:

• Rider App: Mobile Anwendung für Fahrgäste zur Buchung von Fahrten
• Driver App: Mobile Anwendung für Fahrer zur Annahme, Durchführung und Verwaltung von Fahrten
• Rider Web: Webanwendung für Fahrgäste zur Buchung von Fahrten

Alle drei Anwendungen weisen gemeinsame Anforderungen auf. Für eine Plattform wie Uber sind eine hohe Performance sowie eine Echtzeitfähigkeit essenziell, da Funktionen wie Live-Tracking oder ETA-Updates kontinuierlich und zuverlässig aktualisiert werden müssen. Zudem sind zentrale Funktionen wie Kartenansicht, Preisberechnung und Standortverfolgung eng miteinander verknüpft und bilden einen durchgängigen Nutzungskontext. Daraus ergibt sich ein stark gekoppeltes Frontend-System.

6.2. Beurteilung der Modelle

Auf Basis der in Abschnitt 6.1 beschriebenen Anforderungen werden die Kriterien in der folgenden Tabelle 3 dargestellt und die Architekturen Monolithisches Frontend und Micro-Frontend verglichen.

Anhand dieser Tabelle wird deutlich, dass bei Priorisierung von Echtzeit-UX, durchgängigen UX-Flows und konsistentem State Management ein monolithisches Frontend besser geeignet ist. Daher soll pro Client-Anwendung ein monolithisches Frontend mit intern angewandter Component-Based Architecture eingesetzt werden. Während Aspekte wie Microservices, verteilte Teams und Autonomie primär das Backend und interne Tools betreffen, bleibt der Fokus im Frontend auf einer konsistenten Nutzererfahrung. Da Micro-Frontends hauptsächlich Organisations- und Skalierungsprobleme adressieren, jedoch zusätzliche technische Komplexität im Frontend verursachen können, sind sie für die im Architecture Inception Canvas beschriebene Aufbauphase der Organisation tendenziell noch nicht geeignet.

7. Frontend Aufbau im Uber-Kontext

Auf Basis der in Abschnitt 6 getroffenen Entscheidung für das Frontendarchitekturmodell wird in Abbildung 4 ein möglicher Aufbau der Frontendarchitektur skizziert.

Jede Client-Anwendung verfügt über ein eigenes monolithisches Frontend, das spezifische fachliche Module enthält. Die Rider App und das Rider Web bilden teilweise dieselben fachlichen Domänen wie Booking, Trips, Account und Map ab, da beide Anwendungen denselben Nutzer und ähnliche Geschäftsprozesse unterstützen. Die Module werden jedoch entsprechend der jeweiligen Plattformanforderungen separat implementiert und entsprechend ihrer jeweiligen Nutzergruppen und Geschäftsprozesse strukturiert.

Während die Rider App insbesondere auf Echtzeitinteraktionen wie Live-Tracking, Standortverarbeitung und Benachrichtigungen optimiert ist, liegt der Fokus des Rider Web stärker auf Verwaltung und Planung.

Die Driver App adressiert hingegen spezifische Fahrerprozesse und enthält eigene fachliche Module wie Incoming Ride Requests, Active Trip, Earnings und Availability Management. Im Gegensatz zu den Rider-Anwendungen liegt der Schwerpunkt hier auf der Echtzeitverarbeitung von Fahrtanfragen, der Durchführung aktiver Fahrten sowie der Verwaltung von Fahrerstatus und Einnahmen.

Die adressierten zentralen Module und deren Funktionalitäten sind in Tabelle 4 zusammengefasst.

Übergreifende technische Komponenten wie Design-System, Authentifizierung, API-Client, Fehlerbehandlung und Logging können über wiederverwendbare Bibliotheken bereitgestellt werden. Dadurch bleiben die einzelnen Frontends unabhängig voneinander entwickelbar und betreibbar, während gleichzeitig technische Konsistenz und Wiederverwendbarkeit gewährleistet werden.

7.1. Einordnung in die Gesamtarchitektur

In Abbildung 5 wird eine mögliche Einordnung des Frontends in die Gesamtarchitektur dargestellt.

Die Client-Anwendungen kommunizieren über eine API-Gateway- und eine darauffolgende BFF-Schicht mit den Backend-Systemen. Das zentrale API Gateway übernimmt dabei ausschließlich querschnittliche Aufgaben wie Authentifizierung, Routing und Request-Validierung und enthält keine fachliche Geschäftslogik.

Zwischen Frontend und Backend wird eine BFF-Schicht eingesetzt, die jeweils auf die Anforderungen der einzelnen Clients zugeschnitten ist. Der Rider BFF optimiert die Kommunikation für Buchungsprozesse und UX-Flows, während der Driver BFF insbesondere Echtzeitkommunikation und Dispatch-Ereignisse unterstützt. Der Rider Web BFF ist auf browserbasierte Anforderungen wie Datenaggregation und SEO optimiert.

Durch die Trennung der BFFs werden die Frontend-Komplexität reduziert, unnötige Datenübertragung (Over-Fetching) vermieden und unterschiedliche Nutzererfahrungen unabhängig voneinander unterstützt. Die fachliche Geschäftslogik verbleibt weiterhin in den Backend-Domain-Services.

8. Designsystem

Neben der Frontend-Architektur ist auch eine konsistente UX über verschiedene Plattformen hinweg von zentraler Bedeutung, da sie die Benutzerfreundlichkeit, Zufriedenheit und das Vertrauen der Nutzer beeinflusst [4]. Zur Sicherstellung dieser Konsistenz werden Designsysteme eingesetzt [4][41]. Daher betrachtet dieser Abschnitt deren grundlegende Konzepte sowie deren Einsatz im Kontext der betrachteten Anwendung.

8.1. Designsystem Definition

Ein Designsystem ist eine zentrale Sammlung von Standards, Richtlinien und wiederverwendbaren UI-Komponenten zur konsistenten und skalierbaren Entwicklung digitaler Produkte. Es umfasst typischerweise einen Styleguide mit Gestaltungsrichtlinien (z. B. Farben, Typografie und Interaktionsprinzipien), eine Component Library mit wiederverwendbaren UI-Komponenten sowie eine Pattern Library mit wiederkehrenden Interaktions- und Layoutmustern [41].

8.2. Designsystem von Uber

Uber verwendet das Base Design System [42] als zentrales Designsystem für seine Produkte. Es vereint Gestaltungsrichtlinien, Komponenten und UI-Patterns in einem einheitlichen System und besteht aus einem Styleguide, einer Component Library sowie einer Pattern Library. Ziel ist eine konsistente UX und eine effiziente Entwicklung über verschiedene Anwendungen hinweg [42].

Für Webanwendungen stellt Uber zusätzlich Base Web [43] bereit, eine React-basierte Open-Source-Komponentenbibliothek, die das Designsystem technisch umsetzt. Sie umfasst wiederverwendbare UI-Komponenten, unterstützt Barrierefreiheit standardmäßig und ermöglicht durch Design Tokens sowie Overrides eine flexible Anpassung. Zudem ist sie hinsichtlich Performance optimiert [43].

Der Einsatz des Designsystems fördert eine konsistente UI, reduziert den Entwicklungsaufwand durch Wiederverwendung und erleichtert die Skalierung großer Anwendungen. Daher eignet sich das Base Design System als Grundlage für die Frontendentwicklung des ULSSs im Uber-Kontext.

9. Diskussion

Die in dieser Arbeit vorgeschlagene Frontend-Architektur stellt einen geeigneten Lösungsansatz für das betrachtete ULSS im Uber-Kontext dar. Dennoch sind die getroffenen Architekturentscheidungen stets im Zusammenhang mit den zugrunde gelegten Anforderungen und Annahmen zu betrachten.

Die Entscheidung für separate monolithische Frontends in Abschnitt 6 basiert insbesondere auf der Priorisierung von Echtzeitfähigkeit, durchgängigen UX-Flows und einem konsistenten State Management. Werden hingegen andere Ziele, wie eine möglichst unabhängige Entwicklung vieler autonomer Teams oder eine schnelle organisatorische Skalierung, stärker gewichtet, kann ein Micro-Frontend-Ansatz trotz der höheren technischen Komplexität geeigneter sein (siehe Abschnitt 5.3). Die Wahl des Architekturmodells hängt somit wesentlich von den fachlichen und organisatorischen Rahmenbedingungen eines Unternehmens ab.

Darüber hinaus geht die Arbeit von einer klaren Trennung zwischen Web- und Mobile-Anwendungen aus. Mit plattformübergreifenden Technologien wie React Native oder Ionic können Teile der Implementierung zwischen Web- und Mobile-Anwendungen gemeinsam genutzt werden [44][45]. Dadurch lassen sich Entwicklungsaufwand und Wartung reduzieren, während gleichzeitig neue Anforderungen hinsichtlich gemeinsamer Codebasis, Plattformanpassungen und Architektur entstehen. Ob eine vollständige Trennung oder eine stärkere Wiederverwendung von Komponenten sinnvoll ist, hängt daher von den jeweiligen Projektzielen und Plattformanforderungen ab.

Schließlich handelt es sich bei der Arbeit um eine konzeptionelle Architekturbetrachtung. Die vorgeschlagenen Architekturentscheidungen wurden auf Basis der in dieser Arbeit ausgewerteten Quellen sowie der zugrunde gelegten Anforderungen des Uber-Szenarios hergeleitet, jedoch nicht anhand eines implementierten Prototyps oder quantitativer Messungen evaluiert. Aussagen zu den behandelten Themen beruhen daher auf einer theoretischen Bewertung und sollten in zukünftigen Arbeiten durch praktische Implementierungen und empirische Untersuchungen validiert werden.

10. Fazit

Diese Arbeit hat zentrale Konzepte und Architekturentscheidungen für das Frontend eines ULSSs am Beispiel eines Uber-ähnlichen Systems untersucht. Dabei wurde deutlich, dass moderne Frontend-Architekturen eine ganzheitliche Betrachtung von Struktur, Rendering, State Management, Backend-Integration und UX-Anforderungen erfordern.

Für das betrachtete ULSS wird eine Architektur mit separaten monolithischen Frontends für die jeweiligen Client-Anwendungen gewählt. Jedes Frontend basiert dabei auf einer Component-Based Architecture, um Funktionalitäten modular zu strukturieren und wiederverwendbare Komponenten zu ermöglichen.

Die Entscheidung für monolithische Frontend-Architekturen basiert insbesondere auf den hohen Anforderungen an Echtzeitfähigkeit, konsistente UX und ein einheitliches State Management. Im Gegensatz zu Micro-Frontends ermöglicht dieser Ansatz eine geringere technische Komplexität und eine effizientere Verwaltung eng gekoppelter Funktionalitäten wie Kartenansicht, Buchung und Live-Tracking.

Hinsichtlich des Renderings wurde ein hybrider Ansatz gewählt, der die Vorteile verschiedener Rendering-Methoden kombiniert. Während CSR und SPA für hochinteraktive Bereiche mit Echtzeitdaten eingesetzt werden, eignen sich SSR und SSG für statische oder öffentlich zugängliche Inhalte. Ergänzend ermöglicht ein strukturiertes State-Management-Konzept mit einer Trennung von Client State und Server State eine skalierbare Verwaltung der komplexen Datenflüsse.

Die Integration mit dem Backend erfolgt über eine API-Gateway- und BFF-Schicht, wodurch die Frontends von der Komplexität der zugrunde liegenden Microservice-Architektur entkoppelt werden. Ergänzend gewährleisten WebSockets die notwendige Echtzeitkommunikation für Funktionen wie Standortverfolgung und Statusaktualisierungen.

Zusätzlich wird eine konsistente UX auf verschiedenen Plattformen durch ein zentral eingesetztes Designsystem unterstützt. Durch das Designsystem wird zudem die Wiederverwendbarkeit von Komponenten erhöht.

Zusammenfassend zeigt sich, dass die Frontend-Architektur für ein ULSS im Uber-Kontext unter Berücksichtigung des Architecture Inception Canvas nicht durch eine sofortige maximale Modularisierung einzelner Komponenten entsteht, sondern durch eine ausgewogene Kombination aus beherrschbarer Komplexität, Wartbarkeit, Performance und konsistenter UX. Bei einer tatsächlichen Umsetzung müssen konkrete Implementierungsdetails jedoch an die jeweiligen Rahmenbedingungen angepasst werden.

11. Ausblick

Eine mögliche Weiterentwicklung der vorgestellten Architektur besteht in der schrittweisen Einführung weiterer Modularisierungskonzepte. Bei stark wachsender Organisationsgröße könnten, wie in Abschnitt 9 angedeutet, Micro-Frontend-Ansätze für ausgewählte, klar abgegrenzte Domänen eingesetzt werden, sofern die Vorteile einer unabhängigen Entwicklung die zusätzliche technische Komplexität dann rechtfertigen.

Darüber hinaus bieten zukünftige Entwicklungen im Bereich Edge Computing, Streaming-Architekturen und automatisierter Performance-Optimierung weitere Möglichkeiten zur Verbesserung global verteilter Anwendungen. Insbesondere die Optimierung von Echtzeitkommunikation und die effiziente Verarbeitung großer Mengen an Standort- und Nutzerdaten bleiben zentrale Herausforderungen.

Ein weiterer Untersuchungsbereich liegt in der nutzerzentrierten Gestaltung bei verzögerten Ladeprozessen. Bei Funktionen mit hoher Datenabhängigkeit stellt sich insbesondere die Frage, welche Informationen Nutzern während des Ladens oder bei eingeschränkter Datenverfügbarkeit angezeigt werden sollten. Konzepte wie schrittweise Inhaltsbereitstellung, Ladezustände oder alternative Informationsdarstellungen könnten hierbei untersucht werden, um trotz technischer Verzögerungen eine konsistente Nutzererfahrung sicherzustellen.

Referenzen

[1] Software Engineering Institute, “Ultra-Large-Scale Systems: The Software Challenge of the Future”, Carnegie Mellon University, 2006.
[2] K. Kamboj, “System Design 101: The Architecture Behind Large-Scale Applications”, Medium, 2026.
[3] Uber Technologies, Inc., “Uber Developer Documentation”, 2026.
[4] R. G. N. Dunes, “Frontend System Design of Uber”, Substack.
[5] A. Zubrytskyi, “Importance of Front-End Development For Your Industry and Business”, Elitex Systems, 2025.
[6] Hochschule der Medien Stuttgart, “Uber Architecture Inception Canvas”, 2026.
[7] Hochschule der Medien Stuttgart, “Anforderungen für das gewählte System”, 2026.
[8] GeeksforGeeks, “Component-Based Architecture — System Design”, 2025.
[9] Mozilla Developer Network, “SPA (Single-page application)”.
[10] GeeksforGeeks, “What is Single Page Application (SPA)?”.
[11] JulesWritesCode, “The Junior Developer’s Complete Guide to SSR, SSG and SPA”, Medium, 2024.
[12] Y. Jadvani, “CSR vs SSR vs SSG vs ISR: A Deep Dive for Modern Web Development”, DEV Community, 2024.
[13] GeeksforGeeks, “CDN vs Edge Server — System Design”.
[14] C. Sharma, “What is Edge Rendering and How to Implement It Using Next.js”, C# Corner.
[15] Sparity, “Modern Web Development: Why Hybrid Rendering Is the Future”, 2025.
[16] E. Hecks, “Understanding Hydration in Frontend Frameworks: Definition, Challenges, and Optimization Strategies”, Frontend Dogma, 2026.
[17] Mimo, “State Management”, Mimo Glossary.
[18] F. Sharif, “State Management in Software Development”, DEV Community.
[19] Redux, “Getting Started”, Redux Documentation.
[20] A. Singh, “Redux vs Zustand vs Context API: Their Pros, Cons and Usage”, Medium, Design Bootcamp.
[21] Zustand Team, “Introduction”, Zustand Documentation, 2025.
[22] TanStack, “TanStack Query Documentation”.
[23] WriterDock, “Is TanStack Worth Learning in 2026? Pros, Cons, and Use Cases”.
[24] Meta Platforms, Inc., “React Documentation”, 2026.
[25] Uber Technologies, Inc., “Introducing Fusion.js: A Plugin-based Universal Web Framework”, 2018.
[26] Fusion.js Engineering, “Fusion.js Documentation: Overview”, 2026.
[27] Node.js Foundation, “Node.js Documentation”, 2026.
[28] Palo Alto Networks, “What Is an API Gateway?”.
[29] A. P. Singh, “What is an API Gateway?”, AlgoMaster.
[30] S. Newman, “Backends For Frontends”.
[31] ITNEXT, “Backend for Frontend (BFF): What It Is and When to Use It”.
[32] Postman, “GraphQL vs REST: What Are the Differences?”.
[33] Ably, “WebSockets vs Long Polling: Which Should You Use?”.
[34] AlterSquare, “Monolith vs Modular Frontend Architecture: When Each Breaks”.
[35] Z. Ali, “Micro Frontends: Monolith vs MFE”, DEV Community.
[36] A. E. Marajan, “Monolithic vs Micro Frontend: Which Architecture Should You Choose?”, DEV Community.
[37] Codex, “Frontend Architecture: Monoliths, Microfrontends, and Monorepos”, Medium.
[38] S. Peltonen, L. Mezzalira, and D. Taibi, “Motivations, Benefits, and Issues for Adopting Micro-Frontends: A Multivocal Literature Review”, Information and Software Technology, vol. 136, 2021.
[39] Amazon Web Services, “Micro-Frontends on AWS — Introduction”.
[40] C. Jackson, “Micro Frontends”, Martin Fowler.
[41] T. Fessenden, “Design Systems 101”, Nielsen Norman Group, 2021.
[42] Uber Technologies, Inc., “Base Design System”, Uber Base, 2026.
[43] Uber Technologies, Inc., “Base Web React UI Framework”, Base Web.
[44] Meta Platforms, Inc., “React Native Documentation”, 2026.
[45] Ionic, “Ionic Framework Documentation”, 2026.