php[architect] November 2018

12 \ November 2018 \ http://www.phparch.com

Maintaining Laravel Applications

this is additional code you will need

to maintain. While custom code and

packages indeed have their place, you

may be surprised how little code you

have to write to use or customize pretty

advanced features.

Here are a few features developers

seem to overlook.

FormRequest
Many applications do inline form
validation within controller actions.
While recent versions of Laravel make
this easy to do using $request->vali-
date() it can clutter code. Laravel 5.
introduced FormRequest objects which
encapsulate all of the logic around
request validation. These can help keep
your controller actions clean by sepa-
rating this responsibility.

Responsables
Another relatively large amount of
code in controller actions relates to
generating the response. Laravel 5.
introduced the Responsable interface.
Any class which implements this inter-
face can be returned, and Laravel will
use its toResponse method to generate
a response. Another way to keep your
code clean or replace functionality
previously provided by a package.

Events

Event-driven design is reemerging

with paradigms like CQRS. Laravel

has supported events since version 5.0.

However, not many applications are

using them. While using events within

your application may increase complex-

ity, they are nonetheless an easy way to

communicate between objects. You will

need to weigh the cost versus benefits

for your application, but if you find

yourself performing blocks of different

logic in one place because that’s where

the action occurs, events may provide

a way to separate those responsibilities.

Scheduled Tasks

Similar to events, commands have

been available since Laravel 4. They

received an overhaul in Laravel 5 to

allow for the scheduling of these tasks.

Instead of running multiple separate

cron jobs, you can run one cron job for

the Laravel scheduler. I still see so many

applications with various cron jobs

for scripts with odd ways to hook into

Laravel. Creating a console command

and scheduling it within Laravel keeps

all your application logic in one place.

Staying Current

Analytics from Shift show Laravel

5.3 is the most popular version. A lot

of applications get stuck on Laravel 5.

because of PHP version requirements,

conversion to Dusk, and changes in

Auth components. However, we have to

remember, Shift is an upgrade service.

So while this indicates Laravel 5.3 is

popular in the wild, it equally indi-

cates applications are being upgraded.

As such, Laravel 5.5 is likely the most

popular version.

All projects should run the latest,

stable version of Laravel.

Many believe as the creator of Shift I

am biased. Sure, maybe a little. But this

advice comes from analytics, commu-

nity discussion, and conversations

with Taylor Otwell. It’s not an effort

to sell another Shift. It doesn’t matter

to me how you upgrade, just that you

do upgrade. Here are a few things to

consider when staying current.

Refreshing Refactor

Too often when it’s time to upgrade

Laravel developers simply run composer

update. This may work for a few versions.

But each time you do this you’re accu-

mulating technical debt. Sooner or later

that debt stacks up enough, and you’ll

end up paying more. As a result, I see a

lot of developers go the route of copy-

ing and pasting their code from the old

application into a new Laravel applica-

tion running the latest version.

Even fewer developers go through

the Upgrade Guide^6 and perform all

changes related to the new version. This

is actually one of the reasons Shift is so

successful. Not only does it apply the

changes required between each version,

but also the recommended changes.

6 Upgrade Guide:

https://laravel.com/docs/5.7/upgrade

It will even warn about deprecations

and make suggestions for using new

features.

The goal of any upgrade should be to

make your application look as though

it was created using that version. This

not only eliminates all technical debt

but allows you to use the latest features

of the framework freely. Next time you

upgrade your Laravel application take

the time to review your application for

opportunities to refactor code. You may

find large amounts of code or packages

used previously that are now available

within the framework.

LTS is a Trap

Laravel offers a Long Term Support

(LTS) version. LTS versions receive bug

fixes for two years and security fixes for

three years. Currently, there are two

LTS versions: Laravel 5.1 and Laravel

5.5. While this appeals to developers

who may see this as a mark of stability,

it’s a trap.

LTS was adopted by Laravel simply to

follow suit with other frameworks. The

theory is, by offering this support the

framework might appeal to enterprise.

But this creates a rob Peter to pay Paul

scenario. In offering this support to

increase adoption, you’re also increas-

ing drag on not only the application

but the community because you’re

diverting resources away from the latest

versions.

Once you lock your application into

this LTS version, you’re committing to

staying behind the latest version. This

means you’re willingly taking on tech-

nical debt. Every passing version means

more outdated code, less compatibility,

and potential rework to implement new

features.

Lumen is Dead

Lumen is dying, if not already dead.

I actually wrote “Lumen is dead, long

live Lumen”^7 at the beginning of 2017.

Despite the stubborn haters, each of

my premises continues to be validated.

Google Trends, as well as Packagist,

demonstrate a decline in adoption.

7 “Lumen is dead, long live Lumen”:

https://phpa.me/lumen-dead