// d-01daten
Eloquent ORM.
Jede Tabelle wird zum Model, jede Beziehung — Kunde, Bestellung, Position — im Code beschrieben. Datenzugriffe bleiben lesbar und testbar, statt in handgeschriebenem SQL zu verschwinden.
zweck: models + relationen
// stack · php
Wenn eine Website mehr können muss als Inhalte anzeigen, bauen wir die Server-Logik in PHP — meist mit dem Laravel-Framework. Damit entstehen bei siteway eigene Anwendungen, Rechner, Portale und Schnittstellen: sauber modelliert mit Eloquent, Queues und Artisan — statt mit verbogenen CMS-Plugins.
// definition
Laravel ist ein PHP-Framework für Webanwendungen — kein fertiges Produkt, sondern ein strukturiertes Gerüst, mit dem eine Anwendung von Grund auf gebaut wird. Es liefert die Bausteine, die fast jedes Projekt braucht: Routing, das Eloquent-ORM für den Datenbankzugriff, Migrations fürs Schema, Queues für Hintergrundaufgaben und die Kommandozeile Artisan.
Taylor Otwell hat Laravel 2011 veröffentlicht; heute ist es das meistgenutzte PHP-Framework. Der entscheidende Unterschied zu einem CMS wie TYPO3 oder WordPress: Ein CMS verwaltet Inhalte, ein Framework modelliert Logik. Sobald eigene Objekte, Rollen und Abläufe im Zentrum stehen, ist genau das der Punkt, an dem wir zu Laravel greifen.
// praxis
framework als kern · nicht als selbstzweck
Ein Framework nimmt niemandem die Denkarbeit ab — es ordnet sie. Wir setzen Laravel dort ein, wo die eigene Fachlogik der Kern ist: ein Konfigurator, ein Buchungsablauf, ein Portal mit Rollen und Rechten, ein Rechner, der Regeln abbildet. Solche Logik in ein CMS zu pressen funktioniert eine Weile — bis jede neue Anforderung ein Workaround wird. In Laravel wird sie zum sauber modellierten Kern, den man Jahre später noch lesen und erweitern kann.
Dafür halten wir uns an die Struktur, die Laravel vorgibt, statt gegen sie zu arbeiten: die Datenbank als Eloquent-Models mit klaren Beziehungen, das Schema versioniert in Migrations, damit jede Umgebung denselben Stand aufbaut. Fachlogik landet in Services und Actions, nicht im Controller. Eingaben werden über Form Requests validiert, Berechtigungen über Policies geregelt. Das klingt nach Handwerk, weil es Handwerk ist — und es ist der Grund, warum eine Anwendung nach zwei Jahren noch wartbar ist.
Langsames läuft im Hintergrund: E-Mail-Versand, Bildverarbeitung, der Aufruf einer fremden API gehen über Queues, damit der Nutzer sofort eine Antwort bekommt. Wiederkehrende Aufgaben — nächtliche Importe, Aufräumläufe — laufen als Artisan-Befehle im Scheduler. Jeder Code-Stand wird von einem Menschen geprüft und liegt in Git mit GitHub Actions, sodass Deployments reproduzierbar sind statt riskant.
// bausteine · 6 details
jeder mit klarem zweck
Laravel besteht aus vielen Teilen — das sind die, die in unseren Projekten am meisten tragen. Kein Framework-Zwang, sondern das Werkzeug, das die jeweilige Aufgabe am saubersten löst.
// d-01daten
Jede Tabelle wird zum Model, jede Beziehung — Kunde, Bestellung, Position — im Code beschrieben. Datenzugriffe bleiben lesbar und testbar, statt in handgeschriebenem SQL zu verschwinden.
zweck: models + relationen
// d-02schema
Das Datenbankschema liegt versioniert im Git-Repository. Jede Umgebung — lokal, Staging, Produktion — baut denselben Stand auf, und jede Änderung ist nachvollziehbar statt manuell nachgeklickt.
zweck: schema im git
// d-03nebenläufig
Langsame Aufgaben — Mails, Bildverarbeitung, API-Aufrufe — laufen im Hintergrund. Der Nutzer bekommt sofort eine Antwort, die Arbeit erledigt ein Worker nebenläufig. So bleibt die Anwendung schnell, auch unter Last.
zweck: jobs + worker
// d-04automation
Die Kommandozeile von Laravel. Wir bauen eigene Befehle für wiederkehrende Aufgaben und hängen sie in den Scheduler: nächtliche Importe, Reports, Aufräumläufe. Ein Handgriff statt eines Menschen, der daran denken muss.
zweck: cli + scheduler
// d-05sicherheit
Eingaben werden validiert, bevor sie die Fachlogik erreichen; Berechtigungen liegen in Policies statt verstreut im View. Zusammen mit dem Schutz vor CSRF und SQL-Injection nimmt das viele klassische Fehlerquellen von vornherein aus dem Spiel.
zweck: schutz ab werk
// d-06schnittstellen
Eine eigene REST-API fürs Frontend oder eine App, oder die Anbindung von CRM, Warenwirtschaft, Payment und Newsletter. Aufrufe laufen über Queues, jede Anbindung wird protokolliert — ein langsames Fremdsystem bremst die eigene Seite nicht aus.
zweck: rest + integration
// entscheidung
inhalt oder logik
Nicht jedes Projekt braucht ein Framework — die meisten Websites sind mit einem CMS besser bedient, schneller gebaut und einfacher zu pflegen. Die ehrliche Frage lautet: Steht der Inhalt im Zentrum oder die Logik? An diesen Zeichen erkennen wir, dass eine Eigenentwicklung mit Laravel der tragfähigere Weg ist.
// e-01objekte
Wenn deine Fachwelt aus mehr besteht als Seiten und Artikeln — Buchungen, Verträge, Geräte, Anträge — und diese Objekte eigene Regeln und Beziehungen haben, wird ein CMS zur Krücke. Laravel bildet sie direkt ab.
domänen-modell
// e-02abläufe
Mehrstufige Abläufe mit Zuständen, Nutzer mit unterschiedlichen Rechten, Freigaben und Benachrichtigungen: Sobald „wer darf was, und was passiert danach" komplex wird, trägt ein Framework weiter als jedes Plugin.
workflow + policies
// e-03systeme
Wenn die Seite mit CRM, Warenwirtschaft oder Payment sprechen muss oder selbst eine API bereitstellt, ist das Framework-Terrain. Die Anbindung wird zum modellierten Teil der Anwendung, nicht zum fragilen Anbau.
integration
// beleg
nicht aus der doku
Für die Garbe-Gruppe haben wir ein Karten-Portal auf Basis von Mapbox und OpenStreetMap gebaut — eine Anwendung, in der nicht Inhalte, sondern Daten, Filter und Kartenlogik den Kern bilden. Genau der Fall, für den ein Framework gemacht ist: eigene Objekte, eine API dahinter, Prozesse statt Seiten. Ein CMS hätte hier gegen sich selbst gearbeitet.
Wo Inhalt im Zentrum steht, gehen wir den anderen Weg: Der Konzern-Auftritt von Spelsberg läuft auf TYPO3 in 13 Sprachen — Redaktion, nicht Fachlogik. Beide Wege stehen im Werkzeugkasten; wir wählen den, der zum Projekt passt. Alle Referenzen findest du unter Cases.
// faq
Laravel ist ein PHP-Framework für Webanwendungen. Anders als ein fertiges CMS gibt es kein vorgebautes Produkt vor, sondern ein strukturiertes Gerüst: Routing, das Eloquent ORM für den Datenbankzugriff, Migrations für das Schema, Queues für Hintergrundaufgaben und das Kommandozeilen-Werkzeug Artisan. Laravel wurde 2011 von Taylor Otwell veröffentlicht und ist heute das meistgenutzte PHP-Framework. siteway baut damit eigene Anwendungen, Server-Logik und Schnittstellen, die exakt zum Prozess passen.
Ein CMS ist ein fertiges Produkt für Inhalte: Seiten, Artikel, Redaktion. Laravel ist ein Framework — ein Baukasten, mit dem eine Anwendung von Grund auf modelliert wird. Sobald eine Website vor allem Inhalte pflegt, ist ein CMS der schnellere Weg. Sobald eigene Objekte, Rollen, Berechnungen oder Abläufe im Zentrum stehen — ein Buchungssystem, ein Portal, ein Rechner — trägt ein Framework wie Laravel weiter. siteway wählt pro Projekt: TYPO3, WordPress oder Statamic fürs CMS, Laravel für die eigene Anwendung.
Wenn die eigene Fachlogik der Kern ist und nicht der Inhalt. Zeichen dafür: Nutzer haben Rollen und Rechte, es gibt eigene Datenobjekte mit Regeln, Prozesse laufen über mehrere Schritte, es müssen Fremdsysteme angebunden werden oder es entsteht eine eigene API. Ein CMS lässt sich dafür verbiegen, aber jede Sonderlogik wird zur Last. Mit Laravel wird die Logik zum sauber modellierten Kern statt zum Plugin-Workaround. siteway klärt diese Weiche früh — meist schon in Konzept und Strategie.
Eloquent ist die Datenbank-Schicht von Laravel. Statt SQL von Hand zu schreiben, wird jede Tabelle als Model abgebildet, und Beziehungen zwischen Objekten — etwa Kunde, Bestellung, Position — werden im Code beschrieben. Das macht Datenzugriffe lesbar und testbar. siteway nutzt dazu Migrations: Das Datenbankschema liegt versioniert im Git-Repository, sodass jede Umgebung denselben Stand aufbaut und Änderungen nachvollziehbar bleiben.
Queues verschieben langsame Aufgaben aus dem Request in den Hintergrund: E-Mail-Versand, Bildverarbeitung, der Aufruf einer fremden API. Der Nutzer bekommt sofort eine Antwort, die eigentliche Arbeit läuft nebenläufig — das hält die Anwendung schnell. Artisan ist die Kommandozeile von Laravel: siteway baut damit eigene Befehle für wiederkehrende Aufgaben und geplante Jobs, etwa nächtliche Importe oder Aufräumläufe. Beides zusammen macht eine Anwendung belastbar statt nur lauffähig.
Laravel bringt die wichtigen Schutzmechanismen ab Werk mit: Schutz vor CSRF und SQL-Injection, Passwort-Hashing, Validierung von Eingaben und ein Rechtesystem über Policies. Das nimmt viele klassische Fehlerquellen von vornherein aus dem Spiel. siteway ergänzt das um Security-Header, HTTPS mit HSTS und eine trackingfreie, datensparsame Umsetzung — Details im Stack unter Sicherheit & Datenschutz.
Ja. Laravel eignet sich sehr gut für Schnittstellen: eine eigene REST-API für App oder Frontend, oder die Anbindung fremder Systeme wie CRM, Warenwirtschaft, Payment oder Newsletter. Aufrufe laufen über Queues, damit ein langsames Fremdsystem die eigene Seite nicht ausbremst, und jede Anbindung wird protokolliert. Die Umsetzung als Leistung liegt bei Schnittstellen & Integration, die Technik dahinter ist dieser Stack.
// womit das zusammenhängt
leistung & stack
// framework · im detail
Das Framework im Detail: Eloquent, Migrations, Queues, Artisan — und die Architektur-Leitplanken, nach denen wir bauen.
weiterlesen →
// leistung · buchen
Diese Technik als Leistung: Wir setzen deine Anwendung um — von Templates bis zur eigenen Laravel-App. Hier wird gebucht.
weiterlesen →
// stack · cms
Die andere Seite der Weiche: TYPO3, WordPress und Statamic, wenn der Inhalt im Zentrum steht statt der Fachlogik.
zum stack →
// stack · betrieb
Wie eine Laravel-Anwendung live geht und läuft: Git, GitHub Actions, reproduzierbare Deployments und Monitoring.
zum stack →
// Eigene Anwendung im Kopf?
Projekt anfragen