Webprogrammierung Hannover: individuelle Software, wenn der Standard an seine Grenze kommt

Backend: die Geschäftsregel gehört in den Code

Das Backend ist die Instanz, die entscheidet. Es prüft, ob eine Person auf einen Datensatz zugreifen darf, ob ein Vorgang freigegeben ist, welcher Wert berechnet wird und was an ein angebundenes System übergeben wird. Alles, was der Browser anzeigt, ist eine Darstellung dieser Entscheidung, niemals ihr Ersatz.

Typische Aufgaben individueller Backend-Logik sind mehrstufige Freigaben, rollenabhängige Zugriffsrechte, Berechnungen mit Plausibilitätsprüfung, Statuswechsel mit definierten Folgeaktionen, zeitgesteuerte Verarbeitung, Import und Export großer Datenbestände sowie eine Protokollierung fachlich relevanter Änderungen. Wichtig ist dabei weniger die einzelne Funktion als die Frage, wo eine Regel genau einmal steht. Eine Rabattgrenze, die an vier Stellen implementiert ist, wird irgendwann an drei Stellen falsch sein.

Für PHP-Anwendungen arbeiten wir je nach Ausgangslage mit etablierten Frameworks. Laravel ist ein quelloffenes PHP-Framework, das 2011 von Taylor Otwell erstmals veröffentlicht wurde. Symfony erschien 2005 bei SensioLabs, und seine Komponenten werden bis heute in zahlreichen anderen PHP-Projekten wiederverwendet. PHP ist laut W3Techs die am weitesten verbreitete serverseitige Programmiersprache im Web, was für mittelständische Unternehmen einen sehr praktischen Vorteil hat: Know-how, Hosting und Werkzeuge bleiben langfristig verfügbar, auch wenn ein Team wechselt. Ausschlaggebend bleibt trotzdem die Eignung für den konkreten Fall, nicht die Verbreitung.

Das Datenmodell entscheidet, was später möglich ist

Eine Webanwendung ist so belastbar wie ihr Datenmodell. Unklare Entitäten und Beziehungen rächen sich nicht am ersten Tag, sondern im zweiten Jahr, in Form doppelter Datensätze, widersprüchlicher Zustände und Sonderfälle, die niemand mehr auflösen kann.

Deshalb klären wir früh:

• Welches System ist für welche Information führend?
• Welche Werte müssen historisiert werden, weil ein späterer Blick auf den Stand von damals nötig ist?
• Welche Änderungen müssen revisionsnah nachvollziehbar bleiben, inklusive Zeitpunkt und Urheber?
• Was passiert fachlich beim Löschen, und was darf überhaupt gelöscht werden?
• Welche Regeln gehören als Bedingung in die Datenbank, weil sie auch dann gelten müssen, wenn ein Import sie umgeht?

Aus den Antworten entsteht ein Modell, das die realen Geschäftsobjekte abbildet. Ob relationale Datenbank, dokumentenorientierter Speicher oder ergänzender Suchindex sinnvoll ist, entscheiden Datenmenge, Abfrageverhalten, Konsistenzanforderung und die erwartete Weiterentwicklung. Schemaänderungen laufen dabei über versionierte Migrationen, damit Test- und Produktivsystem denselben Stand erreichen und ein Rückweg existiert.

Schnittstellen zu ERP, CRM und Warenwirtschaft

Die wenigsten individuellen Anwendungen stehen allein. Sie verbinden vorhandene Systeme: ERP, CRM, Warenwirtschaft, Produktinformations- und Dokumentenmanagementsysteme, Authentifizierungsdienste, Zahlungs- und Versanddienstleister, branchenspezifische Software.

Eine Integration beginnt nicht mit dem ersten API-Aufruf, sondern mit den unangenehmen Fragen. Welches System besitzt die Datenhoheit? Woran erkennen beide Seiten denselben Datensatz, wenn die Nummernkreise nicht übereinstimmen? Was geschieht bei einer Übertragung, die zweimal ankommt, und was bei einer, die nie ankommt? Wir bauen Übergaben deshalb wiederholbar auf, sodass ein erneuter Aufruf keinen zweiten Auftrag erzeugt, ergänzt um Wiederholungslogik, nachvollziehbare Fehlerprotokolle und eine Stelle, an der ein Mensch sieht, was hängen geblieben ist.

Für APIs setzen wir je nach Anwendungsfall REST oder GraphQL ein. GraphQL wurde 2015 als Abfragesprache für APIs öffentlich freigegeben und wird seit 2018 von der GraphQL Foundation verwaltet; REST bleibt der zweite verbreitete Schnittstellenstil. GraphQL spielt seine Stärke aus, wenn verschiedene Clients gezielt unterschiedliche Ausschnitte derselben Daten brauchen. REST passt zu klar abgegrenzten Ressourcen und stabilen Integrationsprozessen. Der Datenfluss bestimmt die Wahl, nicht der Trend.

Stellt ein Altsystem gar keine moderne Schnittstelle bereit, führen strukturierte Dateien, abgesicherte Datenbankzugriffe oder kontrollierte Importstrecken zum Ziel. Auch ein zwanzig Jahre altes System lässt sich in einen sauberen digitalen Ablauf einbinden, solange die Übergabe definiert und überwacht ist.

Portale, Konfiguratoren und interne Werkzeuge

Kunden- und Partnerportale stellen angemeldeten Nutzergruppen Dokumente, Status, Eingaben und Freigaben bereit. Die eigentliche Arbeit steckt im Berechtigungsmodell: Welche Organisation sieht welchen Vorgang, und was passiert, wenn eine Person das Unternehmen wechselt?

Produkt- und Angebotskonfiguratoren übersetzen Auswahlregeln in einen reproduzierbaren Prozess. Abhängigkeiten, Ausschlüsse, Mengenstaffeln und Berechnungen liegen im Code statt in einer gewachsenen Tabelle, und das Ergebnis geht strukturiert an Vertrieb, Warenwirtschaft oder Produktion.

Interne Webanwendungen bündeln, was heute auf Tabellen, E-Mail-Ketten und Einzellösungen verteilt ist. Ihr Wert entsteht dort, wo mehrere Abteilungen mit denselben Daten arbeiten, aber unterschiedliche Sichten und Rechte brauchen.

Engineering-Praxis: nachvollziehbar statt persönlich

Individueller Code darf nicht bedeuten, dass ihn nur seine Urheber verstehen. Git bildet die Grundlage: Das 2005 von Linus Torvalds veröffentlichte Standardwerkzeug zur Versionsverwaltung macht jede Codeänderung nachvollziehbar und rückholbar. Neue Funktionen entstehen in getrennten Zweigen und werden vor der Zusammenführung geprüft.

Dazu gehören außerdem einheitliche Coding-Standards, dokumentierte Architekturentscheidungen, Code-Reviews nach dem Vier-Augen-Prinzip, automatisierte Unit- und Integrationstests, reproduzierbare Entwicklungsumgebungen, getrennte Test- und Produktivsysteme, automatisierte Prüfungen in CI/CD-Pipelines, protokollierte Deployments sowie Monitoring und strukturierte Fehlerlogs.

Tests sichern vor allem die Regeln ab, an denen der Betrieb hängt. Eine Freigabe muss nicht nur im Normalfall funktionieren, sondern auch bei unvollständigen Daten, doppelten Anfragen und fehlender Berechtigung. CI/CD führt diese Prüfungen bei jeder Änderung automatisch aus, sodass ein Fehler auffällt, bevor er produktiv wird, und nicht erst, wenn ihn jemand im Tagesgeschäft bemerkt.

Sicherheit: die OWASP Top 10 als Prüfrahmen

Die OWASP Top 10 benennen die zehn häufigsten Sicherheitsrisiken in Webanwendungen, darunter Injection und Broken Access Control, und gelten als Prüfrahmen für selbst programmierten Code. Für individuelle Entwicklung ist das keine Formalie, sondern eine Checkliste gegen die typischen Fehler.

Konkret heißt das: serverseitige Validierung aller Eingaben, parametrisierte Datenbankabfragen, konsequente Prüfung von Rollen und Rechten pro Anfrage, sichere Passwortspeicherung, geschützte Sitzungen, minimale Rechte für technische Konten, Konfigurationswerte außerhalb des Quellcodes, Protokollierung sicherheitsrelevanter Ereignisse, regelmäßige Kontrolle der eingesetzten Abhängigkeiten und Fehlermeldungen, die nichts über die Interna verraten.

Der häufigste Fehler in Portalen ist unspektakulär: Eine ausgeblendete Schaltfläche ist keine Zugriffskontrolle. Wer die Kennung im Aufruf ändert, muss trotzdem abgewiesen werden. Deshalb prüft das Backend bei jeder einzelnen Anfrage selbst, ob die anfragende Identität diesen konkreten Datensatz sehen oder ändern darf.

Datenschutz als Eigenschaft der Architektur

Die Datenschutz-Grundverordnung gilt seit dem 25. Mai 2018 unmittelbar in allen EU-Mitgliedstaaten und verlangt in Artikel 25 Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Das ist eine Anforderung an die Architektur, nicht an das Layout.

In der Programmierung bedeutet das: Personenbezogene Daten stehen nur dort, wo sie gebraucht werden. Jede Kategorie hat einen Zweck und eine Aufbewahrungsdauer, die als Feld existiert und nicht als Absichtserklärung. Wo Pseudonymisierung möglich ist, wird sie eingeplant, bevor der erste Datensatz entsteht. Auskunft, Berichtigung und Löschung sind nur dann zuverlässig erfüllbar, wenn feststeht, in welchen Systemen eine Person überhaupt vorkommt, auch in den angebundenen. Genau deshalb gehört diese Frage in dieselbe Sitzung wie das Datenmodell.

Frontend-Logik zählt zur technischen Qualität

Auch wenn der Schwerpunkt im Backend liegt: Programmierte Interaktivität ist Teil der Qualität. Google hat zum 12. März 2024 die Metrik Interaction to Next Paint als Core Web Vital eingeführt und damit First Input Delay abgelöst. INP misst, wie schnell eine Seite sichtbar auf eine Interaktion reagiert, und hängt damit direkt an der programmierten Frontend-Logik. Gute Werte entstehen durch schlanke Bündel, effiziente Ereignisverarbeitung, vermiedene Mehrfachabfragen und lange Berechnungen, die nicht den Hauptthread blockieren.

Zusammenarbeit in Hannover

Hannover ist Landeshauptstadt Niedersachsens mit über 500.000 Einwohnern und beherbergt mit der Leibniz Universität Hannover und der Hochschule Hannover zwei Hochschulen mit Informatik-Studiengängen. Individuelle Softwareentwicklung ist hier kein Nischenthema, sondern normaler Bestandteil der Wertschöpfung.

Für ein Projekt zählt am Ende aber weniger der Standort als die Arbeitsweise: Fachbereiche kennen ihre Prozesse, das Entwicklungsteam übersetzt sie in konsistente Software, und Architekturentscheidungen bleiben dokumentiert statt mündlich überliefert. Gestaltung, Systemauswahl, Shop-Themen, Relaunch und laufende Betreuung behandeln wir in den jeweils eigenen Leistungsbereichen.

Der erste Schritt ist keine Zeile Code

Individuelle Webprogrammierung lohnt sich, wenn die Abweichung vom Standard zum Geschäftsmodell gehört und nicht dauerhaft mit manuellen Umwegen kompensiert werden kann. Der Einstieg besteht deshalb darin, den Kern der Anforderung zu klären: Welche Regel muss verlässlich gelten, welche Daten braucht sie, welche Systeme sind beteiligt und woran würde man merken, dass sie verletzt wurde?

Auf dieser Grundlage entsteht eine Anwendung, deren Verhalten prüfbar und deren Quellcode auch in drei Jahren noch lesbar ist. Das ist der Unterschied zwischen einer Sonderlösung und einer Softwarebasis, auf der weitergebaut werden kann.