Forem: Marcel Pociot

Using Laravel Blade components in your layout

Marcel Pociot — Wed, 14 Apr 2021 09:49:24 +0000

Blade Components for your Layout

In the latest blog post I showed you how Laravels Blade view components work and how you can make use of them.
In this part of the series, I want to focus on how we can use these components throughout our application - starting with the very basic: your layout.

In a typical Laravel application, you might have a file called layouts/app.blade.php that all of your other views extend from.

Such a view could look like this:

<!DOCTYPE html>
<html>
    <head>
        @yield('scripts')
    </head>
    <body>
        @yield('content')
    </body>
</html>

And in your actual pages, you will extend that view and provide your content within the content section. Here's an example welcome.blade.php file:

@extends('layouts.app')

@section('scripts')
    <!-- Some JS and styles -->
@endsection

@section('content')
  <div>My Page content is here</div>
@endsection

So far so good, so let's see how we can make use of our newly learned Blade components to refactor this.

First of all, we are going to create a new component called "Layout":

php artisan make:component Layout

Next, we can take all of our existing layout view code and place it inside of our new layout component view:

<!-- /views/components/layout.blade.php -->
<!DOCTYPE html>
<html>
    <head>
        @yield('scripts')
    </head>
    <body>
        @yield('content')
    </body>
</html>

To make this work, the only thing we need to do in our welcome.blade.php file is, instead of extending our layout - we can just wrap all of the content inside of our new layout component, like this:

<x-layout>
    @section('scripts')
        <!-- Some JS and styles -->
    @endsection

    @section('content')
      <div>My Page content is here</div>
    @endsection
</x-layout>

This is already pretty good, but as we have seen in the previous post, Laravel provides a $slot variable that automatically holds all of the content that was placed inside of the blade component tags. So lets go and change our layout to make use of the $slot variable, instead of yielding a content section:

<!-- /views/components/layout.blade.php -->
<!DOCTYPE html>
<html>
    <head>
        @yield('scripts')
    </head>
    <body>
          {{ $slot }}
    </body>
</html>

Instead of using the @section directive, we can now simply pass the data as is:

<x-layout>
    @section('scripts')
        <!-- Some JS and styles -->
    @endsection

  <div>My Page content is here</div>
</x-layout>

Alright - so we got rid of the content section and wrapped everything into our layout component. That's already pretty cool and I think this improves the readability of our view component. Because of the indentation it is immediately clear which layout is being used. This scripts section is still bothering me though. So let's see how we can get rid of this as well - and there are multiple options.

Named Slots

The first option that we have is to make use of a "named slot". We already discussed the $slot variable, that will automatically be populated with everything within the component HTML, but we can also manually specify a slot name. This can be done using the x-slot tag - which itself is sort of a pre-defined Blade component that comes out of the box with Laravel.

By passing a name property to our x-slot, we can make the data available within a variable with the same name as our name attribute.

Let's modify our layout component to make use of a new $scripts variable:

<!-- /views/components/layout.blade.php -->
<!DOCTYPE html>
<html>
    <head>
        {{ $scripts }}
    </head>
    <body>
          {{ $slot }}
    </body>
</html>

To pass this variable to our view, we can now pass it into a scripts slot:

<x-layout>
  <x-slot name="scripts">
        <!-- Some JS and styles -->
  </x-slot>

  <div>My Page content is here</div>
</x-layout>

Refresh the page, and you can see that everything works as expected. With this, we introduced an error though, as our $scripts variable is now mandatory within our layout - so if a view would not provide a scripts slot, you would get an error "Undefined variable: scripts".

While this works with a named slot, we no longer have the ability to append to the scripts section from within multiple of our views/components - because we don't have a real "section" anymore.

So what if we want to get rid of the @section directives and use a component for this instead? First of, lets get our @yield directive back into our layout component:

<!DOCTYPE html>
<html>
    <head>
        @yield('scripts')
    </head>
    <body>
          {{ $slot }}
    </body>
</html>

Alright - now lets see how we can make use of this section, without using a directive.

Renderless Blade components

When you create a custom Blade component, the class has a render method, that by default returns a string containing the name of the view for the given component:

namespace App\View\Components;

use Illuminate\View\Component;

class Alert extends Component
{
    public function render()
    {
        return view('components.alert');
    }
}

There's another way of returning a view though, which is by returning a callable, that is then going to return the actual view. In this case, our component only holds the data/state that was provided for the component, but it doesn't actually return a view - which is great for our section use case.

So lets create a new view component called Section:

php artisan make:component Section

Now instead of returning a view, we are actually going to return a function - that will return the @section directive for us:

namespace App\View\Components;

use Illuminate\View\Component;

class Section extends Component
{
    public function render()
    {
        return function ($componentData) {
            return <<<BLADE
                @section("{$componentData['attributes']->get('name')}")
                    {$componentData['slot']}
                @endsection
            BLADE;
        };
    }
}

Alright - so lets break this render method down line by line.

The render method returns a callable with one parameter - an array holding the component data.
This array has the following data and keys available:

componentName - The name for the component, in our case "section"
attributes - The Illuminate\View\ComponentAttributeBag instance that holds all of our component attributes
slot - A Illuminate\Support\HtmlString object with the string that was passed to the default slot

Inside of this callable, we are returning a string - this string is escaped using PHPs Heredoc Syntax.

Inside of this string, we can now return any Blade code that we want - so in our case, we are opening a @section directive, with the name attribute that was provided in the <x-section tag. Inside of that @section directive, we pass the slot of our component (and cast it to a string, as it's a HtmlString object).
And last but not least, we close the section directive.

To make use of this renderless component, we can now rewrite our page view like this:

<x-layout>
  <x-section name="scripts">
     <!-- Some JS and styles -->
  </x-section>

  <div>My Page content is here</div>
</x-layout>

Yay - we did it! We got rid of our ugly directive and have successfully refactored it to make use of a custom blade component.

Is this better than using the directives? You'll have to decide for yourself - but I hope that this inspired you to take a look at renderless Blade components, as well as how you can use components for your traditional layout extensions.

Exporting Laravel Eloquent to CSV/XLS

Marcel Pociot — Wed, 14 Apr 2021 09:47:53 +0000

Exporting Laravel Models to CSV or XLS

As I was browsing Twitter, the question came up how you could easily export your Eloquent models to CSV or XLS.
There are many possible ways, so let's inspect a couple of those.

Using pure PHP

Yeah, I know - this might definitely not be the simplest solution - but it is always a good idea to know your tools, so we should at least take a brief look at how you can export your models to CSV with no third-party dependency at all.

PHP has a method called fputcsv, which allows you to write an array of data into a file handle. Pretty easy:

// Open a file handle in 'write' mode for
// a file called export.csv
$data = [
    [1, 'Marcel', 'marcel@beyondco.de'],
  [2, 'Sebastian', 'sebastian@beyondco.de'],
];

$handle = fopen('export.csv', 'w');

foreach ($data as $row) {
    fputcsv($handle, $row);
}

fclose($handle);

This is pretty straight forward and simple to use. The resulting CSV file looks like this:

1,Marcel,marcel@beyondco.de
2,Sebastian,sebastian@beyondco.de

If you want to use a ; instead of a comma for the separator, you can pass it as a third argument to the fputcsv method.

Now in the example above, we have only used a static data array for our export - not a collection of models. Making this change is pretty easy too:

$data = User::all();

$handle = fopen('export.csv', 'w');

foreach ($data as $row) {
    fputcsv($handle, $row->toArray(), ';');
}

fclose($handle);

In this example, we export all of our users, load them into a $data variable and then loop over these models to write them to the CSV file. Notice that we are using the $row->toArray() method, because fputcsv expects us to pass an array - not an object.

And this works just fine, here's the resulting CSV for this:

1;Marcel;marcel@beyondco.de;;2021-04-01T06:37:47.000000Z;2021-04-01T06:37:47.000000Z
2;Sebastian;sebastian@beyondco.de;;2021-04-01T06:37:54.000000Z;2021-04-01T06:37:54.000000Z

As you can see, we get more data than in the first example - that's because our models contain more information, such as the created_at and updated_at timestamps. You can also notice an empty value in the CSV export above - that's from the email_verified_at column that ships with Laravel by default, which is NULL in this case.

Alright - so doing this with pure, raw PHP is not as fancy as the usage of a third-party package might be, but its certainly doable. This comes with some flaws though.

Because we have to load all of our models into memory (by stuffing them in our $data variable), this export will use a lot of memory, as your users table grows. An easy fix is the usage of the chunk method. Instead of loading thousands of rows into memory, this method will only receive a subset of Eloquent models and execute a closure with those models, saving a lot of memory.

The fputcsv method rewritten with chunking looks like this:

$handle = fopen('export.csv', 'w');

User::chunk(100, function ($users) use ($handle) {
    foreach ($users as $row) {
        fputcsv($handle, $row->toArray(), ';');
    }
});

fclose($handle);

We create the file handle, and then for a chunk of every 100 users, we put those users into the handle. This way we won't load thousands of users into memory - great!

Third Party Packages

There are a lot of third-party packages out there, that can help you with exporting data to either CSV or Excel. Laravel Excel is the most popular solution for this - by far.
Let's see how we can create our User export with Laravel Excel.

First of all, you need to install the package using composer:

composer require maatwebsite/excel

Next, we can create our first export. Exports are classes that live in your app/Exports folder and they contain all the logic for a given export.

The package comes with an artisan command to create such an Export class for us:

php artisan make:export UsersExport --model=User

Lets take a look at the generated UsersExport class:

namespace App\Exports;

use App\User;
use Maatwebsite\Excel\Concerns\FromCollection;

class UsersExport implements FromCollection
{
    public function collection()
    {
        return User::all();
    }
}

So all that we do in this class, is we provide a collection method that returns the data that should be exported.

To actually call our export from a controller, you can do this:

namespace App\Http\Controllers;

use App\Exports\UsersExport;
use Maatwebsite\Excel\Facades\Excel;

class UsersController extends Controller 
{
    public function export() 
    {
        return Excel::download(new UsersExport, 'users.xlsx');
    }
}

We can use the Excel facade provided by the package, call the download method to instruct the package that we want to invoke a file download, and last but not least give it an instance of our export, as well as the desired file name for the export.

But what about memory usage...

...you might wonder. If our User model would consist of thousands of rows, because we return User::all(), wouldn't we run into memory issues all over again?
Yes - we would. So let's fix this.

Laravel Excel allows us to also export our models from a query, which is then going to handle the chunking for us. We can modify our UsersExport class like this:

namespace App\Exports;

use App\User;
use Maatwebsite\Excel\Concerns\FromCollection;

class UsersExport implements FromCollection
{
    public function query()
    {
        return User::query();
    }
}

This is now simply returning a base query from our User model, which will then be exported.

GUI solutions

While all the above solutions are great if you want to provide a CSV/XLS export from within your application, you sometimes simply need to export a given set of data to CSV or XLS, which you don't actually need inside of your application.

For example:

You're running a SaaS and you want to have an export of the latest invoices that were created - you don't need to do this multiple times, so there's no need to add this to your application
Your boss tells you: "Hey, give me a CSV file with all users that have relation X real quick!"
Any other "one-off" exports that you want to make for yourself/others

For this, the usage of a GUI based tool can be great. Let me show you how you can create a CSV export using Tinkerwell.

Tinkerwell allows you to connect to your local or remote Laravel applications where you can then evaluate any PHP code within the context of your opened application - and there's no need to install a third-party package for this to work.

This means that we can simply evaluate our fputcsv code snippet on any local or remote Laravel application, like this:

In addition to writing this code yourself, you can also make use of Tinkerwell's table mode. This mode gives you a table view of any collection or array that your PHP code evaluates and it then allows you to browse the data, as well as export it to CSV.

Simply press the "Save CSV" button and you're good to go!

Getting fancier

If you prefer an even simpler solution, you can make use of Invoker. Invoker is a desktop application that, just like Tinkerwell, can connect to local or remote Laravel applications and provides you with an instant admin-panel of your Eloquent models, mailables, notifications, and much more.

Inside of Invoker, you can then browse all of your models, filter them by adding additional Eloquent queries, as well as export the results to XLS/CSV with a click of a button.

It doesn't get easier than that.

So we looked at a couple of different ways how we can export our Laravel models to CSV, either by using pure PHP methods, third-party libraries, or GUI tools for one-off exports and easier data-filtering.

Laravel Octane

Marcel Pociot — Wed, 14 Apr 2021 09:30:19 +0000

Laravel Octane - What, How, and Why

Taylor Otwell already showed a glimpse of Laravel's latest open-source package, Octane, during his Laracon Online talk - but today, the new package is available on GitHub for everyone to beta test.

In this blog post, I'm going to explore Laravel Octane and tell you what it is, how you can install and use it, and why you might need it.

Disclaimer: Laravel Octane is still a beta software and should not yet be used in production!

What is Laravel Octane?

Laravel Octane is an open-source package that will boost your Laravel application performance. Laravel Octane requires PHP 8, so if you're still on 7.x, you need to upgrade your PHP version.
Under the hood, Octane makes use of Swoole and RoadRunner - two application servers, that take care of serving and booting up your Laravel application. Why is it faster, you might ask. Let me explain.

With a traditional PHP application that gets served via a webserver like nginx, every incoming request is going to spawn an PHP-FPM worker. This means that each request starts up one individual PHP process, that will run through all the necessary tasks in order to serve that one request.

In the case of Laravel, this means that the Framework needs to be booted, all service providers register their services within the container, all providers get booted themselves, the request goes through a list of middleware classes, hits your controller, a view gets rendered, etc. until we eventually get a response from our server.

With Swoole or RoadRunner in place, we still have a worker for each incoming HTTP request, but they all share the same booted framework. This means that only the first incoming request is going to bootstrap the framework (including all service providers, etc.) while every other request can then make use of a ready-to-go framework. And this is what makes Octane so insanely fast.

Getting started with Laravel Octane

As Laravel Octane is a package, you need to install it as a dependency of your specific application. You can do this via composer:

composer require laravel/octane\

After you installed Octane in your application, make sure to run php artisan octane:install. This is going to publish the Octane configuration file, as well as add rr - the RoadRunner binary, to the .gitignore file.

As I said, Octane is going to publish its configuration file, which looks like this:

return [

    /*
    |--------------------------------------------------------------------------
    | Octane Server
    |--------------------------------------------------------------------------
    |
    | This value determines the default "server" that will be used by Octane
    | when starting, restarting, or stopping your server via the CLI. You
    | are free to change this to the supported server of your choosing.
    |
    */

    'server' => env('OCTANE_SERVER', 'roadrunner'),

    /*
    |--------------------------------------------------------------------------
    | Force HTTPS
    |--------------------------------------------------------------------------
    |
    | When this configuration value is set to "true", Octane will inform the
    | framework that all absolute links must be generated using the HTTPS
    | protocol. Otherwise your links may be generated using plain HTTP.
    |
    */

    'https' => env('OCTANE_HTTPS', false),

    /*
    |--------------------------------------------------------------------------
    | Octane Listeners
    |--------------------------------------------------------------------------
    |
    | All of the event listeners for Octane's events are defined below. These
    | listeners are responsible for resetting your application's state for
    | the next request. You may even add your own listeners to the list.
    |
    */

    'listeners' => [
        WorkerStarting::class => [
            EnsureUploadedFilesAreValid::class,
        ],

        RequestReceived::class => [
            ...Octane::prepareApplicationForNextOperation(),
            ...Octane::prepareApplicationForNextRequest(),
            //
        ],

        RequestHandled::class => [
            //
        ],

        RequestTerminated::class => [
            //
        ],

        TaskReceived::class => [
            ...Octane::prepareApplicationForNextOperation(),
            //
        ],

        TickReceived::class => [
            ...Octane::prepareApplicationForNextOperation(),
            //
        ],

        OperationTerminated::class => [
            FlushTemporaryContainerInstances::class,
            // DisconnectFromDatabases::class,
            // CollectGarbage::class,
        ],

        WorkerErrorOccurred::class => [
            ReportException::class,
            StopWorkerIfNecessary::class,
        ],

        WorkerStopping::class => [
            //
        ],
    ],

    /*
    |--------------------------------------------------------------------------
    | Warm / Flush Bindings
    |--------------------------------------------------------------------------
    |
    | The bindings listed below will either be pre-warmed when a worker boots
    | or they will be flushed before every new request. Flushing a binding
    | will force the container to resolve that binding again when asked.
    |
    */

    'warm' => [
        ...Octane::defaultServicesToWarm(),
    ],

    'flush' => [
        //
    ],

    /*
    |--------------------------------------------------------------------------
    | Garbage Collection Threshold
    |--------------------------------------------------------------------------
    |
    | When executing long-lived PHP scripts such as Octane, memory can build
    | up before being cleared by PHP. You can force Octane to run garbage
    | collection if your application consumes this amount of megabytes.
    |
    */

    'garbage' => 50,

    /*
    |--------------------------------------------------------------------------
    | Maximum Execution Time
    |--------------------------------------------------------------------------
    |
    | (info) 0 means no maximum limit
    |
    */

    'max_execution_time' => 30,

    /*
    |--------------------------------------------------------------------------
    | Octane Cache Table
    |--------------------------------------------------------------------------
    |
    | While using Swoole, you may leverage the Octane cache, which is powered
    | by a Swoole table. You may set the maximum number of rows as well as
    | the number of bytes per row using the configuration options below.
    |
    */

    'cache' => [
        'rows' => 1000,
        'bytes' => 10000,
    ],

    /*
    |--------------------------------------------------------------------------
    | Octane Swoole Tables
    |--------------------------------------------------------------------------
    |
    | While using Swoole, you may define additional tables as required by the
    | application. These tables can be used to store data that needs to be
    | quickly accessed by other workers on the particular Swoole server.
    |
    */

    'tables' => [
        'example:1000' => [
            'name' => 'string:1000',
            'votes' => 'int',
        ],
    ],

];

Next up, you need to decide for yourself wether you want to use RoadRunner, or Swoole. You can then configure the application server that you want to use by customizing the server key in the configuration file. This can either be swoole, or roadrunner.

RoadRunner

RoadRunner is an application server that is written in Go, that does not have any other dependencies within PHP itself. Choose RoadRunner, if you do not want to install additional PHP extensions. You can install RoadRunner through composer, like this:

composer require spiral/roadrunner

Swoole

Swoole comes with a couple of nice benefits, that RoadRunner can not provide. As Swoole is an extension on top of PHP, PHP itself gains some cool new features, such as "ticks" and "coroutines", which I'm going to cover in a bit. These features are not available with RoadRunner, so if you want to make use of them, you should go with Swoole.

You can install the Swoole extension using:

pecl install swoole

During the installation, you will be asked if you want to have support for HTTP2, curl, JSON, and open_ssl within Swoole. You can safely stick to the default values here (which are off) as those settings only affect things like coroutines. You will still be able to use curl, JSON, and everything else.

Starting Octane

Once you have installed RoadRunner or Swoole, and defined it in your octane.php configuration file, you can start Octane and let it serve your Laravel application. The Octane server can be started with:

php artisan octane:start

By default, Octane will start the server on port 8000, so you may access your application in a browser via http://localhost:8000.

So go ahead, visit that route and watch your Laravel application fly!
If you make multiple requests to the app, you can see that the first one is a little bit slower - that's where the framework gets booted, while the other ones are noticeably faster, as they can use the booted framework from memory.

200 GET / .............. 14.23 ms
200 GET / ..............  1.93 ms
200 GET / ..............  2.06 ms

Making code changes

If you now go and make a code change - for example, add a new /test route - and try to hit that URL, you will receive a 404!
And that's because the request is still using the framework (and all of its routes/code) that was booted once you started the Octane server. So in order to see that code change, you need to restart your Octane server.
Because this is super cumbersome to do during development, Octane comes with a nice way to automatically watch your codebase for changes and restart the Octane server automatically.

In order to make this work, make sure to install Chokidar - a NodeJS based file watching library:

npm install --save-dev chokidar

You can then start the Octane server in "watch" mode, like this:

php artisan octane:start --watch

Now the next time you make a change in your codebase, this will be detected, and Octane will restart the workers for the requests and you can immediately see your changes.

Customizing Workers

Speaking of Workers - by default, Octane is going to start one worker for each CPU core that you have. But you can also change this, by passing a --workers option to the octane:start command:

php artisan octane:start --workers=2

Swoole specific features

As I mentioned, Octane comes with a couple of Swoole specific features, so lets take a look at those, as I think they are very interesting.

Concurrent Tasks

Octane allows you to perform multiple tasks concurrently. This means that they will be performed at the same time and will be returned as soon as all tasks finished.

Here's an example taken from the Octane documentation on GitHub:

use App\User;
use App\Server;
use Laravel\Octane\Facades\Octane;

[$users, $servers] = Octane::concurrently([
    fn () => User::all(),
    fn () => Server::all(),
]);

So in this example, we are getting all users and all servers at the same time. To make this clearer, here's another example:

Octane::concurrently([
        function () {
                sleep(0.5);
                return 1;
        },
        function () {
                sleep(1);
                return 2;
        },
    ]);

We are executing two "tasks" concurrently and PHP will continue evaluating the code as soon as both of the tasks are finished. One task waits for 0.5 seconds, the other one waits for 1 second. As they are being evaluated concurrently, in two individual tasks, PHP will wait exactly 1 second (not 1.5) until both results are available.
This feature is a great way to perform multiple smaller tasks simultaneously.

Just like the --workers option, you can also customize the amount of --task-workers that Octane should make available.

Ticks / Intervals

Octane in combination with Swoole, allows you to register ticks - which are operations that will automatically be executed at a given interval. Similar to the setInterval method in JavaScript.
Unfortunately, there's no way to stop those ticks at the moment, but you can register them within your application like this:

Octane::tick('simple-ticker', fn () => ray('Ticking...'))
        ->seconds(10);

The Octane Cache

Another new feature within Octane and Swoole is a new cache driver. This cache driver, according to the official documentation, provides read and write speeds of up to 2 million operations per second. Behind the scenes, Swoole is caching the data in a shared memory using Swoole Tables, which can be accessed across all workers. When the server restarts, the cached data will be flushed though, as the cache is only persisted in memory.

To make use of this cache, you can access it through the octane cache store on the Cache facade, like this:

Cache::store('octane')->put('framework', 'Laravel', 30);

Another cool new addition, that is Swoole and Octane specific is the ability of a "cache interval". This allows you to store information in the Octane cache and refresh the data in a given interval:

use Illuminate\Support\Str;

Cache::store('octane')->interval('random', function () {
    return Str::random(10);
}, seconds: 5)

Octane Tables

Built upon the feature of Swoole Tables, you can create your own tables that you want to access within your Octane applications. These tables have the same performance benefit as a Cache would have, by allowing you to save data in a structured way.
Keep in mind that all data that you store within such a table will be lost when the server restarts though.

To configure a table, you can create an entry in the tables section of your octane.php config file:

'tables' => [
    'example:1000' => [
        'name' => 'string:1000',
        'votes' => 'int',
    ],
],

In this example, we are defining a table called example, which can hold a maximum of 1.000 entries/rows. The structure of this table is a name, which is a string with a maximum length of 1000, and votes, which is an integer.

To write data to this table, we can make use of the Octane::table method:

use Laravel\Octane\Facades\Octane;

Octane::table('example')->set('a-unique-identifier', [
    'name' => 'Marcel Pociot',
    'votes' => 1000,
]);

And to pull out the data, we can use a get method on the table, like this:

return Octane::table('example')->get('a-unique-identifier');

Caveats with Octane

There are a couple of things that you need to watch out for, when you want to either make an existing application ready for Octane, or start building a new application from scratch.

Since Octane holds the framework in memory across all workers, things like all of your applications service providers will only be registered and booted once. While Octane takes care of resetting the state of first-party packages (which includes Inertia), it's not possible for Octane to reset global state that you might have in your own application code.

The official documentation, which currently can be found on GitHub holds some of the most common scenarios that you should watch out for.

Listeners

One feature of Octane that hasn't been documented yet, is the ability to register custom listeners, whenever something happens in the application server within Octane.
You can hook into the following events:

WorkerStarting
RequestReceived
RequestHandled
RequestTerminated
TaskReceived
TickReceived
OperationTerminated
WorkerErrorOccurred
WorkerStopping

To attach listeners to these events, you can add them to your octane.php config file.

Service Warming and Flushing

When a new Octane worker gets booted, you can specify a list of container bindings/services that you want to "warm up" during the boot process. This means that, upon the booting of the worker, the service container will already make the specified services available, so that following requests can immediately access them.

Octane already has a list of internal services that it keeps warm during each worker boot process, but you can add your own services to the warm section of the octane.php config file.

Similar to this, you can also define a list of services that you want to flush, before a new request comes in. This can be useful for services that get manipulated over the course of a request, that you want to reset to its original/unloaded state when a fresh request comes in.

Octane Routes

If Octane does not already grant you enough speed boost, you can even squeeze a little more out of it, by making use of routing built right into Octane.
You can define a custom Octane route through the Octane facade like this:

Octane::route('GET', '/fast', function() {

});

These routes are very fast because they entirely skip Laravels routing system (so these routes do not provide any kind of middleware) - which can be helpful for endpoints that only need to provide data really fast.

Since the HTTP Kernel in Laravel is not being used for these requests, you need to return a Symfony Response object yourself, like this:

use Symfony\Component\HttpFoundation\Response;

Octane::route('GET', '/faster', function() {
    return new Response('Hello from Octane.');
});

All service providers are of course booted and available, so that you can still make use of these services, perform Eloquent queries, etc.

Alright...so why Octane?

Laravel Octane is definitely going to give your Laravel application a big performance boost - and we all love performance boosts, don't we?
Do we actually need this performance boost? Well, maybe - I think it depends on the application that you are running.
But what's more important to me, is the fact that Laravel is (once again) pushing the current state of PHP. Not only is Octane a package that requires at least PHP 8, but it also pushes exciting new features in the PHP world such as coroutines, ticks, and in general the mindset of serving your own application using an artisan command.

I'm excited for the future of Octane!