I’ve been putting off learning how to deploy a PHP/Laravel app to a “serverless” environment for quite a while. A recent talk by Carl Alexander at Longhorn PHP finally gave me the push to try it out. This is the first in a series of posts documenting my experience as a longtime PHP developer checking out this topic in-depth for the first time.
Array validation in Laravel is very powerful, but sometimes it might not do exactly what we expect when we’re dealing with multidimensional arrays and wildcard notation. Let’s dig into a real-world example to see how it works internally and deepen our understanding of this feature along the way.
If your Laravel app is “full stack” and rendered with Blade views, but you have a few controller actions called only by Javascript, should those controllers go in the api route group or should they stay in the web route group?
Laravel factories are a huge time-saver when writing tests. In the past, I’d build a factory to include every model property in the default state, but lately I’ve switched to having minimal factories by default. I’ll explain my reasons for this change, and what benefits I’ve found.
In a previous post, I discussed some thoughts around choosing the right HTTP status code. In today’s post, I’ll tackle a different scenario, and my reasoning behind the particular status code I ended up using.
On a recent project, we were building a Laravel API to be consumed by a mobile app being built by a separate team. When an end user reported an issue, one of the first questions was “Is this bug in the API or the mobile app?” In this post, I’ll share a logging strategy we used to help us quickly get to the root cause of the problem.
Laravel automatically trims incoming strings in the HTTP request. This convenience can be easy to take for granted because it’s such a sensible default behavior, but how would you disable it for just one route? And why might you want to do that?
We all make stupid mistakes from time to time. I’m sharing this one to hopefully save someone else a little frustration.
I used to think Docker would solve all my issues with local dev matching the production environment, but I was wrong.
Podcast hosting is one of those things that feels very difficult to change. I worked hard to build an audience and I didn’t want a behind-the-scenes technical change to break any subscriptions and alienate listeners. As a result, I kept putting off the move to Transistor. Well, I finally took the plunge, and I’m happy to report it was much easier than I anticipated. Before we get into the details, I want to step back and explain my motivation to move in the first place.