Stack & Werkzeuge

Haupt-Stack. Ausgereiftes Ökosystem, Eloquent für den Alltag und eine Community, die 90% der üblichen Probleme bereits gelöst hat.

Wo Performance zählt. Hält die Anwendung zwischen Anfragen im Speicher und eliminiert die Startkosten des klassischen PHP-Zyklus. Auf stark frequentierten Abfrage-Routen ist der Unterschied spürbar.

Für Services, bei denen starke Typisierung und das Enterprise-Ökosystem zählen. Spring deckt Sicherheit, Persistenz und Konfiguration ab.

Keine Entscheidung, sondern Realität vieler Produktionssysteme. Sich in einer Legacy-Codebasis zu bewegen, ohne sie zu zerbrechen, ist eine eigene Fähigkeit.

JavaScript im Backend, vor allem in Webprojekten, in denen der übrige Stack ohnehin dieselbe Sprache spricht.

Frontend, Scripting und Werkzeuge. TypeScript, sobald das Projekt länger als ein paar Monate leben soll.

Haupt-Frontend-Framework. Die Composition API hält die Logik geordnet, während die Komponente wächst.

Auf Vue, für Verwaltungsanwendungen: Extranets, Intranets und Dashboards. Ein konsistenter Komponentenkatalog, der verhindert, das Designsystem pro Oberfläche neu zu bauen.

In Projekten, in denen Team oder Kunde es bereits einsetzen. Funktionskomponenten mit Hooks, ohne ein schweres Framework obendrauf.

Für Frontends, die von Haus aus eine strengere, typisierte Struktur wollen — üblich in Verwaltungsanwendungen mit größeren Teams.

Individuelle Entwicklung auf WordPress, wenn der Kunde seine Inhalte selbst pflegen will, ohne von jemandem abhängig zu sein.

Für Content-Seiten wie diese. Standardmäßig kein JavaScript und Inhalte in Markdown ohne CMS.

Utility-first. Visuelle Konsistenz, ohne ein Stylesheet anzuhäufen, das niemand mehr anfassen will.

Die Datenbanken, mit denen ich in Produktion gearbeitet habe. Gut modelliert und indexiert halten sie weit mehr aus, als man annimmt, bevor etwas Exotisches nötig wird.

Cache, Sessions und häufig abgerufene Daten. In einer Verfügbarkeits-Engine ist das der Unterschied zwischen sofort antworten und dieselbe Frage erneut an die Datenbank stellen.

Das Schema ist die teuerste umkehrbare Entscheidung eines Systems. Es verdient mehr Zeit, als es üblicherweise bekommt.

Ausführungspläne lesen und verstehen, welcher Index warum benutzt wird. In Systemen unter echter Last liegen hier die großen Gewinne.

Lese- von Schreibzugriffen trennen, wenn das Abfragevolumen das Schreibvolumen weit übersteigt — der Normalfall bei Verfügbarkeits-Engines.

Der Cloud-Anbieter, mit dem ich arbeite. EC2, RDS und S3 decken das meiste ab, was ein Backend braucht, ohne Dienste aus Modegründen hinzuzufügen.

Reproduzierbare Umgebungen. Compose für die lokale Entwicklung mit vernünftiger Nähe zur Produktion.

Infrastruktur als Code. Der eigentliche Wert liegt nicht in der Automatisierung, sondern darin, im Repository lesen zu können, was existiert und warum.

Reverse Proxy, TLS-Terminierung und Security-Header. Das Stück, das fast nie Ärger macht — und genau deshalb vergessen wird.

Wo am Ende alles läuft. Logs, Prozesse und Ressourcenverbrauch lesen zu können spart enorm viel Diagnosezeit.

Lastspitzen abfangen, ohne die Infrastruktur die übrige Zeit überzudimensionieren.

Kontinuierliche Integration und Auslieferung. Wenn Deployen Angst macht, deployt man selten — und dann ist jedes Deployment riskanter.

API-Design aus Sicht der Konsumenten, nicht danach, wie die Datenbank intern organisiert ist.

Ein Adapter pro Anbieter, ein Modell nach innen. Jede Eigenheit des Anbieters an einer einzigen Stelle gekapselt.

Ohne Zeremonie: entscheidend sind die Grenzen und die Richtung der Abhängigkeiten, nicht das Nachbauen eines Diagramms.

Messen vor dem Optimieren und Arbeit vermeiden statt sie zu beschleunigen.

JetBrains-IDEs für PHP und Java. Automatisiertes Refactoring und Codenavigation zahlen sich in großen Codebasen aus.

Für Frontend, TypeScript, Terraform und Markdown.

Versionskontrolle, überprüfte Pull Requests und Schutz des Hauptbranches.