Fallback Image
Fallback Image

Im Gespräch mit

Laravel-Gründer Taylor Otwell

Beim Q&A mit Taylor Otwell beim vergangenen Laravel DACH Meetup nutzten die Teilnehmenden die Möglichkeit ihre persönlichen Fragen zu stellen. Die Antworten gibt es hier.

Für die Teilnehmenden des Laravel DACH Meetups bot sich vergangenen Woche eine seltene Möglichkeit: Laravel Gründer Taylor Otwell war zu Gast im Meetup und beantwortete in einem Q&A die Fragen der Anwesenden. Die spannendsten Fragen und Antworten des Abends möchten wir natürlich auch hier nicht vorenthalten. Die Aufzeichnung des gesamten Meetups ist hier verfügbar.

Taylor, gestern hast du deine Follower auf Twitter gefragt, an was sie in letzter Zeit arbeiten. Woran arbeitest du im Moment?

Wir arbeiten an ein mehreren Dingen. Ich baue ein Projekt, das ich noch nicht veröffentlicht habe, es heißt Beep. Es ist etwas anders als meine anderen Projekte. Es ist nicht unbedingt ein Entwickler-Tool, sondern eher ein Team-Produktivitäts-Tool, das wir sozusagen danach modellieren, wie wir die Dinge hier bei Laravel machen. Ich habe dieses Projekt im August fertiggestellt, seitdem hat es den Front-End-Design-Prozess durchlaufen. Aber jetzt ist es endlich fertig. Ich habe die funktionierende Anwendung in meinen Händen, mit dem Design und allem, was dazu gehört. Jetzt gehe ich sie nur noch durch, verpasse ihr den letzten Schliff und füge einige Funktionen hinzu. Ich hoffe, dass ich sie am 9. Februar auf dem Laracon-Event veröffentlichen kann. Es wird ein völlig offenes Projekt sein. Ich werde eine gehostete Version davon bereitstellen, aber auch den gesamten Code Open-Source zur Verfügung stellen, sodass jeder ihn lesen, davon lernen und sehen kann, wie ich Laravel verwende, wenn ich meine eigenen Anwendungen erstelle. Es ist keine übermäßig komplizierte Anwendung, aber sie ist kompliziert genug, um als gute Lernressource zu dienen. [...]

Abgesehen davon haben wir uns auf die Veröffentlichung von PHP 8.1 vorbereitet, die nächsten Monat ansteht. Wir mussten Updates an allen unseren Bibliotheken vornehmen, um uns darauf vorzubereiten. Das ist jetzt so gut wie fertig. Außerdem haben wir auch an einer aktualisierten Benutzeroberfläche für Laravel Forge gearbeitet, die ebenfalls weit fortgeschritten ist. Ich denke, sie wird wahrscheinlich noch vor Ende des Jahres veröffentlicht werden. [...]

Apropos Veröffentlichungen und Neuigkeiten: Kannst du uns einen Einblick geben, was die Community mit Laravel 9 erwarten kann?

Laravel 9 wird im Januar veröffentlicht werden und bietet einige wartungsbezogene Funktionen. Zum Beispiel haben wir in Laravel 9 Swift Mailer durch Symfony Mailer ersetzt, weil Swift Mailer nicht mehr weiterentwickelt werden wird. [...] Wir werden auch das Flysystem von 1.0 auf 2.0 aktualisieren. Außerdem gibt es an einigen Stellen ein paar neue Funktionen rund ums Data Types. Es gibt ein neues Query Builder Interface, was zum Type Hinting benutzt werden kann. Aber ehrlich gesagt ist das meiste, was wir gemacht haben, in die aktuelle Version eingeflossen, weil wir uns bemühen, keine bahnbrechenden Änderungen einzuführen. Der einzige Grund, etwas in Laravel 9 einzubauen würden, ist es, wenn dadurch etwas kaputt geht. Und weil wir versuchen, das zu vermeiden, haben wir die meisten Funktionen, an denen wir arbeiten, auf Laravel 8 verlagert.

Mohamed [Said] arbeitet an einem neuen Eloquent Model Cast, der nun auf Enums casten kann, was ein Feature von PHP 8.1 ist. Wir werden also in der Lage sein, Eloquent-Eigenschaften in PHP-Enums zu casten. Denn PHP bekommt endlich eine integrierte Unterstützung für dieses Sprachfeature. Aber auch das könnte schon in Laravel 8 einfließen. [...]

Ich sollte auch erwähnen, dass Laravel 9 für unsere zugrunde liegenden Komponenten, wie Symfony Console, Symfony HttpFoundation, auch auf Symfony 6 aktualisiert wird.

Welche PHP-Version wird für Laravel 9 mindestens erforderlich sein?

[...] Wir haben einige Bibliotheken, die PHP 8 benötigen – das wird auch für Laravel 9 der Fall sein. Bis dahin wird PHP 8 seit über einem Jahr auf dem Markt sein. Es hat einige nette Funktionen, die wir nutzen können. [...]

Einige Leute sagen, dass Laravel nicht gut für sehr große Unternehmensprojekte geeignet ist. Taylor, was denkst du darüber?

Ich denke, dass Laravel für viele Arten von Projekten gut geeignet ist. Häufig hängt es von den Fähigkeiten der Entwickler ab, die an dem Projekt beteiligt sind. [...] Ich denke, der Schlüssel liegt darin, einige der Funktionen zu nutzen, die Laravel bietet, um die Arbeit mit großen Projekten zu erleichtern. Nutzt also alle Testmöglichkeiten, die Laravel bietet, damit ihr sicherstellen können, dass der Code gut getestet ist. Man kann auch Tools wie larastan verwenden, eine Art Laravel-kompatible Version von PHPStan, die eine gute statische Analyse bietet und zum Beispiel sagt, ob eine Methode aufgerufen werden soll, die es für ein Objekt nicht gibt, oder ob einer Methode ein falscher Typ übergeben wird, etc. Einige dieser Dinge kann die IDE [Integrierte Entwicklungsumgebung] mitteilen, andere aber auch nicht. Außerdem gibt es in der Community einige hilfreiche Ressourcen für den Umgang mit großen Laravel-Projekten. Spatie hat ein Buch mit dem Titel "Laravel beyond Crud" veröffentlicht, das sie auf der Grundlage ihrer eigenen Erfahrungen mit großen Laravel-Projekten geschrieben haben. Außerdem gibt es Muster, die man verwenden kann, um sicherzustellen, dass der Code in diesem Kontext wartbar und verständlich ist.

Offensichtlich wurde Laravel in den letzten zehn Jahren in vielen großen Projekten eingesetzt und ich denke, dass der Erfolg des Projekts von dem Entwicklerteam abhängt, das den Code schreibt. Es gibt schlechten Code in allen möglichen Sprachen und Frameworks. [...] Das ist nicht nur bei einem Tool oder einer Sprache so. Es hängt einfach von der Disziplin und den Fähigkeiten der beteiligten Entwickler ab.

Kannst du uns etwas über die Zukunft von Laravel Octane erzählen?

Um einige Hintergrundinformationen zu geben: Octane ist eine Möglichkeit, Laravel-Anwendungen zwischen den Anfragen im Speicher zu halten. Das ist etwas ganz anderes als das, was wir uns normalerweise unter PHP-Anwendungen vorstellen. Normalerweise löst jede neue Anfrage an die Website aus, dass das gesamte Framework seinen gesamten Code von Anfang bis Ende ausführt, um die Anfrage zu bearbeiten. Octane verfolgt einen anderen Ansatz. Er ähnelt dem anderer Sprachen wie Node, wo man die Anwendung einmal startet und das gesamte Framework in den Speicher lädt und – im Fall von Laravel – alle Container-Bindings, alle Konfigurationen usw. im Speicher registriert. Wenn eine neue Anfrage eingeht, erhalten wir sie und bearbeiten sie einfach mit dieser bereits geladenen Anwendungsinstanz. Dadurch wird im Wesentlichen der Boot-Overhead des Frameworks für die Anwendung eliminiert, so dass nur noch der Anwendungscode für die Leistung ausschlaggebend ist. Wir haben das Framework sozusagen aus der Gleichung entfernt.

Das ist natürlich ein enormer Vorteil, denn die Anwendung wird viel schneller laufen. Ein weiterer Vorteil ist, dass die Datenbankverbindung zwischen den Anfragen aufrechterhalten wird und nicht für jede einzelne Anfrage geschlossen und wieder geöffnet werden muss. Das spart mehrere Millisekunden ein, was die Antwortzeit um 10 oder 20 Millisekunden verkürzen kann. Der Nachteil ist, dass man sich bewusst sein muss, dass die Anwendung die ganze Zeit im Speicher läuft. Es ist also etwas einfacher, Speicherlecks zu erzeugen, wenn man nicht darauf achtet. Wenn man dem Array bei jeder Anfrage etwas hinzufügt, wird das Array immer größer und größer und größer. [...]

Einige der jüngsten Entwicklung in Octane ist unsere Octane-Unterstützung in Laravel Vapor, unserem serverlosen Deployment-Tool für Laravel. Es überträgt den Code an AWS Lambda und ist unsere skalierbarste Bereitstellungsplattform für Laravel, die wir derzeit haben. Sie kann Tausende von Anfragen gleichzeitig verarbeiten. Mit Octane nutzen wir den Vorteil, dass die Datenbankverbindung auch zwischen diesen Anfragen besteht. [...]

Darüber hinaus beobachten wir weiterhin neue Funktionen in Swoole, einer PHP-Erweiterung, die von Octane genutzt wird. Sobald neue Funktionen in Swoole verfügbar sind, können wir sie auch in Octane übernehmen.

Ich denke, Octane ist stabil und wird gut angenommen. Uns wird berichtet, dass die Leute es mit großem Erfolg sowohl im Forge-Kontext als auch im Laravel Vapor-Kontext verwenden. Ich glaube, die Leute haben Spaß daran. [...]

Welches ist Ihr Lieblingsprodukt aus dem Laravel-Ökosystem, abgesehen vom Framework selbst?

Das Produkt, das ich am meisten benutze, ist wahrscheinlich Laravel Forge, weil wir wahrscheinlich 20 oder 30 Server haben, die von Laravel Forge verwaltet werden. Die Software, die ich täglich am meisten benutze, ist also definitiv Forge. Das gilt auch für die Community. Forge ist das größte Produkt in Bezug auf die Anzahl der Kunden und verwalteten Server [...]. Es [Forge] wird natürlich immer einen besonderen Platz für mich haben, denn es war das erste Produkt, das erste große kommerzielle Tool, das ich für Laravel geschrieben habe.

Außerhalb des Frameworks selbst denke ich, dass Vapor für alle zukünftigen Sachen, die ich mache, wichtig ist. Alle zukünftigen Projekte werde ich wahrscheinlich auf Laravel Vapor hosten, weil ich mir keine Gedanken über Betriebssystem-Upgrades oder SSL-Zertifikate oder Skalierung von Servern machen muss. Es ist schön, all diese Dinge vergessen zu können. Mir gefällt auch die zeitnahe Wiederherstellung der Datenbank, die man direkt von der Laravel-Vapor-Benutzeroberfläche aus durchführen kann. [...]

Aber um die Frage zu beantworten, würde ich wahrscheinlich Forge sagen. Es ist einfach das, was ich am meisten benutze. Die beste Codebasis hat aber definitiv Laravel Vapor. Auch den Code bin ich besonders stolz und ich halte ihn für am saubersten geschrieben. Das liegt auch daran, dass es am neusten ist, so dass ich einfach mehr Erfahrung hatte. [...]

Wann ist der Zeitpunkt für den Wechsel zu Vapor gekommen?

Es ist immer am besten, so früh wie möglich auf Vapor umzusteigen, damit sichergestellt werden kann, dass die Anwendung kompatibel ist und in Vapor gut funktioniert. Aber es ist nicht unmöglich, ein bestehendes Projekt nach Vapor zu verschieben. [...]

Alles, was ich sagen kann, ist, dass ich es gerne so früh wie möglich mache, um sicherzustellen, dass die Dinge kompatibel sind und gut funktionieren, wenn ich denke, dass es irgendwann etwas in der Größenordnung von Laravel Vapor brauchen wird. Wir sind Entwickler, also gehen wir normalerweise davon aus, dass unsere Anwendungen tonnenweise Skalierung benötigen, aber die Realität ist, dass die meisten das wahrscheinlich nicht tun. Wenn Sie diese Art von Skalierung nicht benötigen, dann ist es natürlich viel einfacher und auch billiger, etwas wie DigitalOcean oder einen anderen VPS [Virtual Private Server]-Service zu nutzen.

Vor einigen Jahren gab es einen Wechsel vom Laravel UI-Paket zu anderen Packages wie Jetstream. Warum wurden die Packages aufgeteilt und warum wird Bootstrap nicht mehr unterstützt?

Ursprünglich sollte es nur Laravel Jetstream geben. Ich wollte das Back-End und das Front-End aufteilen, so dass man – wenn man nur ein Authentifizierungs-Back-End möchte, z. B. für eine SPA [Single Page Application] oder etwas anderes – Laravel Fortify verwenden kann. Man könnte es so sehen, dass Laravel UI in zwei Pakete aufgeteilt wurde: im Wesentlichen Laravel Fortify als Back-End und Laravel Jetstream als Front-End, das das Laravel Fortify Back-End verwendet. Prinzipiell konnte allerdings jedes beliebige Frontend mit Laravel Fortify verwenden werden. So die Idee.

Als Laravel Jetstream auf den Markt kam, gab es gemischte Kritiken, weil ich glaube, dass einige Leute es im Vergleich zu Laravel UI zu kompliziert fanden. In mancher Hinsicht ist es auch komplizierter als Laravel UI. Als Antwort darauf habe ich einen geistigen Nachfolger von Laravel UI geschrieben, sozusagen eine nächste Generation von Laravel UI mit Laravel Breeze […]. Laravel Breeze ist Laravel UI insofern sehr ähnlich, als dass der gesamte Code direkt vor uns liegt. Es handelt sich nicht wirklich um ein großes Paket. Alles, was es tut, ist das Kopieren der Ansichten und Controller an Ort und Stelle. Dann können wir den Code ganz nach unserem Belieben anpassen. Laravel Breeze finde ich wirklich sehr gut. Mir gefällt, wie einfach und unkompliziert es ist. Ich denke, dass es ein besserer Nachfolger für Laravel UI ist als Jetstream. Jetstream ist gut und schön, wenn man ein etwas komplexeres Verhalten oder ein robusteres Projekt benötigt, aber Laravel Breeze ist wahrscheinlich für die meisten Projekte ausreichend. Im Nachhinein betrachtet, hätte ich vielleicht nur Laravel Breeze veröffentlicht, wenn es das zuerst gegeben.

Bezüglich des Wechsels von Bootstrap zu Tailwind: Der größte Teil des Wechsels war, dass wir Bootstrap bei Laravel einfach nicht mehr für neue Entwicklungen verwendet haben, sondern nur noch Tailwind. Wir waren uns nicht sicher, ob wir etwas pflegen wollten, was wir nicht selbst benutzen oder als Entwickler für neue Projekte nicht benutzen würden. Wir hatten das Gefühl, dass Tailwind anpassungsfähiger und flexibler ist, was die Erstellung von maßgeschneiderten Benutzeroberflächen angeht. Also haben wir es einfach in die Hände der Community gelegt. Wenn sie eine Bootstrap-Version des Authentifizierungsgerüsts will, kann sie das tun. Damit haben wir uns dazu verpflichtet, Laravel UI auf dem neuesten Stand zu halten, was die PHP- und Laravel-Versionen angeht. Bootstrap wird immer noch gewartet und es kann heute noch in einem Laravel-Projekt installiert werden. Es ist nicht wirklich etwas, dem wir neue Funktionen hinzufügen oder für das wir große Pläne haben, denn ich betrachte Breeze und Jetstream als eine Art aktuelle Generation dieser Art von Tool. Aber halten es für Leute, die Bootstrap mögen, am Laufen. Wie gesagt, wir verwenden Tailwind für alle unsere neuen Produkte, wie Laravel Vapor oder Laravel Nova, die komplett auf Tailwind basieren. Es ist also einfach das Tool, das wir verwenden.

Hast du schon entschieden, ob die nächste Laracon US eine persönliche Veranstaltung sein wird?

Ich neige dazu, dass es eine persönliche Veranstaltung wird. [...] Ich habe Anfang dieser Woche mit einem Veranstaltungsort in New York gesprochen. [...] Ich denke, es wird eine kleinere Veranstaltung sein, vielleicht 400 oder 500 Leute. Das ist immer noch eine ziemlich große Anzahl von Leuten, aber kleiner als 2019, als wir fast 900 Leute hatten.

Die Veranstaltungsorte in New York verlangen ab sofort entweder eine Impfung oder den Nachweis eines negativen COVID-Tests, sodass es vom Veranstaltungsort und dem jeweiligen Bundesstaat abhängt, wie er entscheidet. Aber ich würde es gerne persönlich machen. Ich denke, es macht einfach viel mehr Spaß als online. Beides hat natürlich seine Vorteile: Wenn man es online macht, können viele Leute teilnehmen, und man kann 4000 oder 5000 Teilnehmer haben. Aber es ist auch schön, sich persönlich zu treffen und sich persönlich zu unterhalten. Im Moment plane ich also, wahrscheinlich im Sommer eine Veranstaltung zu organisieren, bei der man sich persönlich trifft. Das wäre dann wahrscheinlich im Juli 2022.

Kommende Events zum Thema Laravel

Eine Möglichkeit, Taylor Otwell persönlich zu treffen, gibt es vom 13. bis 14. Januar 2022 auf der Laracon EU in Amsterdam. Auch wir planen bereits Events und Meetups für das kommende, die die Gelegenheit zum persönlichen Austausch bieten.

Kein Meetup mehr

verpassen

jetzt beitreten