How we simplified our development process with a new workflow

Our problem

In the past, many of our projects were built in a two-step process. First, the UX team would create a static build of the website using our frontend baseplate, Core. Templates would be made for each page using a defined framework of bespoke components in Sass & HTML. Once signed off, this would be given to the development team, who would integrate it into the Laravel backend.

However, the backend was built using database models; in our case, this meant passing Eloquent models through to Laravel Blade templates based on the static frontend build. As a result, whenever changes were required, both teams were needed to action them. Over time, the static and dynamic templates would gradually diverge due to human error.

Our solution

We still needed parts of the process to stay the same; the backend templates are always required by the website, but the frontend templates are used for first stage sign off.

We replaced both the database-model-driven Laravel Blade templates and the static HTML templates with a single Laravel Blade template which only uses simple PHP objects (arrays, numbers, string, dates etc.).

Then, to create the static version of the site, we included an extra folder, called “frontend” which can pass our view data needed for sign off:

These “frontend” files are then exposed on a “/frontend” route in non-production environments, such as testing and staging. Then, for the backend, we can still render these template files, but first we have to transform our database model into simple PHP objects.

How it works

We use a particular convention called a Builder to encapsulate the creation of the frontend models. All our frontend models have a corresponding Builder that understands how to create the model from an database model in a particular context. They all inherit the following base class:

In our product example, we could have the following:

And now we have a Builder that understands how to create view models for Products. Once this is in place, we can request them with Laravel’s service container inside our controllers or elsewhere:

We can also have various Builders for the same model, but in different contexts. For example, we might create a NewsArticleBuilder for building the article page itself, and a NewsArticleSummaryBuilder, for when we are showing multiple articles at once on a News listing page.

Why it works

With this new process, we have decoupled the frontend build from the backend models. However, at sign off time, we have much tighter cohesion between the frontend and backend, as there is now only one HTML template to manage when making changes.

Try it for yourself

We have published our solution to packagist as engageinteractive/laravel-frontend, and made all the code available here.

The setup described in this post is the default provided by the package, but this can all be changed in the configuration. Once you have it installed, just run the vendor publish command to get started with the default setup.