Most systems will have to deal with future or deferred events. Even the most common example of software on the web — a blog — will have the ability to “publish” a post in the future at a certain time.
When that time is reached, the read model should return “published”. How does the read model do this? Compute the current time and override the status? What if we need a Reactor to do something once the post is published? Following are some strategies which can be used, depending on the system and the complexity required.
But first, this problem…
Laravel Octane is a new way of running Laravel applications at super high speeds:
“Laravel Octane supercharges your application’s performance by serving your application using high-powered application servers, including Swoole and RoadRunner. Octane boots your application once, keeps it in memory, and then feeds it requests at supersonic speeds.”
These steps assume you have the following:
Start off, by creating a new Laravel instance…
Tailwind CSS is a mobile first, utility CSS framework which will vastly increase productivity while implementing designs in your web app or website.
A small DX improvement I make in my Tailwind projects, which I’m describing as a “default first” approach (this is a semi-joke derived from mobile first).
It revolves around targeting styles for mobile. The Tailwind docs specify:
If you’d like to apply a utility at one breakpoint only, the solution is to undo that utility at larger sizes by adding another utility that counteracts it.
This is a small DX annoyance for me, why should I have…
Laravel Blueprint is a wonderful tool that helps scaffold Laravel apps in the early stage of development.
It uses a simple YAML format, like the below:
php artisan blueprint:trace and the models, migrations, factories, Nova resources will all be generated.
This saves a lot of time, but once it has been generated once, they can’t be generated again for fear of overwriting changes that have been made in developing the application.
A technique I’ve been using is to separate the generated model code and the model behaviour into a separate trait.
To achieve this, I’ve created a…
This is a matter of personal preference, it basically means that if you have a file, say
app/Services/Calculator.php and you wanted to write a test for this class, instead of hiding the test away in a
tests/Unit/Services/CalculatorTest.php file, you would put the test right next to what it is testing, in
This approach has a few benefits:
The approach has been championed by a few popular frameworks in the JS world — Angular, RedwoodJS…
Heroku provides a good base level guide to get a Laravel running on its platform, however, it really stops at the bare minimum.
We’ve got 10+ (micro-ish) services running in production on Heroku and over the years we’ve fine tuned our setup to ensure that these apps are performant and our DevOps is as seamless as possible.
There’s a bit of scope, so we’ll break it down into key areas. Follow along in the app’s lifecycle:
Frameworks like Laravel encourages this behaviour out of the box, with the loading of the
.env file and the config directory for the different services the application might do. This file is not committed to the repository as it contains super secret stuff, so a
.env.example is provided to assist developers when setting up the application on their local computer or deploying to servers.
However, I feel the process could be improved, especially when adding new environment variables to…
Every developer loves to hate WordPress, and they have good reason to! It’s built on PHP which has its many flaws and does not follow any modern software architectures.
However, there’s no denying the popularity of the “platform”, it powers 20% of the internet and as such there is a HUGE market for developers that can develop on the WordPress platform. It’s cost effective and probably the best content editing experience for clients. Clients being the key word here.
As such, I’m torn between the market and using modern software techniques. So, I’ve tried to combine the two :)
If you have state that can be stored in the URI, I highly suggest you store it there, because:
If you authenticate with Firebase in your app, authenticating with your API is very easy, as the Firebase token is a JWT.
All we really need to is implement a
Guard with a
user function that returns an
Because our user is actually stored in the JWT token, we can completely skip the custom User Provider class, as we can simply return an
Authenticable object directly from our
Step 1: Configure Laravel to use our custom guard in
Step 2: Add our custom guard to the Auth manager
Step 3: Add some dependencies