DEV Community: Brent Roose

PHP 8.1 in 8 code blocks

Brent Roose — Sun, 07 Nov 2021 00:00:00 +0000

enum Status
{
    case draft;
    case published;
    case archived;

    public function color(): string
    {
        return match($this) 
        {
            Status::draft => 'grey',   
            Status::published => 'green',   
            Status::archived => 'red',   
        };
    }
}

Enums

class PostData
{
    public function __construct(
        public readonly string $title,
        public readonly string $author,
        public readonly string $body,
        public readonly DateTimeImmutable $createdAt,
        public readonly PostState $state,
    ) {}
}

Readonly properties

class PostStateMachine
{
    public function __construct(
        private string $state = new Draft(),
    ) {
    }
}

New in initializers

$fiber = new Fiber(function (): void {
    $valueAfterResuming = Fiber::suspend('after suspending');

    // … 
});

$valueAfterSuspending = $fiber->start();

$fiber->resume('after resuming');

Fibers, a.k.a. "green threads"

Do you want to learn more about PHP 8.1? There's The Road to PHP 8.1. For the next 10 days, you'll receive a daily email covering a new and exiting feature of PHP 8.1; afterwards you'll be automatically unsubscribed, so no spam or followup. Subscribe now!

$array1 = ["a" => 1];

$array2 = ["b" => 2];

$array = ["a" => 0, ...$array1, ...$array2];

var_dump($array); // ["a" => 1, "b" => 2]

Array unpacking also supports string keys

function foo(int $a, int $b) { /* … */ }

$foo = foo(...);

$foo(a: 1, b: 2);

First class callables

function generateSlug(HasTitle&HasId $post) {
    return strtolower($post->getTitle()) . $post->getId();
}

Pure intersection types

$list = ["a", "b", "c"];

array_is_list($list); // true

$notAList = [1 => "a", 2 => "b", 3 => "c"];

array_is_list($notAList); // false

$alsoNotAList = ["a" => "a", "b" => "b", "c" => "c"];

array_is_list($alsoNotAList); // false

The new array_is_list function

What's new in PHP 8.1

Brent Roose — Fri, 29 Jan 2021 00:00:00 +0000

PHP 8.1 is currently is active development and will probably be release somewhere around the end of November 2021. We already know some of the features, changes and deprecations, so let's go through them one by one.

Do you want to stay up-to-date about PHP 8.1's development? Subscribe to my newsletter and receive occasional updates:

New features

As with every release, PHP 8.1 adds some nice new features. Keep in mind that this list will grow over the year. I'm also listing features that haven't been implemented yet but that make a good chance of ending up in the language. I'll make sure to always mark those features.

Array unpacking with string keys

Array unpacking was already allowed in PHP 7.4, but it only worked with numeric keys. The reason string keys weren't supported before is because there wasn't any consensus on how to merge array duplicates. The RFC cleanly solves this by following the semantics of array_merge:

$array1 = ["a" => 1];

$array2 = ["b" => 2];

$array = ["a" => 0, ...$array1, ...$array2];

var_dump($array); // ["a" => 1, "b" => 2]

New `array_is_list` function

You've probably had to deal with this once in a while: determine if an array's keys are in numerical order, starting form index 0. Just like json_encode decides whether an array should be encoded as an array or object.

PHP 8.1 adds a built-in function to determine whether an array is a list with those semantics, or not:

$list = ["a", "b", "c"];

array_is_list($list); // true

$notAList = [1 => "a", 2 => "b", 3 => "c"];

array_is_list($notAList); // false

$alsoNotAList = ["a" => "a", "b" => "b", "c" => "c"];

array_is_list($alsoNotAList); // false

Explicit octal integer literal notation

You can now use 0o and 0O to denote octal numbers. The previous notation by prefixing a number with 0 still works as well.

016 === 0o16; // true
016 === 0O16; // true

Enums

This RFC is still under discussion.

Even though there hasn't been a vote yet, this proposal to add enums has been received with enthusiasm. If you're unsure about the value they add, you can read about them here.

Adding enums would be a significant improvement in PHP, so I'm for one am very much looking forward seeing this RFC further evolve. To give you a quick preview of what they would look like, here's a code sample:

enum Status {
  case Pending;
  case Active;
  case Archived;
}

And this is how they would be used:

class Post
{
    public function __construct(
        private Status $status = Status::Pending;
    ) {}

    public function setStatus(Status $status): void
    {
        // …
    }
}

$post->setStatus(Status::Active);

Breaking changes

While PHP 8.1 is a minor version, there will be some changes that might technically be a breaking change, and deprecations as well. Let's discuss them one by one.

Restrict `$GLOBALS` usage

A small change to how $GLOBALS is used will have a significant impact on the performance of all array operations. Nikita does a fine job explaining the problem and solution in the RFC. The change means that some edge cases aren't possible to do anymore with $GLOBALS. "What is no longer supported are writes to $GLOBALS taken as a whole. All of the following will generate a compile-time error":

$GLOBALS = [];
$GLOBALS += [];
$GLOBALS =& $x;
$x =& $GLOBALS;
unset($GLOBALS);

On top of that, passing $GLOBALS by reference will generate a runtime error:

by_ref($GLOBALS); // Run-time error

Nikita analysed the top 2000 packages on packagist, and only found 23 cases that will be affected by this change. We can conclude the impact of this — technically breaking — change will be low, which is why internals decided to add it in PHP 8.1. Remember that most of us will win by this change, given the positive performance impact it has everywhere in our code.

Deprecate passing null to non-nullable arguments of internal functions

This change is simple: internal functions currently accept null for arguments that are non-nullable, this RFC deprecates that behaviour. For example, this is currently possible:

str_contains("string", null);

In PHP 8.1, these kinds of errors will throw a deprecation warning, in PHP 9 they will be converted to type errors.

That's it for now, keep in mind I'll regularly update this post during the year, so make sure to subscribe if you want to be kept in the loop. Are you exited for PHP 8.1? Let me know on Twitter!

What a good PR looks like

Brent Roose — Fri, 02 Oct 2020 00:00:00 +0000

It's Hacktoberfest, your chance to contribute to open source and win a t-shirt while at it! Being an open source maintainer myself, I find it a great initiative, but it comes with responsibility as well. Many people try to be smart and send low-effort, borderline-spam PRs, essentially ruining a maintainer's day.

So to help maintainers and contributors in creating quality open source, here are a few tips!

# Start by looking at existing issues and PRs

Even though most PRs are well meant, it's important to first look around the repo for existing issues or PRs addressing the same problem. Someone else might already be working on a similar PR or there might be issues preventing the PR from being made. If you want to help out, start by participating in the discussions already happening, instead of working on your own.

# Discuss first

If nothing has been said about your feature, it might be a good idea to discuss it first, instead of going ahead and potentially changing hundreds of lines of code. I'll be the one who has to maintain your PR for the foreseeable future, so it's best to first discuss it with me! I can probably give you some tips about the code base, as well as tell you about our expectations regarding implementation.

You can choose to open an issue first, or submit a draft PR with a minimal implementation, a proof of concept. I actually really like those draft PRs: it visualises what you want to change, but also indicates that you realise there's more work to do.

# Follow the style guide

Speaking of expectations, check whether the repository you're committing to has any code style guide or linter set up. Follow those rules. Don't submit a PR that deliberately uses other styling rules. You're submitting code to another codebase, and that style guide has to be followed.

A note to maintainers: you can help out here by using GitHub actions to automatically run your linters on PRs.

# Document your PR

I'm going to review your code, so I'd like it to be as clear as possible. This starts by writing clean code: using proper variable names, maybe even add a doc block here and there; but it's equally important to explain your thought process as well. You could use review comments to clarify specific parts of the code, or you could add some general comments in the PR.

# Clean commits

Please try to avoid "wip" commit messages, please? You don't have to write a book for every commit, and I realise that you might not want to think about them while in the zone; but something like "Refactor XX to YY" is already infinitely better than "wip". If you really want a good commit message, try to have your commits only do one thing, and try to explain why this commit is necessary.

# Only relevant changes

Only submit changes that are relevant within the scope of the PR. You might be tempted to fix another thing or two while at it — and you're allowed to — but keep those changes in a separate PR.

You can always base a new branch on your PR branch if necessary, and mention in the second PR that it depends on the first one to be merged. I'm happy to merge them for you, in the right order.

# Be patient

It might take a while for maintainers to merge your PR. I even confess to have lost track of a few PRs over the past years. A friendly "bump" after a few days is always appreciated, but it still might take some time. Remember that most OSS maintainers are doing this on a voluntary basis, so don't be mad when a PR takes a little longer to merge.

# Be friendly

This goes for both maintainers and contributors: don't be a jerk. Sometimes a PR gets declined, sometimes a maintainers looses their patience. Stop and breath, realise it's not the end of the world and move on. Be friendly and respectful.

# Don't wait too long to tag

This one is for the maintainers: one of the most frustrating things is a PR getting accepted, and than having to wait another month for a release to be tagged. You shouldn't be afraid of high version numbers, that's what semver is for. Tag the release as soon as possible, and please don't wait another week!

Do you have any more tips? Let them know via Twitter or email. Here's already another good read by my Colleague Sebastian, on how to write a good issue.

PHP 8: before and after

Brent Roose — Mon, 20 Jul 2020 00:00:00 +0000

It's only a few months before PHP 8 will be released, and honestly there are so many good features. In this post I want to share the real-life impact that PHP 8 will have on my own code.

# Events subscribers with attributes

I'm going to try not to abuse attributes, but I think configuring event listeners is an example of an annotation I'll be using extensively.

You might know that I've been working on event sourced systems lately, and I can tell you: there's lots of event configuration to do. Take this simple projector, for example:

// Before

class CartsProjector implements Projector
{
    use ProjectsEvents;

    protected array $handlesEvents = [
        CartStartedEvent::class => 'onCartStarted',
        CartItemAddedEvent::class => 'onCartItemAdded',
        CartItemRemovedEvent::class => 'onCartItemRemoved',
        CartExpiredEvent::class => 'onCartExpired',
        CartCheckedOutEvent::class => 'onCartCheckedOut',
        CouponAddedToCartItemEvent::class => 'onCouponAddedToCartItem',
    ];

    public function onCartStarted(CartStartedEvent $event): void
    { /* … */ }

    public function onCartItemAdded(CartItemAddedEvent $event): void
    { /* … */ }

    public function onCartItemRemoved(CartItemRemovedEvent $event): void
    { /* … */ }

    public function onCartCheckedOut(CartCheckedOutEvent $event): void
    { /* … */ }

    public function onCartExpired(CartExpiredEvent $event): void
    { /* … */ }

    public function onCouponAddedToCartItem(CouponAddedToCartItemEvent $event): void
    { /* … */ }
}

PHP 7.4

There are two benefits attributes will give me:

Event listener configuration and handlers are put together, I don't have to scroll to the top of the file to know whether a listener is configured correctly.
I don't have to bother anymore writing and managing method names as strings: your IDE can't autocomplete them, there's no static analysis on typos and method renaming doesn't work.

Luckily, PHP 8 solves these problems:

class CartsProjector implements Projector
{
    use ProjectsEvents;

    @@SubscribesTo(CartStartedEvent::class)
    public function onCartStarted(CartStartedEvent $event): void
    { /* … */ }

    @@SubscribesTo(CartItemAddedEvent::class)
    public function onCartItemAdded(CartItemAddedEvent $event): void
    { /* … */ }

    @@SubscribesTo(CartItemRemovedEvent::class)
    public function onCartItemRemoved(CartItemRemovedEvent $event): void
    { /* … */ }

    @@SubscribesTo(CartCheckedOutEvent::class)
    public function onCartCheckedOut(CartCheckedOutEvent $event): void
    { /* … */ }

    @@SubscribesTo(CartExpiredEvent::class)
    public function onCartExpired(CartExpiredEvent $event): void
    { /* … */ }

    @@SubscribesTo(CouponAddedToCartItemEvent::class)
    public function onCouponAddedToCartItem(CouponAddedToCartItemEvent $event): void
    { /* … */ }
}

PHP 8

# Static instead of doc blocks

A smaller one, but this one will have a day-by-day impact. I often find myself still needing doc blocks because of two things: static return types en generics. The latter one can't be solved yet, but luckily the first one will in PHP 8!

When I'd write this in PHP 7.4:

/**
 * @return static
 */
public static function new()
{
    return new static();
}

PHP 7.4

I'll now be able to write:

public static function new(): static
{
    return new static();
}

PHP 8

# DTO's, property promotion and named arguments

If you read my blog, you know I wrote quite a bit about the use of PHP's type system combined with data transfer objects. Naturally, I use lots of DTOs in my own code, so you can image how happy I am, being able to rewrite this:

class CustomerData extends DataTransferObject
{
    public string $name;

    public string $email;

    public int $age;

    public static function fromRequest(
        CustomerRequest $request
    ): self {
        return new self([
            'name' => $request->get('name'),
            'email' => $request->get('email'),
            'age' => $request->get('age'),
        ]);
    }
}

$data = CustomerData::fromRequest($customerRequest);

PHP 7.4

As this:

class CustomerData
{
    public function __construct(
        public string $name,
        public string $email,
        public int $age,
    ) {}
}

$data = new CustomerData(...$customerRequest->validated());

PHP 8

Note the use of both constructor property promotion, as well as named arguments. Yes, they can be passed using named arrays and the spread operator!

# Enums and the match expression

Do you sometimes find yourself using an enum with some methods on it, that will give a different result based on the enum value?

/**
 * @method static self PENDING()
 * @method static self PAID()
 */
class InvoiceState extends Enum
{
    private const PENDING = 'pending';
    private const PAID = 'paid';

    public function getColour(): string
    {
        return [
            self::PENDING => 'orange',
            self::PAID => 'green',
        ][$this->value] ?? 'gray';   
    }
}

PHP 7.4

I would argue that for complexer conditions, you're better off using the state pattern, yet there are cases where an enum does suffice. This weird array syntax already is a shorthand for a more verbose conditional:

/**
 * @method static self PENDING()
 * @method static self PAID()
 */
class InvoiceState extends Enum
{
    private const PENDING = 'pending';
    private const PAID = 'paid';

    public function getColour(): string
    {
        if ($this->value === self::PENDING) {
            return 'orange';
        }

        if ($this->value === self::PAID) {
            return 'green'
        }

        return 'gray';
    }
}

PHP 7.4 — alternative

But with PHP 8, we can use the match expression instead!

/**
 * @method static self PENDING()
 * @method static self PAID()
 */
class InvoiceState extends Enum
{
    private const PENDING = 'pending';
    private const PAID = 'paid';

    public function getColour(): string
    {
        return match ($this->value) {
            self::PENDING => 'orange',
            self::PAID => 'green',
            default => 'gray',
        };
}

PHP 8

# Union types instead of doc blocks

When I mentioned the static return type before, I forgot another use case where docblock type hints were required: union types. At least, they were required before, because PHP 8 supports them natively!

/**
 * @param string|int $input
 *
 * @return string 
 */
public function sanitize($input): string;

PHP 7.4

public function sanitize(string|int $input): string;

PHP 8

# Throw expressions

Before PHP 8, you couldn't use throw in an expression, meaning you'd have to do explicit checks like so:

public function (array $input): void
{
    if (! isset($input['bar'])) {
        throw BarIsMissing::new();
    }

    $bar = $input['bar'];

    // …
}

PHP 7.4

In PHP 8, throw has become an expression, meaning you can use it like so:

public function (array $input): void
{
    $bar = $input['bar'] ?? throw BarIsMissing::new();

    // …
}

PHP 8

What's your favourite PHP 8 feature?

Don't write your own framework

Brent Roose — Sat, 13 Jun 2020 00:00:00 +0000

We were sitting with 5 or 6 backend developers around the large meeting table. It was 10 in the morning on a Monday, and we were all silently working on our laptops. There was a hasty atmosphere, and everyone tried to concentrate on the task ahead.

Less than 2 hours before, I walked into the office, not yet aware of any harm. I was immediately called to the meeting room at the back, there was no time to sit at my desk. Still I quickly grabbed a coffee, and went to the back where a few other colleagues already gathered.

With them was our boss, a nice guy; there wasn't any "upper management" culture or anything, we were just colleagues. The other people in the room already knew what was going on, so he explained to me personally.

There was a bug, in our in-house framework.

"It sure isn't the first one" — I remember thinking.

At this point we'd used this custom-built framework for several years; 200 websites were affected, more or less.

The bug was a stupid mistake — after all, which bug isn't?

Our framework router would take a URL and filter out repeated slashes, so //admin would become /admin. This is, I believe, part of some HTTP spec; at least I was told so, I never double checked. The problem however, was in the authorisation layer: /admin was a protected URL, but //admin was not. So the router would resolve //admin and all its underlying pages to the admin section, and the authoriser wouldn't recognise it as a location you'd need admin privileges for.

In other words: the admin section of all our websites could be entered without any login, by simply replacing /admin with //admin.

I don't remember drinking my coffee after that.

So we did the only thing we could do: manually update all of our websites, some running a very outdated version of our framework. It took us 3 days to do this with 5 or 6 developers. You can do the math on how much it cost.

In the end we never actually got to know whether the bug had been exploited: it was discovered by accident by one of our colleagues over the weekend, and we didn't keep access logs longer than a few days. So nobody could tell whether someone had unauthorised access to one of our sites over the past years; let alone know if, and which data had been leaked.

Don't write your own framework, at least not when you're building websites for paying clients; who trust your work to be professional and secure. Whatever framework you use, make sure it's backed by a large community.

The latest PHP version

Brent Roose — Wed, 03 Jun 2020 04:44:46 +0000

It seems like a simple question with a simple answer: the latest PHP version currently is PHP 7.4. However! If you want to know more inside information about how PHP's lifecycle is managed, keep on reading!

Levels of support

PHP versions are grouped in three levels of support: active, security fixes only and end of life. The "end of life" versions should be avoided at all costs, usually a version goes into the "end of life" phase after three years. A year before that, it goes into the "security fixes only" phase, where only the most needed security fixes are released, and no more other improvements or bug fixes.

These are the currently active supported PHP versions:

PHP 7.2	Security fixes until November 30, 2020
PHP 7.3	Active support until December 6, 2020
PHP 7.4 (current)	Active support until November 28, 2021

This release cycle guarantees that, usually, only three versions of PHP are supported at any given time, with only two being actively supported.
I say usually because PHP 5.6 had a year extra of security fixes support, but that has also ended now: PHP 5.6 was supported up until December 31, 2018.

A look at the past

So, if you're not running PHP 7.2, 7.3 or 7.4, you're running a version that won't receive any updates anymore. At least none from the official PHP developers. There are in fact companies still working independently on old PHP versions like PHP 5.6.

These initiatives of course only exist because there's a need for them: PHP 5.6 is somewhat the Windows XP of the PHP world: it was such a popular release at the time, and many older projects aren't able to deal with the breaking changes the new major version of PHP brings. As a sidenote: the new PHP version after PHP 5.6 is PHP 7 and 6 was skipped; but that's a story for another day.

The PHP 5.* era was the one that set PHP on a course for maturity, a path that would be continued in the 7.* versions, and one that has proven itself over the past years: PHP's performance increased significantly compared to the 5.* versions, the rich community only, and the language syntax and type system kept evolving towards a modern day language.

Obviously PHP bears the consequences of more than 26 years of legacy with it, but in that time it has also proven itself to be a robust and stable language, despite its reputation.

About that reputation — PHP is still looked down upon by many who don't know the modern language — PHP is quite a good language these days. Yes, it carries its battle scars, and we'd wish for many legacy things to just go away, but overall it's quite a nice tool; one that has proven itself time and time again.

These days, the core teams keeps a consistent release cycle: one new release every year, and every 4 or 5 years a new major release. And there are exiting times to come: 2020 will be the year of the new major release, since PHP 8 is coming by the end of the year!

Every new release is done in stages: the last months before the general availability — GA, or simply the release — is focused on testing all the new features and changes. First there are couple of alpha releases, followed by beta releases, followed by release candidates, followed by the final release: GA.

During the alpha phase, new features are still allowed to be added. But once in beta, the final form of the new version has been decided on.

These features, by the way, are decided upon by a core committee who votes on RFCs, which stands for request for comments. These RFCs describe a feature or a change to the language, and are discussed in depth. Everyone is allowed to make RFCs if they want to, but RFCs are of course critically looked at.

PHP 8 is still in the RFC phase, so things are still changing, but not for long anymore! This is the timeline of alpha, beta, RCs and GA, it looks like this:

Alpha 1	June 18, 2020
Alpha 2	July 2, 2020
Alpha 3	July 16, 2020
Feature freeze	July 28, 2020
Beta 1	July 30, 2020
Beta 2	August 13, 2020
Beta 3	August 27, 2020
Release candidate 1	September 10, 2020
Release candidate 2	September 24, 2020
Release candidate 3	October 8, 2020
Release candidate 4	October 22, 2020
Release candidate 5	November 5, 2020
Release candidate 6	November 19, 2020
General availability	December 3, 2020

As you can see, we're closing in on the first alpha releases.

It is possible by the way, for the dates to shift a little bit still, this will depend on how testing goes early on. Speaking of testing: everyone is allowed to do so, it's even encouraged to try stuff out in your own projects, so that enough feedback can be provided to the core team on time.

I told you there was more to PHP's release cycle than just one active version 😁. My advice for modern-day projects would be this: always make sure to update at the latest a few months after GA. Don't lack behind 2 or 3 versions, or even worse: be stuck in PHP 5 land.

The updates actually never were that much of a pain, and there's so much to gain: performance improvements, security benefits, new syntax, wider community support. So keep that in mind, and let's look forward to PHP 8!

PHP 8 in 8 code blocks

Brent Roose — Fri, 15 May 2020 00:00:00 +0000

PHP 8 brings lots of new features, in this list we'll look at the most outstanding ones. If you want a full list and background information, you can read about all things new in PHP 8.

use \Support\Attributes\ListensTo;

class ProductSubscriber
{
    <<ListensTo(ProductCreated::class)>>
    public function onProductCreated(ProductCreated $event) { /* … */ }

    <<ListensTo(ProductDeleted::class)>>
    public function onProductDeleted(ProductDeleted $event) { /* … */ }
}

Attributes — aka annotations — you can about them in depth in this post.

public function foo(Foo|Bar $input): int|float;

public function bar(mixed $input): mixed;

Union types allows for type hinting several types. There's also a new mixed type which represents several types at once.

interface Foo
{
    public function bar(): static;
}

The static return type is built-in.

[JIT]
opcache.jit=5

The just-in-time compiler for PHP.

$triggerError = fn() => throw new MyError();

$foo = $bar['offset'] ?? throw new OffsetDoesNotExist('offset');

throw can be used in expressions.

try {
    // Something goes wrong
} catch (MySpecialException) {
    Log::error("Something went wrong");
}

Non-capturing catches: no need to specify an exception variable if you don't need it.

public function(
    string $parameterA,
    int $parameterB,
    Foo $objectfoo,
) {
    // …
}

Trailing commas are allowed in parameter lists

str_contains('string with lots of words', 'words');

str_starts_with('haystack', 'hay');

str_ends_with('haystack', 'stack');

New string functions.

Let's not fool ourselves: 8 code blocks isn't enough to summarise all great new things in PHP 8. If you want a full list, you can find it on my blog.

What feature are you looking forward to the most? Let me know on Twitter or via email.

Combining event sourcing and stateful systems

Brent Roose — Tue, 14 Apr 2020 00:00:00 +0000

In this two-part series, my colleague Freek and I will discuss the architecture of a project we're working on. We will share our insights and answers to problems we encountered along the way. This part will be about the design of the system, while Freek's part will look at the concrete implementation.

Let's set the scene.

This project is one of the larger ones we've worked on. In the end it will serve hundreds of thousands of users, it'll handle large amounts of financial transactions, standalone tenant-specific installations need to be created on the fly.

One key requirement is that the product ordering flow — the core of the business — can be easily reported on, as well as tracked throughout history.

Besides this front-facing client process, there's also a complex admin panel to manage products. Within this context, there's little to no need for reporting or tracking history of the admin activities; the main goal here is to have an easy-to-use product management system.

I hope you understand that I deliberately am keeping these terms a little vague because obviously this isn't an open-source project, though I think the concepts of "product management" and "orders" is clear enough for you to understand the design decisions we've made.

Let’s first discuss an approach of how to design this system based on my Laravel beyond CRUD series.

In such a system there would probably be two domain groups: Product and Order, and two applications making use of both these domains: an AdminApplication and a CustomerApplication.

A simplified version would look something like this:

Having used this architecture successfully in previous projects, we could simply rely on it and call it a day. There are a few downsides with it though, specifically for this new project: we have to keep in mind that reporting and historical tracking are key aspects of the ordering process. We want to treat them as such in our code, and not as a mere side effect.

For example: we could use our activity log package to keep track of "history messages" about what happened with an order. We could also start writing custom queries on the order and history tables to generate reports.

However, these solutions only work properly when they are minor side effects of the core business. In this case, they are not. So Freek and I were tasked with figuring out a design for this project that made reporting and historical tracking an easy-to-maintain and easy-to-use, core part of the application.

Naturally we looked at event sourcing, a wonderful and flexible solution that fulfills the above requirements. Nothing comes for free though: event sourcing requires quite a lot of extra code to be written in order to do otherwise simple things. Where you'd normally have simple CRUD actions manipulating data in the database, you now have to worry about dispatching events, handling them with projectors and reactors, always keeping versioning in mind.

While it was clear that an event sourced system would solve many of the problems, it would also introduce lots of overhead, even in places where it wouldn't add any value.

Here's what I mean with that: if we decide to event source the Orders module, which relies on data from the Products module, we also need to event source that one, because otherwise we could end up with an invalid state. If Products weren't event sourced, and one was deleted, we'd couldn't rebuild the Orders state anymore, since it's missing information.

So either we event source everything, or find a solution for this problem. You can read about it here.

Benchmarking preloading in PHP 7.4

Brent Roose — Fri, 10 Jan 2020 11:10:50 +0000

I've decided to benchmark PHP's new preloading feature on one of my real-life projects. These are the results:

You can read about the benchmarking process on my blog: https://stitcher.io/blog/php-preload-benchmarks.

Laravel beyond CRUD

Brent Roose — Wed, 16 Oct 2019 00:00:00 +0000

00. Preface
01. Domains
02. Working with data
03. Actions: coming next week
04. Models: coming soon
More chapters are in the making

Preface

A book for PHP developers working on larger-than-average Laravel projects

I've been writing and maintaining several larger-than-average web applications for years now. These are projects that take a team of developers to work on it for at least a year, often times longer. They are projects that take more than the well-known Laravel CRUD approach to stay maintainable.

In this time I've looked at several architectures which would help me and our team improve the maintainability of these projects, as well as help make the development more easy, both for us and our clients: DDD, Hexagonal Architecture, Event Sourcing.

Because most of these projects were large, yet not ginormous, these paradigms as a whole were almost always overkill. On top of that were we still dealing with fixed deadlines, meaning we couldn't spend ages on fine tuning the architecture.

In general, these were projects with a development lifespan of six months to one year, with a team of three to six developers working on them simultaneously. After going live, most of these projects are still heavily worked on for years to come.

In this book, I'll write about the knowledge we gained over the years in designing these projects. I will take a close look at the "Laravel way", and what did and didn't work for us.This book is for you if you're dealing with these larger Laravel projects, and want practical and pragmatic solutions in managing it.

I will talk about theory, patterns and principles, though everything will be in context of a real-life, working web application.

The goal of this book is to hand you concrete solutions to real life problems, things you can start doing different in your projects today. Enjoy!

About me

My name is Brent, I'm a 25-year old web developer living in Belgium. I've been writing PHP professionally for the past 5 years, and have been programming since I was 13 years old.

As a professional, I've mainly worked on medium- to large sized web applications and APIs. Right now I work with Laravel at a company called Spatie, and before that I worked with both Symfony and company-specific frameworks.

A letter to the PHP team

Brent Roose — Wed, 28 Aug 2019 00:00:00 +0000

I've taken the time to write a letter to the PHP core developers; addressing, what I think are, some serious issues holding PHP back.

I've addressed two main concerns

The fear of breaking backwards compatibility
How communication between the core- and userland developers is flawed

You can read my letter on my blog: https://stitcher.io/blog/a-letter-to-the-php-team

Preloading in PHP 7.4

Brent Roose — Thu, 04 Jul 2019 00:00:00 +0000

PHP 7.4 adds preloading support, a feature that could improve the performance of your code significantly.

In a nutshell, this is what preloading is about:

In order to preload files, you need to write a custom PHP script
This script is executed once on server startup
All preloaded files are available in memory for all requests
Changes made to the source file won't have any effect, until the server is restarted

Let's look at it in depth.

Opcache, but more

While preloading is built on top op opcache, it's not exactly the same. Opcache will take your PHP source files, compile it to "opcodes", and store those compiled files on disk.

You can think of "opcodes" as a low-level representation of your code, that can be easily interpreted at runtime. So opcache skips the translation step between your source files and what the PHP interpreter actually needs at runtime. A huge win!

But, there's more to be gained. Opcached files don't know about other files. If you've got a class A extending from class B, you'd still need to link them together at runtime. Furthermore, opcache performs checks to see whether the source files were modified, and will invalidate its caches based on that.

So this is where preloading comes into play: it will not only compile source files to opcodes, but also link related classes, traits and interfaces together. It will then keep this "compiled" blob of runnable code — that is: code usable by the PHP interpreter — in memory.

When a request arrives at the server, it can now use parts of the codebase that were already loaded in memory, without any overhead.

So, what "parts of the codebase" are we talking about? Continue to read on https://stitcher.io/blog/preloading-in-php-74.

DEV Community: Brent Roose

PHP 8.1 in 8 code blocks

What's new in PHP 8.1

New features

Array unpacking with string keys

New array_is_list function

Explicit octal integer literal notation

Enums

Breaking changes

Restrict $GLOBALS usage

Deprecate passing null to non-nullable arguments of internal functions

What a good PR looks like

# Start by looking at existing issues and PRs

# Discuss first

# Follow the style guide

# Document your PR

# Clean commits

# Only relevant changes

# Be patient

# Be friendly

# Don't wait too long to tag

PHP 8: before and after

# Events subscribers with attributes

# Static instead of doc blocks

# DTO's, property promotion and named arguments

# Enums and the match expression

# Union types instead of doc blocks

# Throw expressions

Don't write your own framework

The latest PHP version

Levels of support

A look at the past

PHP 8 in 8 code blocks

Combining event sourcing and stateful systems

Benchmarking preloading in PHP 7.4

Laravel beyond CRUD

Preface

About me

A letter to the PHP team

Preloading in PHP 7.4

Opcache, but more

New `array_is_list` function

Restrict `$GLOBALS` usage