Freek.dev

On his blog, Mathias Verraes started a series of posts on patterns for decoupling in distributed systems. I'll link to just one of the posts here, but they're all worth your time.

The mind switch is to think of the passage of time as just another Domain Event, exactly like all the other events. After all, if we define a Domain Event as a granular point in time where something happened that is relevant to the business, then certainly the next business day, month, or quarter, is extremely relevant.

Read more [verraes.net]

In an impressive blog post on his blog, React lead developer Dan Abramov, explains how React works on the hood.

This is a deep dive — THIS IS NOT a beginner-friendly post. In this post, I’m describing most of the React programming model from first principles. I don’t explain how to use it — just how it works. It’s aimed at experienced programmers and folks working on other UI libraries who asked about some tradeoffs chosen in React. I hope you’ll find it useful!

React as a UI Runtime

Read more [overreacted.io]

Jonathan Reinink proposes a new take on what Vue's role could be in a server rendered app.

What I have here is a classic server-side app, that uses server-side routing and controllers. There is no API. The controllers lookup the data from the database, and then pass it to the templates. Except, I'm not using any server-side (ie. Blade) templates. Instead I'm doing full client-side rendering using Vue.js. Confused yet? Let me explain.

Read more [reinink.ca]

Over at the Honeybadger blog, Starr Horne wrote an interesting article on the different types of UUIDs and ULIDs.

UUIDs are and will continue to be the standard. They've been around forever, and libraries are available in every language imaginable. However, new approaches are worth considering, especially as we enter a world that's increasingly run by distributed systems. New unique-id approaches may help us solve problems that weren't prevalent at the publication of RFC4122.

Read more [blog.honeybadger.io]

Christian Stettler explains why domain events and event sourcing should not be mixed up.

What do domain events have in common with event sourcing? Certainly the word “event” in the name. But beyond that, when talking to architects and developers in projects, at conferences or trainings, I often hear that domain events go well with event sourcing and that event sourcing is an ideal source of domain events. In this blog post I would like to outline why I personally do not share this view.

Read more [www.innoq.com]

The main thought behind hexagonal architecture is that by isolation the core logic of your app, adding more inputs (like an API or console app) or outputs becomes much easier. Here's a cool talk Mattias Noback gave a few years ago at SymfonyLive on the topic.

Read more

Christopher Rumpel launched a new video series on how Laravel works on the hood.

Laravel Core Adventures is a video series which explains how Laravel works under the hood. You will get several videos on different difficulty levels to learn about each topic. The first videos below are about the Laravel request lifecycle. Expect more to come when the full site is released in early 2019.

https://laravelcoreadventures.com/

Read more

At the LaraconLive India conference, Shawn McCool shared some interesting ideas on how to handle models in complex apps.

If you want to speak at the 2019 edition of the conference, you'll be happy to learn that they currently have a CFP running.

Read more

My colleague Brent shares how we've been structuring our non-trivial projects at Spatie.

In this post we'll look at a different approach of structuring large code bases into separate domains. The name "domain" is derived from the popular paradigm DDD, or also: domain driven design.

Read more [stitcher.io]

Here's another excellent post by Matthias Noback.

Reuse-in-the-small is definitely possible. Reuse-in-the-large is deemed to be impossible, because no two problems/projects are alike, but practice proves otherwise. There are reusable components covering entire subdomains, which are nonetheless quite successful. The chance of success is bigger if such a reusable component is used to cover for a generic subdomain. Using an off-the-shelf solution in such a case helps you save development effort which can instead be redirected to the core domain.

Read more [matthiasnoback.nl]

Mariko Kosaka, an engineer at Google, started a beautifully illustrated series on how Chrome works behind the scenes.

In this 4-part blog series, we’ll look inside the Chrome browser from high-level architecture to the specifics of the rendering pipeline. If you ever wondered how the browser turns your code into a functional website, or you are unsure why a specific technique is suggested for performance improvements, this series is for you.

Read more [developers.google.com]

Mark Baker, serial conference speaker and creator of the PhpSpreadsheet package shares some thoughts on how to create private classes using anonymous classes.

I’ve written before about the benefits of using PHP’s Anonymous Classes for test doubles; but Anonymous Classes also have potential usecases within production code as well. In this article I’m going to describe one such usecase that can be particularly useful within libraries, and that is replicating the access of Package Private (in Java), or Protected Internal Classes (as per C#).

Read more [markbakeruk.net]

Mattias Noback shares how you can migrate a code base that fetches its dependencies using static method calls to code that uses dependency injection.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

Read more [matthiasnoback.nl]

A great post by Barry O Sullivan on what, in my mind, is one of the biggest advantages of event sourcing: the ability to create projections.

Projections are a necessary part of any event sourced or CQRS system. These systems don't rely on a single generic data source such as a normalised MySQL database. Instead you build up your data sets by playing through the events, i.e the “film”, "projecting" them into the shape you want. This allows lot of flexibility as you're no longer bound by a single data model on which you have to run increasingly monstrous SQL queries (12+ joins anyone?). With projections you can build a data model specifically for the problem/question at hand.

Read more [dev.to]

At the Devoxx UK conference Michiel Rook gave a good intro talk on Event Sourcing.

Read more