Laravel Founder Taylor Otwell

The participants of the Laravel DACH Meetup had a rare opportunity last week: Laravel founder Taylor Otwell was a guest at the Meetup and answered the questions of the attendees in a Q&A session. Of course, we don't want to withhold the most exciting questions and answers of the evening here. The recording of the entire Meetup is available here.

We are working on a couple things. I build a project that I haven’t released yet called Beep. It is a little different than my other projects. It is not necessarily a developer tool, it is more of a team productivity tool that we model after how we do things here at Laravel. I finished this project back in August, but it has been going through the front-end design process since then. But that is finally done. I have the working app in my hands with the design and everything. What I am doing now, is just going through and putting some final polish on that and adding some final features. I am hoping that I will probably release that at the February 9th Laracon Event. And that is going to be totally open-source project to be used. I am going to host a hosted version of it, but I am also going to open source all of the code so that everyone can read it and learn from it and see how I like to use Laravel when I am building my own applications. It is not an overly complicated application, but it is complicated enough to be useful as a good learning resource. […]

Outside of that we have been getting ready for the PHP 8.1 release which is next month. We had to make some updates to all of our libraries to get ready for that. That is pretty much ready to go.

And then we have also been also working on a refreshed user interface for Laravel Forge which is also far along as well. I think that probably will be released before the end of the year. […]

Laravel 9 will be released in January and has some maintenance related features. For example, in Laravel 9 we replaced Swift Mailer with Symfony Mailer just because Swift Mailer is not going to be updated any longer. […] We will also be upgrading the Flysystem 2.0 from Flysystem 1.0. That just has some minor changes, not anything huge. There are some new features around types in a few places. There is a new query builder interface that lets you type in the query builder interface. But honestly most of the stuff that we have been doing has been going to the current release because we are trying hard not to introduce any breaking changes. The only reason, we would put something in Laravel 9 is if it causes something to break. And because we have been trying to avoid that so much, we have shifted most of every feature we work on to Laravel 8.

Mohamed [Said] is working on a new cast, an Eloquent Model Cast, for Laravel that he has set to Laravel 9 to cast to enums, which is a PHP 8.1 feature. So, you will be able to cast your Eloquent properties to PHP enums. Because PHP is finally getting build-in support for that language feature. And even that may end up going into Laravel 8. […]

I should also note that Laravel 9 also updates to Symfony 6 for our underlying components that we use like Symfony Console, Symfony HttpFoundation which are the two big components that we use at Laravel. […]

[…] We have some libraries that require PHP 8, that’s what Laravel 9 will require as well. By then PHP 8 will have been out for over a year. It has some nice features that we can start to take advantage of. […]

I think Laravel is a good fit for lots of kinds of projects. A lot of times it depends on the skills of the developers involved in the project. […] I think the key is to leverage some of the features that Laravel gives you to make it easier to work with large projects. So, take advantage of all Laravel’s testing capabilities that it offers you so you can make sure your code is well tested! You can also take advantage of tools like larastan which is sort of a Laravel-ready version of PHPStan which gives you good static analysis and tells you for example if you are calling a method that does not exist on an object or passing a wrong type to a method and things like that. Some of the things your IDE [Integrated Development Environment] can tell you but some of the things not. Then there are also some helpful resources out in the community for dealing with large Laravel projects. Spatie has a book called “Laravel beyond Crud” that they have written based on their own experiences with large Laravel projects. And there are patterns you can use to make sure that your code is maintainable and understandable in that context.

I think obviously Laravel has been used in lots of big projects over the last ten years and I think the success of the project is going to depend on the developer team writing the code. There is sort of bad code in all sorts of different languages and frameworks. […] It is not unique to any tool or language. It just depends on the discipline and skill set of the developers involved.

To give some background: Octane is a way to keep your Laravel application in memory in between requests. That is very different than how we typically think of PHP applications working. Usually, every new request to the website triggers the whole framework to run all of its code from start to finish to handle the request. Octane takes a different approach. It is similar to other approaches in other languages like Node, where you boot the application once and load up all the framework stuff into memory and register – in Laravel’s case – all the container bindings, all configurations etc. into memory. When a new request comes in, we receive it, and we just handle it with this already loaded application instance. What it does is essentially eliminate the framework boot overhead of your application so that only your application code is really what is determining your performance. We have sort of eliminated the framework from the equation.

That is of course a huge benefit because your application is going to run much faster. It is also a huge benefit if you persist the data base connection between those requests, so you are not having to close and reopen the database connection for every single request. It saves several milliseconds, it could be as much as 10 or 20 milliseconds off your response time. The downsides would be that you need to be aware that your application is running in memory all the time. So, it is a little easier to create memory leaks if you are not paying attention to that. If you're just adding stuff to the array on every request, that array is just getting bigger and bigger and bigger. […]

Some of the latest things that have been happening with Octane is our Octane support in Laravel Vapor, which is our serverless deployment tool for Laravel. It ships your code to AWS Lambda and is our most scalable deployment platform for Laravel that we have right now. It can handle thousands of requests at the same time. With Octane you are taking advantage of the database connection being open between those requests as well. […]

Other than that, we are continuing to monitor new features in Swoole, which is an underlying PHP extension that is leveraged by Octane. As new features become available in Swoole, we can make them also available in Octane.

I think Octane has been stable and well received. We've received reports that people are using it with a great success both in a Forge context and in a Laravel Vapor context. I think people are enjoying it. […]

The one I use the most is probably Laravel Forge because we have probably 20 or 30 servers managed by Laravel Forge. So as far as the one that I use the most on a daily basis, it's definitely Forge. That is also true for the community. Forge is the biggest product in terms of the number of customers and the number of servers being managed […]. It is of course always going to have a special place for me because it was the first product, the first big commercial tool I wrote for Laravel.

Outside of the framework itself I think Vapor for any future stuff I do. Any future projects I'll probably host on Laravel Vapor because I never have to think about operating system upgrades or SSL certificates or scaling servers or workers at all. It is nice to be able to forget about all that stuff. I also really like the point in time database recovery that you can do right from Laravel Vapor UI. […]

But to answer the question, I would probably say Forge. It is just the one I use the most. The best code base is definitely Laravel Vapor, though. As far as what code am I the proudest of and do I think is most cleanly written it would definitely be Laravel Vapor. That is also because it is the newest, so I had just more experience than. […]

It is always best to do it as early as possible so you can make sure your application is compatible and working well in Vapor. But it is not impossible to move an existing project to Vapor at all. […]

All I can say is that I like to do it as early as possible to make sure things are compatible and working well if I think that it's eventually going to need something at the scale of Laravel Vapor. We are developers, so we usually do assume that our applications need tonnes of scale, but the reality is that most probably don't. If you are not going to need that kind of scale, then of course using something like DigitalOcean or some other VPS [Virtual Private Server] service is going to be much simpler and cheaper as well.

Originally there is just going to be Laravel Jetstream. I was going to break up the back-end and the front-end of that so that if you just wanted an authentication back-end like for example for an SPA [Single Page Application] or something you could use Laravel Fortify. You could look at it like Laravel UI was split into two packages, essentially Laravel Fortify which was the back-end, and then Laravel Jetstream, which was the front-end that used the Laravel Fortify back-end. But you could put any front-end you wanted with Laravel Fortify. That was the idea.

When Laravel Jetstream was released, they got sort of mixed reviews because I think some people found it too complicated compared to Laravel UI. In some ways it is more complicated than Laravel UI. In response to that, I wrote a spiritual successor to Laravel UI, like a next generation of Laravel UI with Laravel Breeze […]. Laravel Breeze is very much like Laravel UI in the sense that all of the code is right there in front of you. It is not really a big package. All it does is copy the views and controllers into place. Then it is totally your code to customise however you want.

I really enjoy Laravel Breeze a lot. I like how simple and straightforward it is. I think that was really a better successor to Laravel UI than Jetstream was. Jetstream is fine and good if you need a little bit more complex behaviour or a more robust project, but Laravel Breeze is probably sufficient for most projects. In hindsight, I might have only released Laravel Breeze if I had done that first.

Regarding Bootstrap to Tailwind: Most of the change there was because we simply weren't using Bootstrap anymore at Laravel for any new development we were only using Tailwind. We weren't sure we really wanted to maintain stuff that we weren't really using ourselves or wouldn't use ourselves as developers for new projects. It felt like Tailwind was more customizable, more flexible in terms of building custom bespoke user interfaces. We just were leaving it in the Community’s hands. If they wanted a Bootstrap version of authentication scaffolding, they could do. When this happened, is we sort of committed to keeping Laravel UI up to date as far as PHP versions go and Laravel versions go. So, we still have been maintaining that ever since, and you can still install it today for example on a Laravel project. It's not really something we're adding new features to, or have any big plans for, because I consider breeze and Jetstream, sort of the current generation of that kind of tool. But we have kept it running for people that like Bootstrap. Again, we just use Tailwind on all of our new stuff like Laravel Vapor is all Tailwind, the Laravel Nova is all Tailwind, so it's just the tool that that we are using here.

I am leaning towards it will be in-person. […] I spoke to a venue in New York earlier this week. […] I do think it would be a smaller event, maybe 400 or 500 people. I guess that is still a pretty good amount of people, but smaller than in 2019 when we had almost 900 people.

Venues in New York as of now do require either vaccination or proof of a negative COVID test, so that will be up to the venue and up to that state here in the United States to decide. But I would like to do it in-person. I think it is just so much fun to do it in-person versus online. Both have their benefits: doing it online so many people can attend where you can have 4000 or 5000 attendees, but it's nice to be able to meet in-person and talk in-person as well. So right now, I'm planning on probably organising an in-person event for the summer. It would probably be in July of 2022.

One opportunity to meet Taylor Otwell in person will be at Laracon EU in Amsterdam on 13-14 January 2022. We are also already planning events and meetups for the coming year, which offer the opportunity for personal exchange.