DEV Community

Writing Code like a Senior Developer in Laravel

Martin Tonev on February 08, 2024

In the evolving landscape of web development, Laravel has emerged as one of the prominent PHP frameworks for building elegant applications. If you’...

Read full post

Jesus Guerrero • Feb 9

We should take care before labeling something as wrong without giving context because there's a reason things are there in the first place

Eg. With eloquent vs DB::table(). when you want granular data and calculations with select with the eloquent model the attribute with the same name will be overwritten and are Eloquent is slower for some cases DB::table gives you more control an its more suitable.

Kaloy • Feb 9

Agree. Using the query builder shouldn't be labeled as the wrong way. I think the combination of both is the right way and it should be depending on the use case e.g. use query builder for large datasets.

Martin Tonev • Feb 9

There are cases where I even write plain MySQL but the point is for juniors to use Models and relations.

Because I have been part of large projects where juniors use only DB - you can imagine if something changes in one table, how many places you have to change it OR just add one global scope to table.

leob • Feb 11 • Edited

Good article, but if this would already be enough to make you or me a Laravel Senior then we'd be setting the bar pretty low :P ...

There's such enormous breadth and depth to the way you can do things in Laravel - but of course that would require not a single article on dev.to, but a series, or a whole book ...

Martin Tonev • Feb 12

All the things which senior need to know are things for book not for article.

Daniel Reis • Feb 10

I would not say that is a "Senior" thing. It's the basics from the Framework itself.

There's so many ways that you can do the same thing in Laravel, using features that isn't even documented that you would be impressed.

Totally agree with the SOLID, DRY and naming classes etc but we as seniors should know that DEPENDS mostly on how much time we have and what the feature ask us.

And btw: do not user $request->all() if you're validating something when you can go for $request->validated() :p

Martin Tonev • Feb 12

All the things which senior need to know are things for book not for article.

Julian Finkler • Feb 9

Wrong and right are terms that should a senior developer avoid in a context like this.
Applying the DRY principle everywhere causes tighter coupling. You have to use the most fitting tool - or are you using a hammer for screws too? 😅

RoestVrijStaal • Feb 15 • Edited

Using the Query Builder instead of Eloquent is not "wrong". It depends per (company) context of what is the most usable.

However, most "plugins" and "extensions" of the Laravel ecosystem are so opinionated that they assume the use of Eloquent.

When the use of Eloquent or another ORM is not needed, then Laravel is a questionable choice to use as framework.

The use of Laravel's own database migrations and seeders is also context-dependent.

Also, the use of Middleware should be restricted to the bare necessaries.

Often I see people creating Middleware for certain parts of their application. They forget that EACH REQUEST goes through their Middleware (when no strict checks are put in their Middleware's provider, which is often forgotten as well). Most of the time it was better that the logic of that Middleware was moved to a trait. To be used by the controllers of those parts of their application only.

For the rest of the article mostly programming best practices are highlighted. The use of PSR's should be no subject of discussion. But following and using them does not make you a Senior Laravel Developer at all.

Mohammed Samgan Khan • Feb 9

This was good but was pretty generic. But Nice for covering basics.

Stanley Amaziro • Jul 26

I need to upscale my Laravel skills. any help?

Martin Tonev • Jul 31

Just read and practice everything you learn, this is the faster way!

Rickrickiin • Feb 9

This post will definitely be helpful.

teamradhq • Feb 16

I feel like the examples you've provided are more like Junior developer oopsies as opposed to senior developer pro tips.

For example, why wouldn't a senior developer use the DB facade? There are things you can't do with Eloquent that are easily achieved with the facade. And there are things that you might not want to define model methods for.

Here's a silly example: say you wanted to get a list of authors and illustrators who share the same birthday (a non-indexed column), you wouldn't want to define a relationship for this:

DB::table('authors')
    ->join('illustrators', 'authors.id.birthday', '=', 'illustrators.birthday')
    ->select('authors.name as author_name, illustrators.name as illustrator_name')
    ->get()

There are good reasons for using the DB facade here:

This is not a relationship in the strictest sense. At most, the query provides a coincidental relationship.
This information is unlikely to be used in other parts of the application.
If this were a model method, then developers would use it.

And your DRY tips seem a bit off... I'd expect a senior Laravel talking about this topic to discuss traits at the very least:

trait HasBirthday {
    public function scopeBornOn(Builder $query, Carbon|String $date) {
        return $query->where('birthday', $date);
    }
}

class User extends Model {
    use HasBirthday;
}

class Author extends Model {
    use HasBirthday;
}

class Illustrator extends Model {
    use HasBirthday;
}

User::bornOn('2008-01-01')->get();
Author::bornOn('2008-01-01')->get();
Illustrator::bornOn('2008-01-01')->get();

And while your example, provides a good start for a Junior developer, a senior developer would write this more succinctly:

private function getItemAndCategories(int $id) {
    $data['item'] = Item::find($id);
    $data['categories'] = Category::all();
    return $data;
}

Because there's no point in having an intermediary variable here:

private function getItemAndCategories(int $id): array {
    return [
        'item' => Item::find($id),
        'categories' => Category::all(),
    ];
}

Or here:

public function show(int $id) {
    return view('item.show', $this->getItemAndCategories($id));
}

And would a senior developer ever call Model::all like this? At the very least, a senior developer would paginate the result and restrict the columns:

Category::paginate(25, ['name', 'id', 'description'], 'categories');

If you have hundreds of categories, you don't return every one and you don't return all data.

And where are the examples for Artisan, Migrations, Seeders, Middleware, Testing, and Queues? If you scrubbed all of your examples and provided some context and examples (with syntax highlighting) on these topics, the article would be more worthy of its title :)