Over the course of a year in 2020, we fully migrated off our Jenkins installation which housed our entire set of pipelines for continuous integration and deployment. This is our journey of creating and open-sourcing a set of actions to grow our GitHub pipelines.

One day we saw an interesting crash that one of our applications was generating a URL so long that Google's static map generation refused to generate it. With a bit of research we discovered lodged in the official documentation that there was a known limit.

This led us to discovering that Google had the Encoded Polyline Algorithm Format designed to help pack information in the URL into a dense binary format in plain ASCII text in order to reduce characters. This blog is our journey to writing a little package to accomplish this in PHP.

As our application pipeline elevated into ephemeral GitHub Action containers the Fastlane plugin codenamed "badge" we used was showing some age. It depended on a few native dependencies and took a bit of time to install on our runners. We saw this chance to leverage some exciting new technology and produce an alternative.

As Laravel said goodbye to Laravel Mix and embraced Vite we saw some new exception in our logs as we completed the migration.

Unable to preload CSS for /build/assets/Map-BjJvrIF-.css
Failed to fetch dynamically imported module build/assets/en-c7059b5d.js

We went on a journey to fix this issue and this blog is our findings.

As a project we built evolved with websockets becoming a far more important feature we wanted to move off of a regular implementation of Redis onto a Redis Cluster to scale for larger usage while giving us the safety of failover and redundancy.

As the year clocked into 2023 a package we depended on exceeded a year without a merge with pull requests stacking. At this point we already had a few patches applied locally with patch package, but we decided to fork the package due to our dependency on it.

Introduction​

Here at Sourcetoad, we've been working on migrating our PHP framework—mostly Laravel-based projects—to Amazon Web Services' Elastic Container Service (ECS). As we worked through the process, we were surprised at how scattered around the web good information seemed to be. There certainly was no comprehensive guide to run Laravel applications on ECS in what we would consider an enterprise-grade fashion.

Don't get us wrong: many guides exist, but they appeared to be leaving out important information. Some guides had part of the story, and others had the other part. A person needs to already understand AWS best practices to really know what is left out of each one. We thought it would be interesting to share what we have done in a comprehensive guide. This guide is for people who already have a basic understanding of how to run Laravel in Docker and use ECS. It focuses on the hardening and optimizations we have done.

Developing an API was a common task for engineers working with Laravel in the early days of the framework. Prior to version 5.5 Laravel did not offer an elegant way to format/prepare API responses. Historically, it worked by calling toArray() on your model instance.

This pattern of calling toArray() risked the possibility of exposing attributes that should not be exposed over an API. As a result, it was common to use the $hidden property to exclude the specified attributes during serialization which was helpful in building an API response as both a mechanism to avoid exposing sensitive data and more generally controlling which data would be included. The example shown below was a common pattern prior to Laravel 5.5.

<?php

class User extends Eloquent {
    protected $hidden = ['password', 'remember_token'];
}

// Usage
$user = User::find(1);
$user->toArray();
// Returns: ['name' => 'John', 'email' => 'john@example.com']

This approach was flexible, but any change to your database schema resulted in those changes appearing in your API. We needed something more concrete and landed on Fractal which served us well until Laravel added official support for API Resources, and thus we worked on an enhancement for that feature.

As our applications moved from Laravel 4 into the future versions we noticed an issue that occasionally came up. Laravel validation rules in the early days of Laravel were primarily leveraged using string concatenation with pipe (|) characters.

$this->validate($request, [
  'title' => 'required|unique:posts|max:255',
  'body' => 'required',
]);

This added a bit of a mental overhead to know all the variations these rules offered and would require a fair amount of trips to the documentation to remember all the possible validation options. Additionally, if you made a typo on some of the rule names Laravel would just silently skip that rule during validation. If you didn't have great test coverage it was pretty easy to make a mistake with this style of validation writing.

We were in search of a more fluent approach to validation rules and as the release of Laravel 8 arrived we decided to create a package to solve our issue.