Laracon 2024: Mateus Guimaraes: Behind Laravel Octane

Mateus Guimaraes brought a deep-dive through how Laravel Octane can massively improve performance of your apps.

Main benefits:

  • Reduced latency by eliminating the framework boot step on every request
  • Increased performance
  • Lower cost by reducing CPU usage

Aaron Francis asked a followup question about which driver is best:

None of the apps I’m currently working on need this level of performance (yet) but I’d be interested to try Octane to see how it could improve performance even now.

One more note: Octane can run multiple processes concurrently to save time during a request:

<?php

use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Route;
use Laravel\Octane\Facades\Octane;

Route:: get('foo', function () {
    Octane::concurrently([
        fn () => DB::select('SELECT * WHERE SLEEP(1)'),
        fn () => DB::select('SELECT * WHERE SLEEP(1)'),
        fn () => DB::select('SELECT * WHERE SLEEP(1)'),
    ]);

    return ['foo' => 'bar'];
});

Laracon 2024: Philo Hermans: Livewire Beyond the Basics

Philo Hermans went deep into Livewire optimizations in his talk. A couple of key takeaways:

If your Livewire component calls an action that doesn’t need to re-render anything, you can skip re-rendering by using the [Renderless] attribute. I think I can find some immediate use cases for this.

For high-traffic apps with read replica databases, the sticky option can help guarantee consistency immediately after writes.

Optimistic UIs can improve perceived efficiency: use wire:loading.remove to immediately remove an element before the server round-trip has completed, so the app feels more snappy. I think I could also improve some UIs using this trick.

Laracon 2024: Luke Downing: Lessons From the Framework

Luke Downing gave a great talk about lessons you can learn from the framework.

He took us line-by-line through routes/web.php (from the app structure prior to Laravel 11), explaining all the things you can learn from that file:

  • Authorization: the app has users, allows registration and login, etc. and uses one of the Laravel authentication starter kits
  • Model relationships: nested resource routes indicate that other models belong to users, and while the public can view models, only users can edit them
  • and more

I’ve found the routes files to be extremely helpful in my day-to-day development. In fact, I usually add the routes file as a pinned tab in VS Code so it’s always open (depending on the app, sometimes web.php, sometimes api.php, and sometimes both).

Some quotes from the talk:

Ordinary and obvious, not clever and convoluted.

The more obvious and clear your code is, the easier it is to spot and prevent bugs, and the simpler it is to come back to it later.

Know the rules and when to break them.

e.g., using facades for simpler testing, instead of the “right way” of dependency injection

Laracon 2024: Nuno Maduro: Pest 3

In his talk, Nuno Maduro announced Pest v3, with several new features and no breaking changes.

I know this is pretty exciting to a lot of people, but personally I prefer PHPUnit for several reasons:

  • Better IDE support
    • e.g., in a Pest test, $this->assertDatabaseHas(…) runs without errors, but the IDE thinks it’s invalid because the test file doesn’t extend the base TestCase or inherit any of the parent methods
    • I personally like the discoverability of using a class, as my IDE will suggest available methods.
    • I do think there are some Pest helpers that I haven’t fully used, so those might help alleviate these gripes.
    • Yes, I know that Pest can be used as the test runner, and still use PHPUnit-style classes.
  • Improved VS Code test integration
    • This is the best VS Code extension I’ve found to work with tests in a PHP project. It shows all the tests along with pass/fail results in the sidebar, and I use the keyboard shortcut to run tests all the time.
    • The extension only works with PHPUnit tests, not Pest.
    • However, the upcoming first-party Laravel VS Code extension might change that…

These new features did catch my eye though:

  • Architecture presets: ensure your code follows best practices and conventions; read more here and see the plugin here
  • Mutation testing: let Pest modify parts of your code to ensure it causes failing tests, to ensure your tests are covering what you think they are; see the plugin here

I’ll be taking a look to see if I can use some of the underlying packages with PHPUnit.

All in all, seems like a solid upgrade, but it just doesn’t excite me all that much.