DEV Community: Lucas Porfirio

SOLID Principles: They're Rock-Solid for Good Reason!

Lucas Porfirio — Fri, 02 Feb 2024 17:22:31 +0000

Just started with object-oriented programming and feeling a bit lost about SOLID? No worries, in this article, I'll explain it to you and provide examples of how to use it in your code development.

What is SOLID?

In object-oriented programming, SOLID is an acronym for five design principles aimed at enhancing the understanding, development, and maintenance of software.

By applying this set of principles, you should notice a reduction in bugs, improved code quality, the production of more organized code, decreased coupling, enhanced refactoring, and encouragement of code reuse. Let's get to them.

1. S - Single Responsibility Principle

SRP - Single Responsibility Principle

This one is really simple, but super important: one class should have one, and only one, reason to change.

No more creating classes with multiple functionalities and responsibilities, huh? You've probably encountered or even created a class that does a bit of everything, a so-called God Class. It might seem fine at the moment, but when you need to make changes to the logic of that class, problems are sure to arise.

God class: In OOP, this is a class that do or knows too much things.



class ProfileManager {
  authenticateUser(username: string, password: string): boolean {
    // Authenticate logic
  }

  showUserProfile(username: string): UserProfile {
    // Show user profile logic
  }

  updateUserProfile(username: string): UserProfile {
    // Update user profile logic
  }

  setUserPermissions(username: string): void {
    // Set permission logic
  }
}

This ProfileManager class is violating the SRP principle by performing FOUR distinct tasks. It is validating and updating data, doing the presentation, and to top it off, it's setting the permissions, all at the same time.

Issues this can cause

Lack of cohesion - a class shouldn't take on responsibilities that aren't its own;
Too much information in one place - your class will end up with many dependencies and difficulties for changes;
Challenges in implementing automated tests - it's hard to mock such a class.

Now, applying SRP to the ProfileManager class, let's see the improvement this principle can bring:



class AuthenticationManager {
  authenticateUser(username: string, password: string): boolean {
    // Authenticate logic
  }
}

class UserProfileManager {
  showUserProfile(username: string): UserProfile {
    // Show user profile logic
  }

  updateUserProfile(username: string): UserProfile {
    // Update user profile logic
  }
}

class PermissionManager {
  setUserPermissions(username: string): void {
    // Set permission logic
  }
}

You might be wondering, can I apply this only to classes? The answer is: NOT AT ALL. You can (and should) apply it to methods and functions as well.



// ❌
function processTasks(taskList: Task[]): void {
  taskList.forEach((task) => {
    // Processing logic involving multiple responsibilities
    updateTaskStatus(task);
    displayTaskDetails(task);
    validateTaskCompletion(task);
    verifyTaskExistence(task);
  });
}

// ✅
function updateTaskStatus(task: Task): Task {
  // Logic for updating task status
  return { ...task, completed: true };
}

function displayTaskDetails(task: Task): void {
  // Logic for displaying task details
  console.log(`Task ID: ${task.id}, Description: ${task.description}`);
}

function validateTaskCompletion(task: Task): boolean {
  // Logic for validating task completion
  return task.completed;
}

function verifyTaskExistence(task: Task): boolean {
  // Logic for verifying task existence
  return tasks.some((t) => t.id === task.id);
}

Beautiful, elegant, and organized code. This principle is the foundation for the others; by applying it, you should create high-quality, readable, and maintainable code.

2. O - Open-Closed Principle

OCP - Open-Closed Principle

Objects or entities should be open for extension but closed for modification. If you need to add functionality, it's better to extend rather than modify your source code.

Imagine that you need a class to calculate the area of some polygons.



class Circle {
  radius: number;

  constructor(radius: number) {
    this.radius = radius;
  }

  area(): number {
    return Math.PI * this.radius ** 2;
  }
}

class Square {
  sideLength: number;

  constructor(sideLength: number) {
    this.sideLength = sideLength;
  }

  calculateArea(): number {
    return this.sideLength ** 2;
  }
}

class areaCalculator {
  totalArea(shapes: Shape[]): number {
    let total = 0;

    shapes.forEach((shape) => {
      if (shape instanceof Square) {
        total += (shape as any).calculateArea();
      } else {
        total += shape.area();
      }
    });

    return total;
  }
}

The areaCalculator class is tasked with calculating the area of diferent polygons, each having its own area logic. If you, 'lil dev, needed to add new shapes, like triangles or rectangles, you'd find yourself altering this class to make the changes, right? That's where you run into a problem, violating the Open-Closed Principle.

What solution comes to mind? Probably adding another method to the class and done, problem solved 🤩. Not quite, young Padawan 😓, that's the problem!

Modifying an existing class to add new behavior carries a serious risk of introducing bugs into something that was already working.

Remember: OCP insists that a class should be closed for modification and open for extension.

See the beauty that comes with refactoring the code:



interface Shape {
  area(): number;
}

class Circle implements Shape {
  radius: number;

  constructor(radius: number) {
    this.radius = radius;
  }

  area(): number {
    return Math.PI * this.radius ** 2;
  }
}

class Square implements Shape {
  sideLength: number;

  constructor(sideLength: number) {
    this.sideLength = sideLength;
  }

  area(): number {
    return this.sideLength ** 2;
  }
}

class AreaCalculator {
  totalArea(shapes: Shape[]): number {
    let total = 0;

    shapes.forEach((shape) => {
      total += shape.area();
    });

    return total;
  }
}

See the AreaCalculator class: it no longer needs to know which methods to call to register the class. It can correctly call the area method by calling the contract imposed by the interface, and that's the only thing it needs.

As long as they implement the Shape interface, all runs fine.

Separate extensible behavior behind an interface and invert dependencies.

Uncle Bob

Open for extension: You can add new functionality or behavior to the class without changing its source code.
Closed for modification: If your class already has a functionality or behavior that works fine, don't change its source code to add something new.

3. L - Liskov Substitution Principle

LSP - Liskov Substitution Principle

The Liskov Substitution Principle says that a derived class must be substitutable for its base class.

This principle, introduced by Barbara Liskov in 1987, can be a bit complicated to understand by reading her explanation. Still, no worries, I'll provide another explanation and an example to help you understand.

If for each object o1 of type S there is an object o2 of type T such that, for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

Barbara Liskov, 1987

You got it, right? Nah, probably not. Yeah, I didn't understand it the first time I read it (nor the next hundred times), but hold on, there's another explanation:

If S is a subtype of T, then objects of type T in a program can be replaced by objects of type S without altering the properties of this program.

Wikipedia

If you're more of a visual learner, don't worry, here's an example:



class Person {
  speakName() {
    return "I am a person!";
  }
}

class Child extends Person {
  speakName() {
    return "I am a child!";
  }
}

const person = new Person();
const child = new Child();

function printName(message: string) {
  console.log(message);
}

printName(person.speakName()); // I am a person!
printName(child.speakName()); // I am a child!

The parent class and the derived class are passed as parameters, and the code continues to work as expected. Magic? Yeah, it's the magic of our friend Barb.

Examples of violations:

Overriding/implementing a method that does nothing;
Returning values of different types from the base class.
Throwing an unexpected exception;

4. I - Interface Segregation Principle

ISP - Interface Segregation Principle

This one says that a class should not be forced to implement interfaces and methods it does not use. It's better to create more specific interfaces than a big and generic one.

In the following example, an Book interface is created to abstract book behaviors, and then classes implement this interface:



interface Book {
  read(): void;
  download(): void;
}

class OnlineBook implements Book {
  read(): void {
    // does something
  }

  download(): void {
    // does something
  }
}

class PhysicalBook implements Book {
  read(): void {
    // does something
  }

  download(): void {
    // This implementation doesn't make sense for a book
    // it violates the Interface Segregation Principle
  }
}

The generic Book interface is forcing the PhysicalBook class to have a behavior that makes no sense (or are we in the Matrix to download physical books?) and violates both the ISP and LSP principles.

Solving this problem using ISP:



interface Readable {
  read(): void;
}

interface Downloadable {
  download(): void;
}

class OnlineBook implements Readable, Downloadable {
  read(): void {
    // does something
  }

  download(): void {
    // does something
  }
}

class PhysicalBook implements Readable {
  read(): void {
    // does something
  }
}

Now it's waaay better. We removed the download() method from the Book interface and added it to a derived interface, Downloadable. This way, the behavior is isolated correctly within our context, and we still respect the Interface Segregation Principle.

5. D - Dependency Inversion Principle

DIP - Dependency Inversion Principle

This one goes like this: Depend on abstractions and not on implementations.

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Uncle Bob

Now I'll show a simple code to illustrate DIP. In this example, there's a service that gets the user from the database. First, let's create a concrete class that connects with the database:



// Low-level module
class MySQLDatabase {
  getUserData(id: number): string {
    // Logic to fetch user data from MySQL database
  }
}

Now, let's create a service class that depends on the concrete implementation:



// High-level module
class UserService {
  private database: MySQLDatabase;

  constructor() {
    this.database = new MySQLDatabase();
  }

  getUser(id: number): string {
    return this.database.getUserData(id);
  }
}

In the above example, UserService directly depends on the concrete implementation of MySQLDatabase. This violates DIP since the high-level class UserService is directly dependent on a low-level class.

If we want to switch to a different database system (e.g., PostgreSQL), we need to modify the UserService class, which is AWFUL!

Let's fix this code using DIP. Instead of depending on concrete implementations, the high-level class UserService should depend on abstractions. Let's create a Database interface as an abstraction:



// Abstract interface (abstraction) for the low-level module
interface Database {
  getUserData(id: number): string;
}

Now, the concrete implementations MySQLDatabase and PostgreSQLDatabase should implement this interface:



class MySQLDatabase implements Database {
  getUserData(id: number): string {
    // Logic to fetch user data from MySQL database
  }
}

// Another low-level module implementing the Database interface
class PostgreSQLDatabase implements Database {
  getUserData(id: number): string {
    // Logic to fetch user data from PostgreSQL database
  }
}

Finally, the UserService class can depend on the Database abstraction:



class UserService {
  private database: Database;

  constructor(database: Database) {
    this.database = database;
  }

  getUser(id: number): string {
    return this.database.getUserData(id);
  }
}

This way, the UserService class depends on the Database abstraction, not on concrete implementations, fulfilling the Dependency Inversion Principle.

Conclusion

By adopting these principles, developers can create systems more resilient to changes, making maintenance easier and improving code quality over time.

The entirety of this article is derived from various other articles, my personal notes, and dozens of online videos that I came across while delving into the realms of Object-Oriented Programming (OOP) 🤣. The code snippets utilized in the examples were created based on my interpretation and comprehension of these principles. I really wish, my lil padawan, that I have contributed to advance your understanding and progress in your studies.

I really hope you liked this article, and don't forget to follow!

Note: Images taken from this article

Handling Exceptions to impress in your Tech Interview

Lucas Porfirio — Wed, 31 Jan 2024 18:16:40 +0000

Exceptions will always be a constant topic when it comes to Object-Oriented Programming, and today, let's find out how to create them like true software artisans!

1. Introduction

When I started learning programming, one of the topics that always scared me was "errors" or anything related to it. However, as I studied more frequently, I realized that errors and/or Exceptions are much more friends than enemies. Of course, to achieve that, you need to understand how to use them in an interesting way for your project.

In my case, I used to use the throw new Error() snippet for literally anything, easily getting lost in the codebase due to a generic Exception scattered among many others. In the beginning, it wasn't a problem since I didn't work in a team with observability, so it was all good.

But over time, as I joined more awesome companies, I encountered excellent implementations of Exceptions, especially using the Factory Pattern. This method amazed me in how things can be simple and elegant, even when dealing with errors.

Today, I'll show you how to develop a taste for writing elegant Exceptions and avoid cluttering your code with a 2km-long error message within the business logic.

2. What We Want to AVOID

Let's start by giving a bit of context to this article: imagine you're developing an simple social network, and in it, you need to create a simple post for your user.

src
├── Post
│   └── Post.php
└── User
    ├── User.php
    └── Permission.php

Within this context, imagine you're trying to post as an user. Naturally, we'll impose some validation rules with their respective Exceptions.

namespace Lukeskw\User;

use Lukeskw\Post\Post;

class User {

    public function __construct(
        public string $username,
        public email $email,
        protected Permission $permission
    ) {

    }

    public function post(Post $post): void
    {

        if (!$this->permission->hasPermission($this->username)) {
            throw new \Exception(
                'You do not have permission to post because you are a "' . $this->permission->name . '". '
            );
        }

        if (strlen($post->description) < 50) {
            throw new \Exception(
                'You cannot post ' . $post->id . ' because it only has ' . strlen($post->description) . ' characters';
            );
        }

        $this->postToFeed($post);
    }


    private function postToFeed(Post $post): void
    {
        // do awesome stuff
    }
}

We've identified two validation rules that throw different exceptions to our client. And believe it or not, it works (in a scenario where the code is complete, ofc) and fulfills the validation role. HOWEVER, after learning that job interviews prioritize the QUALITY OF DELIVERY over the SPEED OF CREATION, my perspective shifted slightly to understanding how to transform things that seem "strange and ugly" into "simple and elegant" things.

In this case, I'd really like to avoid two things:

Generic Exceptions;
Exceptions taking over places meant for business logic.

Don't get me wrong; the exceptions will still be where they are, but we'll improve the code's readability.

3. Refactoring 1: Creating Exceptions

src
├── Post
│   ├── Exceptions
│   │   └── PostException.php
│   └── Post.php
│
└── User
    ├── Exceptions
    │   └── UserPermissionException.php
    ├── User.php
    └── Permission.php

Alright, now let's move on to the part where we create our first "customized" Exception by extending the base Exception to a new class. It's nothing out of this world, but it already enhances our readability and understanding of the code in several aspects.

namespace Lukeskw\User;

class PostException extends \Exception
{}

class UserPermissionException extends \Exception
{}

And we'll do a simple refactoring in our post() function, repositioning the default exceptions with the new exception we created.

namespace Lukeskw\User;

use Lukeskw\Post\Post;
use Lukeskw\Post\Exceptions\PostException;
use Lukeskw\User\Exceptions\UserPermissionException;

class User {

    public function __construct(
        public string $username,
        public email $email,
        protected Permission $permission
    ) {

    }

    public function post(Post $post): void
    {

        if (!$this->permission->hasPermission($this->username)) {
            throw new UserPermissionException(
                'You do not have permission to post because you are a "' . $this->permission->name . '". '
            );
        }

        if (strlen($post->description) < 50) {
            throw new PostException(
                'You cannot post ' . $post->id . ' because it only has ' . strlen($post->description) . ' characters';
            );
        }

        $this->postToFeed($post);
    }


    private function postToFeed(Post $post): void
    {
        // do awesome stuff
    }
}

With the new Exceptions, we now know exactly what it's about and, most importantly, where to look in our codebase when this Exception is triggered. It's literally a CTRL + SHIFT + F and search for the name "UserPermissionException." Makes your life easier, the life of the DevOps who will throw this into NewRelic/DataDog, and so on.

But something still bothers me a lot... Why are these giant messages in the middle of the business logic? Let's learn a way to hide this under the hood, but before that, we need to go through a Design Pattern called Factory!

4. Design Patterns: Factory Pattern

If you've heard of Design Patterns, you probably already understand a bit about what it solves. But in case you don't, I'll explain!

"Design Patterns are generic solutions to generic problems." - John Doe

In this idea of generic problems, some people got together and started creating some Software Design principles for you to solve day-to-day problems with a certain agility. Design Patterns are divided into three types:

Behavioral Patterns;
Creational Patterns;
Structural Patterns.

You can read more about them on the Refactoring Guru website, and I highly recommend it for any developer to explore this documentation and self-develop. Okay, but let's focus on it, the so-called Creational Factory (or Factory Method).

The idea of this pattern is to create objects without having to instantiate a thousand things in different classes. You literally manufacture an instance of something and just receive it in a simple call to some function. In the programming world, there are hundreds of millions of calls like Models::make(), Exception::create(), ApiWhatever::factory() so you don't have to access the constructor method of a respective class.

Taking the example of an API client, where we make the constructor modular in case we need to change the key and secret BUT still give the possibility of a quick call to manufacture the final object:

class GithubClient {

    public function __construct(string $clientId, string $clientSecret)
    {
        $this->client = new Client([
            'clientId' => $clientId,
            'clientSecret' => $clientSecret,
        ]);
    }

    public static function make(): self
    {
        return new self(
            env('github.client_id'),
            env('github.client_secret'),
        );
    }

    public function getUserByUsername(string $username = 'lukeskw'): array
    {
        // do a github call..
    }
}

// Calling without creating object

$client = (new GithubClient('awesome-client-id', 'awesome-client-secret'))
    ->getUserByUsername('lukeskw');

// Using Factory

$client = GithubClient::make()
    ->getUserByUsername('lukeskw');

We made a static call, manufacturing all parameters in a succinct way. This "make/factory" or whatever you want to call it can be a very extensive method depending on what you're injecting, but that's not a problem.

But anyway, we saw that readability using the Factory Pattern was improved; of course, you can put better names for the functions, but at its core, that's it. Now let's go back to our exceptions!

5. Refactoring 2: Refining the Exceptions

Great, we've learned a bit about the factory; now let's apply it.

We'll create a factory method for our exception that makes sense in the context of what's happening. Yeah, none of that "make" or "create" in these moments. Exceptions need to tell at least a minimal story for the user or developer about what's happening, and that's what we'll focus on.

After a slight refactoring in our UserPermissionException, we have the result of:

class UserPermissionException extends \Exception
{
    public static function permissionNotFound(string $permission): self
    {
        $message = sprintf('You do not have permission to post because you are a "%s".', $permission);
        return new self(
            message: $message,
            code: 403 // Forbidden
        );
    }
}

And after calling this factory in our code, we can notice an improvement in readability and maintainability since we isolated the information of the Exception within it.

 public function post(Post $post): void
    {

        if (!$this->permission->hasPermission($this->username)) {
            throw UserPermissionException::permissionNotFound($this->permission->name);
        }

        if (strlen($post->description) < 50) {
            throw new PostException(
                'You cannot post ' . $post->id . ' because it only has ' . strlen($post->description) . ' characters';
            );
        }

        $this->postToFeed($post);
    }

Now, refactoring the next one, we have the same idea of changing the PostException.

class PostException extends \Exception
{
    public static function minCharacters(string $postId, int $postCharCount): self
    {

        $message = sprintf(
           'You cannot post %s because it only has %c characters', $postId, $postCharCount,
        );

        return new self(
            message: $message,
            code: 403 // Forbidden
        );
    }
}

And now our post() is looking wonderful!

 public function post(Post $post): void
    {

        if (!$this->permission->hasPermission($this->username)) {
            throw UserPermissionException::permissionNotFound($this->permission->name);
        }

        if (strlen($post->description) < 50) {
            throw PostException::minCharacters($post->id, strlen($post->description));
        }

        $this->postToFeed($post);
    }

Is it wonderful? Yes. But there's still something bothering me... Why pass primitive types when these exceptions are "communicating" with classes?

It would be much cleaner if we pass the reference of the entire object to the Exception, and inside it, it resolves what it needs to use. After all, what if we need more things in the future, and it doesn't hurt to make it look nice, right?

namespace Lukeskw\Post;

use Lukeskw\Post\Post;

class PostException extends \Exception
{
     public static function minCharacters(Post $post): self
    {

        $message = sprintf(
           'You cannot post %s because it only has %c characters', $post->id, strlen($post->description),
        );

        return new self(
            message: $message,
            code: 403 // Forbidden
        );
    }
}

---------------------------------------------------------------

namespace Lukeskw\User;

use Lukeskw\User\Permission;

class UserPermissionException extends \Exception
{
    public static function permissionNotFound(Permission $permission): self
    {
        $message = sprintf('You do not have permission to post because you are a "%s".', $permission->name);
        return new self(
            message: $message,
            code: 403 // Forbidden
        );
    }
}

And the final result of our method is just charming, with encapsulated exceptions that will also give you great feedback in your job interview.

namespace Lukeskw\User;

use Lukeskw\Post\Post;
use Lukeskw\Post\Exceptions\PostException;
use Lukeskw\User\Exceptions\UserPermissionException;

class User {

    public function __construct(
        public string $username,
        public email $email,
        protected Permission $permission
    ) {

    }

    public function post(Post $post): void
    {

        if (!$this->permission->hasPermission($this->username)) {
          throw UserPermissionException::permissionNotFound($this->permission);
        }

        if (strlen($post->description) < 50) {
            throw PostException($post);
        }

        $this->postToFeed($post);
    }


    private function postToFeed(Post $post): void
    {
        // do awesome stuff
    }
}

6. Conclusion

Exceptions are by far one of the most "annoying" things to deal with. After all, nobody wants errors popping up on the client's screen. But overall, they just need to be well-written, and adding a bit of charm with static calls, and BOOM, you get praise and a positive points in the job interview.

I really hope you liked this article, and don't forget to follow!

Improving Laravel's Queue Performance

Lucas Porfirio — Fri, 15 Sep 2023 19:12:56 +0000

I didn't always use Laravel the way I do today. In the beginning, I made a lot of mistakes, and I believe that's part of the maturing and evolving process, so let's call it normal. Perhaps I've made the same mistakes you have, or maybe even more. One of the many mistakes I made was, for example, making all my validations inside the controller😂 Fortunately, I recognized my mistake very early on and was able to correct it in time.

Now, considering the context of queues (jobs), another mistake I've made is this:

class SaveAccessLog implements ShouldQueue
{
    use Dispatchable;
    use InteractsWithQueue;
    use Queueable;
    use SerializesModels;

    public function __construct(protected User $user)
    {
        //
    }

    public function handle(): void
    {
        Log::create([
            'user_id' => $this->user->id,
            // ...
        ]);
    }
}

Do you know what the problem is with this piece of code? I already know what you're thinking: "It's not creating the log via a relationship!" Did I get it right? Don't worry; this is just an example! If you're not a hardcore Laravel user, you probably won't see the issue; everything seems normal. If you couldn't find the answer, don't worry. I'll explain it to you.

Understanding the Problem

First of all, this is not an error but rather a Laravel behavior that prevents us from extracting the maximum potential from our queues, resulting in a performance issue in terms of execution time.

Have you noticed that every Laravel queue class includes four traits?

class SaveAccessLog implements ShouldQueue
{
    use Dispatchable;
    use InteractsWithQueue;
    use Queueable;
    use SerializesModels;

    // ...
}

Here's where the point to be observed lies. One of these traits is "SerializesModels." This trait is responsible for serializing and deserializing all the properties in the queue class. Inside it, it uses another trait called "SerializesAndRestoresModelIdentifiers," which, in turn, performs other tasks by consuming other Laravel classes, for example, identifying if a serialized property is an instance of a model so it can be correctly retrieved from the database.

Basically, what Laravel needs to do at this point in the execution is, as mentioned above, serialize the properties of the queue class so that they can be stored in databases - regardless of their type. When the queue is actually executed, these properties should be available for use in their original state, preserving the values given to the properties when the queue record was created. This helps us understand that the larger the object to be serialized, the more work Laravel needs to do to perform serialization and deserialization, and that's where the problem lies.

A queue is stored in the database like this:

{
    "uuid": "31378037-ebd2-4cd0-9abf-b9cfac94c8c9",
    "displayName": "App\\Jobs\\SaveAccessLog",
    "job": "Illuminate\\Queue\\CallQueuedHandler@call",
    "maxTries": null,
    "maxExceptions": null,
    "failOnTimeout": false,
    "backoff": null,
    "timeout": null,
    "retryUntil": null,
    "data": {
        "commandName": "App\\Jobs\\SaveAccessLog",
        "command": "O:22:\"App\\Jobs\\SaveAccessLog\":1:{s:6:\"\u0000*\u0000car\";O:45:\"Illuminate\\Contracts\\Database\\ModelIdentifier\":5:{s:5:\"class\";s:14:\"App\\Models\\Car\";s:2:\"id\";i:1;s:9:\"relations\";a:0:{}s:10:\"connection\";s:6:\"sqlite\";s:15:\"collectionClass\";N;}}"
    }
}

If, after deserialization, the property is a model, then:

// Illuminate/Queue/SerializesAndRestoresModelIdentifiers.php

protected function getRestoredPropertyValue($value)
{
    // ...

    return is_array($value->id)
        ? /* ... */
        : $this->restoreModel($value); // 👈🏻
}

public function restoreModel($value)
{
    return $this->getQueryForModelRestoration(
        (new $value->class)->setConnection($value->connection), $value->id
    )->useWritePdo()->firstOrFail()->load($value->relations ?? []); // 👈🏻
}

Solving This Problem

Many developers insist on "injecting" an entire object into the queue class—often as an instance of a model, carrying numerous relationships—without realizing that for the context of that task, perhaps only one, two, or three properties of the model would be necessary.

Let's look at the example again:

class SaveAccessLog implements ShouldQueue
{
    use Dispatchable;
    use InteractsWithQueue;
    use Queueable;
    use SerializesModels;

    public function __construct(protected User $user)
    {
        //
    }

    public function handle(): void
    {
        Log::create([
            'user_id' => $this->user->id,
            // ...
        ]);
    }
}

// ...

SaveAccessLog::dispatch(User::first());

Can you see that only the user's id is REALLY in use in the above example? So, why do I need to send the entire user object? That doesn't make any sense! The best approach to IMPROVE THIS CODE would be:

class SaveAccessLog implements ShouldQueue
{
    use Dispatchable;
    use InteractsWithQueue;
    use Queueable;
    use SerializesModels;

    public function __construct(protected int $userId)
    {
        //
    }

    public function handle(): void
    {
        Log::create([
            'user_id' => $this->userId,
            // ...
        ]);
    }
}

// ...

SaveAccessLog::dispatch(User::first()->id);

Notice the difference? Basically, if I only need the user's id, then I send ONLY the user's id. At this point, you might ask, "But won't Laravel serialize this the same way?" I confess that this is a GREAT question! The answer is: YES, but the effort Laravel needs to serialize and deserialize an int is MUCH LESS than for an entire object.

Here is the serialization of the improved code example:

{
    "uuid": "8fd5f768-8421-467c-8cb6-4a0973ca9829",
    "displayName": "App\\Jobs\\SaveAccessLog",
    "job": "Illuminate\\Queue\\CallQueuedHandler@call",
    "maxTries": null,
    "maxExceptions": null,
    "failOnTimeout": false,
    "backoff": null,
    "timeout": null,
    "retryUntil": null,
    "data": {
        "commandName": "App\\Jobs\\SaveAccessLog",
        "command": "O:22:\"App\\Jobs\\SaveAccessLog\":1:{s:8:\"\u0000*\u0000userId\";i:1;}"
    }
}

Notice how it is smaller in the data section? It's worth noting that with the improved code example approach, Laravel won't perform a database query when the queue is actually executed since we haven't injected a model instance, but only the user's id.

Did you think I forgot about situations where we need to inject more than one property into the queue class? For such cases, in my view, the ideal approach is to send an array with everything needed for execution:

class SaveAccessLog implements ShouldQueue
{
    use Dispatchable;
    use InteractsWithQueue;
    use Queueable;
    use SerializesModels;

    public function __construct(protected array $user)
    {
        //
    }

    public function handle(): void
    {
        Log::create([
            'user_id'    => $this->user['id'],
            'user_email' => $this->user['email'],
            // ...
        ]);
    }
}

// ...

SaveAccessLog::dispatch(User::first()->toArray());

Conclusion

It's okay if you don't see the point in this right now! Take the learning and carry it with you because I guarantee that one day you will need it, and then you will see the difference. In my case, this only made sense to me when I needed to scale the performance and execution time of my queues because it was with this technique that I achieved IMPRESSIVE queue execution results.

From XMLHttpRequest to Fetch API: How Fetch became the Way Forward for JS Development

Lucas Porfirio — Thu, 29 Jun 2023 03:50:21 +0000

Hello there ✌

This week I have been reading about the "recently" added Fetch API in NodeJS, which got me thinking about how we moved from XMLHttpRequests to the Fetch API. As developers, I really think we should understand the history behind the things we use daily.

XMLHttpRequest (XHR) has long been the go-to choice for making asynchronous HTTP requests. But, with the introduction of the Fetch API, a newer alternative has emerged. We will now explore why the Fetch API is considered the way forward for JavaScript development, and why it has quickly gained popularity among us, web developers.

Drawbacks of XMLHttpRequests

XHR, while functional, comes with a few limitations. Its syntax is complex and often requires extensive boilerplate code. Beyond that, XHR responses are based on event listeners, leading to the famous callback hell and unreadable code. The Fetch API addresses these drawbacks, providing a simpler and more intuitive approach to handling network requests.

Simplicity of the Fetch API

I guess we all can agree that ES6 changed the internet, presenting us with many new resources, including the Fetch API. With that said, one of the major advantages of the API is its simplicity. The API is built around the concept of promises, allowing for cleaner and more readable code. Now we can easily chain operations using the .then() method, making the code flow more intuitive and way easier to understand.

Community adoption

The Fetch API has gained significant popularity within the JavaScript community. It is widely used in modern frameworks and libs, and extensive resources and documentation are available for developers to explore and learn from. By using the Fetch API,
devs jump right into a sharing community that's all about working together.

Conclusion

There are tons of reasons for why we moved to the Fetch API, such as standardization, CORS support, async/await and others. The API represented a significant step forward for JavaScript networking, offering a simpler, more flexible, and future-proof approach compared to the traditional XMLHttpRequest. Its seamless integration with promises, improved syntax, and robust support for modern web standards make it the preferred choice for making asynchronous HTTP requests. By using the Fetch API, developers can unlock the full potential of JavaScript networking and build more reliable, and scalable apps for the web.

I truly love the history behind all this revolution we're living, and I really enjoyed writing this. I hope you like the read as well! ❤

Unlocking the Potential of Async in JavaScript

Lucas Porfirio — Fri, 09 Jun 2023 05:03:17 +0000

Today I was wandering around Dev.to and found this great article about promises, and it gave me the idea to discuss about asynchronous Javascript.

As you should know by now, JS is standardized by ECMA International, and every year they develop new features to the language we all know and love. And in 2017, with the 8th version of ECMAScript(ES8), they announced a new syntactic suggar for our Promises: Async and Await.

Async/await is a newer way to handle Promises within our code, avoiding the creation of cascades of .then as we often see on our codes. It's worth noting that we are still working with Promises, but they become less visible and less verbose.

Syntax

We use the prefix async before defining a function to indicate that we are dealing with asynchronous code, and with the added prefix, we can use await before Promises to indicate a point to be awaited by the code. Let's understand how this works in practice:

// Promise way (pre ES8)
function fetchBooks(book) {
  fetch(`/books/${book}`).then(response => {
    console.log(response);
  });
}

// Async/Await way (ES8+)
async function fetchBooks(book) {
  const response = await fetch(`/books/${book}`);
  console.log(response);
}

See how the code became clearer. We no longer need to declare .then or .catch and worry about a Promise not executing before using its result because await takes on the role of waiting for the request to return its result.

I believe that the biggest problem solved by async/await is the famous Promise cascade, affectionately called Promise Hell. Let's imagine the following code written in ES6 (without async/await):

fetch('/users/lukeskw').then(user => {
  fetch(`/groups/${user.id}`).then(groups => {
    groups.map(group => {
      fetch(`/group/${group.id}`).then(groupInfo => {
        console.log(groupInfo);
      });
    })
  });
});

This tangled mess of code and .then statements that we see can be easily improved using this syntax:

async function fetchUserAndGroups() {
  const user = await fetch('/users/lukeskw');
  const groups = await fetch(`/groups/${user.id}`);

  groups.map(group => {
    const groupInfo = await fetch(`/group/${group.id}`);
    console.log(groupInfo);
  });
}

Each time we define an await, we are indicating to our interpreter to wait for the next Promise to execute and return a result before proceeding. This way, we prevent the subsequent lines from executing without the necessary variables.

It's worth remembering that every function we define with async automatically becomes a Promise. This means that we can attach asynchronous functions to each other. Let's see how this looks in code:

async function fetchUser() {
  const response = await fetch('/users/lukeskw');

  return response;
}

async function fetchGroups() {
  const user = await fetchUser();

  const response = await fetch(`/groups/${user.id}`);

  console.log(response);
}

And what about the `.catch`?

So far, we have seen how to capture the result of the previous .then and assign it to a variable using await. But how do we handle errors? With this syntax, we can use the good ol' try/catch to ensure that errors in our code and Promise responses don't leave traces for the end user. Let's see how this works:

// Promise syntax (ES6)

function fetchUser() {
  fetch('/users/lukeskw')
    .then(response => console.log(response));
    .catch(err => console.log('Error:', err));
}

// New syntax (ES8+)

async function fetchUser() {
  try {
    const response = await fetch('/users/lukeskw');

    console.log(response);
  } catch (err) {
    console.log('Error:', err);
  }
}

In addition to making the code more elegant, a great utility is to use a single catch for multiple Promises. This way, if the errors from these Promises have the same outcome for the end user, we can handle them in one place (while still separating them into multiple try/catch blocks if the errors are different).

And when to use it?

That's a tough question to answer, but for me, there is no restrictions to using async/await. In fact, it's been a while since I wrote a .then because I believe that the new syntax makes the code cleaner.

Conclusion

Async/await simplifies error handling with the familiar try/catch blocks, allowing us to centralize error handling logic and provide a better user experience. It also enhances code readability by reducing promise hell and minimizing nested structures.

Whether you're fetching data from an API, performing database queries, or handling any asynchronous task, async/await is a valuable tool in your JavaScript arsenal. Its adoption has become increasingly widespread, and it has quickly become the preferred approach for handling asynchronous operations.

So no more need of writing cascades of .then and .catch that we were used to 😁

Higher Order Functions explained

Lucas Porfirio — Mon, 29 May 2023 16:54:47 +0000

Lately, I've been immersing myself in the study of functional programming. Being someone who enjoys sharing knowledge with others, I have chosen to write this article and share my current knowledge and experience.

As a web developer, it's essential to continuously study new techniques and find ways to enhance your code. Even more so in the JavaScript world, where it experiences daily changes.

One valuable technique to explore in Javascript is the utilization of higher order functions. These functions have the capability to accept one or more functions as arguments or even return a function as their output.

Within this article, we will delve into the concept of higher order functions, and some simple implementation methods.

But what is a Higher Order Function?

According to Mozilla's documentation, a function is a block of code that performs a task or calculates a value.

In JavaScript, functions are treated as first-class citizens, meaning they can be used and manipulated just like any other data type, such as strings, arrays, or objects.

Here are some examples of what you can do with functions when they are treated as first-class citizens:

Assign them to a variable.
Set them as properties of an object.
Store them in arrays.
Use them as an argument to a function or as a return from a function.

And the fouth item is exactly the definition of a Higher Order Function, which is: a higher-order function is a function that takes one or more functions as arguments and/or returns a function as its result.

Simply put, it operates on functions just like any other data type in JavaScript. And this is possible only because in JavaScript, functions are considered first-class citizens.

Passing Functions as Arguments

One of the most powerful aspects of higher-order functions is their ability to accept other functions as arguments. This allows us to abstract common functionality into reusable functions and pass them dynamically to higher-order functions.

Let's see how we can write a code that shows this using HOFs:

As you can see in the code above, we created a higher-order function called "higherOrderFunction" that performs a simple math operation on a number. By passing a separate function, like multiplyByTwo, as an argument to higherOrderFunction, we can customize the operation in our favor. In this example, the multiplyByTwo function doubles the given number. This approach helps us write more flexible and reusable code, as we can easily change the operation or even use different functions with the same higher order function.

Returning Functions

Higher-order functions can also return functions as their results. This allows for the creation of specialized functions or the generation of dynamic functions, enabling customization to suit specific contexts or requirements.
Here's an example:

In the snippet above, the createGreeting function produces a customized greeting function. This inner function combines a provided greeting message with a given name, resulting in personalized greetings. By utilizing createGreeting with various greeting messages, we can generate distinct greeting functions that can be reused to greet different names.

Built-in HOFS in JavaScript

The coolest part of learning higher order functions is definitely understanding that this is a core JS feature. Many of the built-in JavaScript functions, such as those operating on arrays, strings, DOM methods, promise methods, and others, are higher order functions that offer a significant level of abstraction to us. To name a few, we have:

Array.prototype.map()
Array.prototype.forEach()
Array.prototype.filter()
Array.prototype.reduce()

Conclusion

Higher order functions in JavaScript are a powerful tool that empowers developers to create code that is expressive, reusable, and modular. By treating functions as first-class citizens, we can pass them as arguments and even return functions from other functions, opening up the possibilities of functional programming. Understanding higher order functions allows you to enhance your JavaScript programming skills and elevate the overall quality of your code.

DEV Community: Lucas Porfirio

SOLID Principles: They're Rock-Solid for Good Reason!

What is SOLID?

1. S - Single Responsibility Principle

Issues this can cause

2. O - Open-Closed Principle

3. L - Liskov Substitution Principle

Examples of violations:

4. I - Interface Segregation Principle

5. D - Dependency Inversion Principle

Conclusion

Handling Exceptions to impress in your Tech Interview

1. Introduction

2. What We Want to AVOID

3. Refactoring 1: Creating Exceptions

4. Design Patterns: Factory Pattern

5. Refactoring 2: Refining the Exceptions

6. Conclusion

Improving Laravel's Queue Performance

Understanding the Problem

Solving This Problem

Conclusion

From XMLHttpRequest to Fetch API: How Fetch became the Way Forward for JS Development

Hello there ✌

Drawbacks of XMLHttpRequests

Simplicity of the Fetch API

Community adoption

Conclusion

Unlocking the Potential of Async in JavaScript

Syntax

And what about the .catch?

And when to use it?

Conclusion

Higher Order Functions explained

But what is a Higher Order Function?

Passing Functions as Arguments

Returning Functions

Built-in HOFS in JavaScript

Conclusion

And what about the `.catch`?