Hallo liebe Leute, eigentlich wäre heute ein weiterer Teil der Blogserie “CMS Wahl” dran… Ich muss euch aber gestehen, dass mir momentan so viele andere Gedanken durch den Kopf schwirren, sodass ich die Fortsetzung auf’s nächste Mal verschiebe. Da erfahrt ihr dann meine persönlichen Erfahrungen mit Typo3.
Da momentan viele große Projekte anstehen, viel geplant, konzipiert und recherchiert wird, erzählt dieser Beitrag von Entwicklungskonzepten und welche Basis-Komponenten in beinahe all unseren Projekten Verwendung finden. Ich sags gleich vorab: dieser Beitrag bezieht sich hauptsächlich auf die serverseitige Entwicklung; der Frontend-Part wird nur sehr oberflächlich behandelt.
Ich gehe in diesem Beitrag auch nur darauf ein, dass die Applikation von uns selbst entwickelt wird, und nicht auf ein bestehendes CMS aufbaut. In jenem Fall wäre die Vorgehensweise etwas anders.
Noch vor dem Projektstart setzen sich unsere Front- und Backend-Entwickler zusammen, um ein Konzept zu erarbeiten, wie die Kommunikation zwischen Client & Server aussehen wird. Manch einer wird sich’s schon denken – in den meisten Fällen lösen wir das über eine definierte Schnittstelle, auch bekannt als API (application programming interface). Das bedeutet, dass das Backend komplett vom Frontend getrennt entwickelt wird, was einige Vorteile bietet:
- Die Web-App lädt schnell das Grundgerüst (sehr schneller page-load) und kann dann nach eigens definierter Priorität Inhalte nachladen. Für eine bessere User-Experience können pro Bereich Ladeanimationen angezeigt werden.
- die Entwickler bleiben in Ihrem Fachgebiet. Die Backend-Entwickler hantieren nur mit Backend-Frameworks & -Techniken und sind frei von Frontend-Code. Umgekehrt gilt dasselbe auch für Frontend-Entwickler, welche in Ihrem Projekt nicht mit Backend-Code konfrontiert werden.
- Wenn die API entwickelt ist, können Applikationen jeder Art sie nutzen, solange sie autorisiert sind. Das bedeutet, dass Datenbank und Backend-Logik nur einmal programmiert werden müssen. Das erleichtert beispielsweise eine Erweiterung auf eine Mobile-App zu einem späteren Zeitpunkt enorm, da dann nur noch das Frontend für die App programmiert werden muss.
- Sehr komplexe Software lässt sich durch APIs modularisieren. Das bedeutet, dass einzelne Funktionen in Programmmodule ausgelagert werden, um eine saubere Gesamtstruktur zu erhalten.
- Backend & Frontend sind strikt voneinander getrennt.
- …
Bei der Konzeption des Backends wird zu Beginn eine Liste erstellt – yeey 😀
Dafür wird für jeden Punkt der Anforderungen des Endprodukts notiert, durch welche Funktionen diese erfüllt werden… Ein Beispiel dafür könnte sein:
Auszug aus Anforderungen:
„In der Web-Applikation muss es uns möglich sein, User zu verwalten.”
- Die daraus entstandene, einfache Liste:
Web-Applikation:- HTTP Request Handling
- Routing
- …
- Userverwaltung:
- Benutzer (Datenbank)
- Rollen (Datenbank)
- Berechtigungen (cached settings)
- Authentifizierung (oAuth2 API Authentifizierung)
Wie ihr seht, wird eine inhaltliche Wunschliste des Kundens in eine technische Funktionsliste übersetzt. Ich persönlich schreibe mir zu dieser Liste, sofern ich schon Lösungsansätze im Kopf habe diese gleich dazu (in diesem Beispiel, dass Benutzer in der Datenbank gespeichert werden und Berechtigungen aus Settings-Files ausgelesen und gecached werden) — natürlich unverbindlich 😉
Im nächsten Schritt werden für die technischen Anforderungen entsprechende Packages gesucht. In der PHP-Welt kann ich nur Composer als Package-Manager empfehlen. Dieser lädt Pakete aus dem Internet, installiert zusätzlich alle Abhängigkeiten und man hat im Nu eine Applikation, mit vielen, vielen Funktionen – obwohl man selbst nur wenige Zeilen Code geschrieben hat.
Falls ihr’s noch nicht kennt, empfehle ich euch in diesem Schritt die Symfony Komponenten durchzuschauen. Symfony ist Open-Source und beinahe alle PHP Frameworks bauen auf zumindest einigen Komponenten davon auf. Es verbirgt sich eine riesige Community dahinter und alle Funktionen um eine Web-App zu bauen, sind bereits hoch-performant programmiert. All unsere Projekte haben zumindest ein paar der Komponenten im Einsatz.
Um Erweiterbarkeit zu gewährleisten, empfiehlt es sich, dem Kern einen Plugin-Manager hinzuzufügen. Hier ist sicherzustellen, dass Plugins die Möglichkeit haben, alle Funktionen (API, Datenbank, Berechtigungen, …) zu erweitern.
Wenn dieser Punkt erreicht ist, gehts auch schon an die Business-Logic. Alle wiederkehrenden Anforderungen (z.B. User-Management) werden natürlich als Plugins implementiert. Dadurch hat man nicht nur Erweiterbarkeit, sondern auch Wiederverwendbarkeit gewährleistet. Pro Projekt müssen dann immer nur spezifische Anpassungen an die jeweiligen Anforderungen vorgenommen werden.
Dieses (etwas vereinfachte) Konzept hat sich bei uns etabliert und die meisten großen Web-Apps bauen darauf auf. Wir sind natürlich auch neugierig auf eure Konzepte – wie geht ihr mit großen Web-Applikationen um? Lasst es uns in den Kommentaren wissen!
