Webentwicklung

Multi Page Application

Die älteste heute noch oft genutzte Architektur des World Wide Webs. Sie behandelt jede aufgerufene Unterseite wie ein eigenes Dokument, welches in einem eigenen Seitenaufruf geladen wird. Mit jedem Aufruf wird daher die komplette Seite übertragen. Besonders bei größeren Seiten beispielsweise mit vielen Grafiken, Charts oder Datentabellen kann dies durchaus ein Nachteil darstellen. Der Vorteil liegt in der klaren Trennung und den Nutzern, die diese Art der Bedienung seit vielen Jahren gewohnt sind.

Das Internetprotokoll HTTP (Hypertext Transfer Protokoll) basiert seit seiner Erfindung auf der Ausgabe von Dokumenten. Diese waren zunächst tatsächlich einfache Textdateien, die bei der Anfrage ausgegeben wurden. Mittlerweile wurden die Textdateien größtenteils von Datenbanken und dem Webserver ersetzt, welcher die Daten aus der Datenbank abhängig von der aufgerufenen URL ausgibt.

Single Page Application

Bei dieser Architektur ist meistens eine RestAPI vorhanden, welche die vom Frontend angefragten Daten in serialisierter Text-Form ausgibt. Solch ein typischer Datenblock in JSON wäre:

{
    "account": {
        "account_number": 23456,
        "balance": {
            "currency": "eur",
            "value": -50.00
        },
    }
}

Der Anwendungszustand wird dabei an einer anderen Stelle festgelegt. Beispielsweise kann die Entscheidung darüber welche Links angezeigt werden, je nach Architektur in Template oder Backend stattfinden.

HATEOAS - Hypermedia As The Engine Of Application State

Dieses Paradigma stellt eine Ausnahme in RestAPI-Prinzip der Zustandslosigkeit dar. Dabei definiert die API auch den Anwendungs-Zustand, welcher vom Frontend gerendert wird (z.B. Angular, React oä.). Dies kann von Vorteil sein, wenn ein Backend mehrere Systeme definiert wie etwa eine Website + App Kombination.

Was ist ein Paradigma?

In folgendem Beispiel definiert die RestAPI auch die Links für die verfügbaren Aktionen:

{
    "account": {
        "account_number": 23456,
        "balance": {
            "currency": "eur",
            "value": 200.00
        },
        "links": {
            "deposits": "/accounts/23456/deposits",
            "withdrawals": "/accounts/23456/withdrawals",
            "transfers": "/accounts/23456/transfers",
            "close-requests": "/accounts/23456/close-requests"
        }
    }
}

Wenn das Konto überzogen ist, sind weniger Aktionen möglich:

{
    "account": {
        "account_number": 23456,
        "balance": {
            "currency": "eur",
            "value": -50.00
        },
        "links": {
            "deposits": "/accounts/23456/deposits"
        }
    }
}

Hypermedia-Driven Application

Diese Architektur kombiniert die Einfachheit und Flexibilität herkömmlicher Multi-Page-Anwendungen (MPAs) mit der besseren Benutzererfahrung von Single-Page-Anwendungen (SPAs). Im Gegensatz zur SPA mit API werden gerenderte Template Teile ausgetauscht bzw. hinzugefügt. Im Zusammenhang mit Django bedeutet dies einen gravierenden Boost in der Entwicklungs-Geschwindigkeit und -Effizienz. Anstatt Komponenten für das Frontend-Framework zu erstellen, baut man mithilfe der Django Template Sprache kleine Schnipsel, die dann bei bestimmten Events aktualisiert werden. Diese Schnipsel wären im Atomic Design Ansatz die Organismen.

Bei Bedarf kann natürlich dennoch zusätzlich eine RestAPI erstellt werden, z.B. für die Kommunikation mit externen Diensten.

In den meisten Fällen ist der HDA Ansatz heute optimal, denn er gibt dir die Möglichkeit, die Projektrollen flexibler zu besetzen. Während man bei der SPA idR Backend und Frontend-Spezialisten benötigt, kann ein Full-Stack-Entwickler alleine mithilfe der HDA Architektur hervorragende dynamische Webanwendungen bauen. Das bedeutet, man ist flexibler im Ausbau des Teams, was in diesen Zeiten von Vorteil ist.

Auch in Projekten, welche von Beginn an eine API haben, da sie beispielsweise mit anderen Systemen kommunizieren müssen, überwiegen meistens die Vorteile.

Es macht oft wenig Sinn, ein umfangreiches SPA Projekt zu einer HDA upzugraden. Der beste Ansatz ist meistens, Schrittweise die Inseln des alten Modells zu erneuern. HTMX lässt sich beispielsweise parallell zur alten Frontend-Library verwenden und mit knap 50kB ist die zusätzliche Datenmenge nicht alzu groß. Mit dem eingesparten JavaScript Anteil hat man dies häufig sehr schnell übertroffen.

HPA eignet sich generell für fast alle Seiten. Besonders hervorzuheben sind Anwendungen mit vielen Informationen und/oder langen Ladezeiten. Große Elemente, insbesondere außerhalb des Sichtfelds, können nach dem Aufbau der Seite nachgeladen werden, wodurch die Bedienung flüssiger wird. Diese als "Lazy loading" bezeichnete Methode findet man heute bereits sehr häufig im Internet. Man kann auch bereiche bestimmen, die nur dann geladen werden, wenn sie tatsächlich aufgerufen werden, also durch Scrollen in den Sichtbereich wandern. Dies hat weiterhin den Vorteil, dass man das Benutzerverhalten tracken und optimieren kann.

Ein großer Bonus ist die Suchmaschinenfreundlichkeit und abwärtskompatibilität. Mit HTMX können Webanwendungen so geschrieben werden, dass sie sogar mit deaktiviertem JavaScript und auf alten Browsern voll funktionsfähig sind. In diesen Situationen fällt die Funktionalität automatisch zurück zum alten Webstandard.

Ein gutes Beispiel dafür ist diese Seite. Alle Seiten sind einzeln aufrufbar und nur wenn der Browser modern genug ist, wird die Bedienung optimiert, indem beispielsweise Inhalte von Unterseiten in einem Popup Fenster geladen werden.