DEV Community: Lukas Heller

It's okay to use Laravel's Database Queue Driver in Production

Lukas Heller — Tue, 05 Mar 2024 20:30:31 +0000

For years, I've relied on the Database Queue Driver for small and mid-sized Laravel applications, despite a persistent whisper in my ear warning me, "Taylor Otwell himself says it was not intended for production."

This cautionary statement has made its way around the community and has continued to pop up in Reddit threads and Twitter conversations over the past few years. And I had memorized it too.

So I was a bit surprised when Taylor casually mentioned in one of the recent Laravel Podcast episodes that queues in the database "have become more and more robust, so you can actually use the database driver for queues in production."

It turns out that this is not actually news from 2024, but has not been as much of a problem for several years as it was in 2016. Mohammad Said, a former Laravel employee and an expert on the queuing system for Laravel, already addressed this in 2021

I didn't know anything about this. Obviously I didn't recheck what I had remembered. And so I still had a bad feeling when I relied on the database driver in production scenarios.

Just because something works "out of the box" and is considered production-ready does not, of course, mean that it is always the optimal choice. For many applications, a robust solution like Redis might be better suited. However, the realization that the database driver is a viable option is a significant revelation.

So, this isn't groundbreaking news, but maybe I'm not the only one who missed this information or you still have this false impression. For my part, I am glad that I can now use the database driver for queues for smaller applications without any stomach ache.

Storing classes with user configurable parameters in the database (with Laravel)

Lukas Heller — Mon, 12 Feb 2024 09:43:52 +0000

In a current Laravel-based software project I'm developing, I was confronted with a small challenge that kept me thinking more than perhaps it should have: how to efficiently store an "abstraction" of certain classes in the database, combined with user-configured inputs, to later instantiate the corresponding class with the correct parameters. Although I searched through existing solutions, I could not find one that met the requirements.

Imagine the following: Users can choose from some actions such as "SendEmail" or "AssignEmployee" to be executed when certain events occur. Each action requires certain inputs, e.g. email addresses or employee IDs. How can this data be stored elegantly and the associated tasks, each of which has its own class, executed precisely with the right parameters?

At first glance, serializing and storing a class with the correct properties from the user input seems to be a straightforward solution. However, it requires a number of somewhat unwieldy steps downstream. I have also seen approaches to use DataTransferObjects to store the values configured by the user and then extend the DTOs with business logic. But even though this approach works quite easily, it seemed wrong to combine these things.

So I've tried to find my own solution...

The Initial Approach

Serialization appeared as an initial contender. However, there are two key points that I felt were not ideal.

A) Updating Configured Parameters: Modifying user-configured parameters proved to be a bit cumbersome, requiring deserialization, property updates, and serialization — a rather tedious process.

B) Hardcoded Namespace: Any changes in namespace would render the serialized data unusable — an inflexible solution.

Readability of the stored data aside, While serialization may suffice for one-off actions, something that may be performed once, and the record will be removed from the database. But to me it falls short when data longevity and flexibility are more crucial.

A Refined Approach

To address these challenges, I explored alternatives. Storing just the class name and a JSON-encoded array of parameters within the database emerged as a promising alternative. But how to automate class initialization with the correct parameters?

Handling (typed) constructor properties

I use typed constructor properties for these user-configurable classes, so they can be reused and make it obvious what’s required to create an instance. But that's why I can't just throw a "$params" array into the constructor. So I opted for a static creation method like "fromArray" which will take care of creating a new instance with array values, to streamline instantiation, while still providing clarity by the expected constructor inputs.


class SendEmailAction {
    public function __construct(
        protected string $toEmail
    ){}
    public static function from Array(array $params){
        return new self(
            toEmail: $params['email']
        );
    }
}

For the sake of readability the code snippets will only contain the very basic information required. Of course error handling or validation should be improved in a real world situation.

Enum-Based Resolution

To eliminate hard-coded namespaces in the database, I used enums to decouple stored action names from class namespaces. By storing enum values in the database and dynamically resolving the corresponding class names, I have eliminated namespace dependencies and improved scalability.

enum ActionClassOptions: string {
    case SendEmail = 'send_email';
    // …    
    public function getClass(){
        return match($this) => {
            self::SendEmail => SendEmailAction::class
        }
    }
}

Storing the data

Since I didn't want to create an additional database table just for this purpose, I decided to store all this data in a json column. I think this is a fair solution, especially since the data is not queried. However, storing it in a normalized database table can be beneficial in other cases as well.

So, for my Laravel project I had to add a new json column to the migration and a cast definition to the model:

class User extends Model {
    protected $casts = [
        'configured_actions' => 'array'
    ];
}

The data stored in this JSON column is simply a string for the action (from the backed enum) and an array of parameters.

$user->configured_actions = [
    [
        'action' => ActionClassOptions::SendEmail,
        'params' => [
            'email' => 'foo@bar.com'
        ]
    ],
    [
        'action' => ActionClassOptions::AnotherOption,
        'params' => [
            'employee_id' => 'some_id'
        ]
    ]
];

Now, all that remains is to instantiate the actions with the correct data when the time comes. For this, I added a getConfiguredActions() method to the model (but this could be any kind of service class), returning executable instances of the action classes:

public function getEventActions() {
    return array_map(function($actionData){
        $actionOption = ActionClassOption::tryFrom(
            $actionData['action']
        );
        return $actionOption->getClass()::fromArray(
            $actionData['params']
        );
    }, $this->configured_actions);
}

Alternative Solutions?

Even though my solution somehow sufficiently addresses the challenges encountered, I am interested in exploring alternative approaches. I'm sure there are a lot of other and probably better ways to solve this problem, as this issue is not limited to Laravel or even PHP.
And maybe I'm just overthinking it?
Have you ever encountered a similar situation in your projects? What solutions did you choose?

Postman pre-request scripts for authenticated API Development

Lukas Heller — Wed, 07 Apr 2021 07:10:58 +0000

This is something I recently discovered and found very useful in my daily work so I think it's worth sharing.

Currently I'm locally developing an JSON API. It's build with Laravel, which doesn't really matter within this context, as this post about the API and Postman.
A key characteristic of this API is most endpoints are only accessible for authenticated users, which I guess, is a common thing. The authentication system itself is using a bearer token.

Of course every API developing client provides an easy way to set the required headers easily, so does Postman:

But as a project grows, the amount of preconfigured requests grows.
That's where environment variables might come into play as a very handy tool. It's an easy way to e.g. provide the access token once for a collection of requests. So you only have to change a single, central variable for all requests that are configured to use the environment variable as its Bearer Token.

The problem

But as matter of fact, within the current stage of development I am in need to reset my database multiple times a day and it gets seeded with fresh data each time.
While doing this, my access token gets invalid so I need to go back to my login route, make a login request, copy the returned access token and store it in my environment variables.
This might not sound like much, but it can be annoying and is something that holds me back from resetting and reseeding my database. Something a developer should not be afraid of in my opinion.
Until I got behind the use of pre-request scripts for this kind of tasks.

Utilizing pre-request scripts

Postman provides this awesome feature of performing any scripts before actually sending the actual configured request.
By setting up an easy request to check if my currently stored access token from the environment variables is still valid, I'm able to handle the resetting of it completely behind the scenes.

First of all, I'm making a basic request to check if my access token stored in the environment variable is still valid by accessing a route which definitly needs authentication.



// checking if we are logged in 
pm.sendRequest({
    url: 'https://api.yourproject.test/v1/auth/check',
    method: 'GET',
    header: {
        'Accept': 'application/json',
        'Authorization':  'Bearer ' + pm.environment.get('access_token')
    },
})

If my access token is still valid everything is fine and it will carry on with the actual request.
But if it's not I can use a callback to send another request which will sign me back in and update the returned access token within my environment variables.



// ...
}, function (error, response) {
 if (response.code === 401) {
     // Unauthorized. Log in the user
        pm.sendRequest({
            url: 'https://api.yourproject.test/v1/auth/login',
            method: 'POST',
            header: {
                'Accept': 'application/json',
                'Content-Type': 'application/json'
            },
            body: {
                mode: 'raw',
                raw: JSON.stringify({ 
                    email: "user@user.com", 
                    password: "password" 
                })
            }
        }, function (error, res){
            if(!error){
                // Login Successfull. Update access token
                var data = res.json();
                pm.environment.set("access_token", data.access_token);

            } else {
                console.log(error);
            }
        });
    }
})

The complete script may look like this:



pm.sendRequest({

    url: 'https://api.yourproject.test/v1/auth/check',

    method: 'GET',

    header: {

        'Accept': 'application/json',

        'Authorization':  'Bearer ' + pm.environment.get('access_token')

    },

}, function (error, response) {

    if (response.code === 401) {

        pm.sendRequest({

            url: 'https://api.yourproject.test/v1/auth/login',

            method: 'POST',

            header: {

                'Accept': 'application/json',

                'Content-Type': 'application/json'

            },

            body: {

                mode: 'raw',

                raw: JSON.stringify({ 

                    email: "user@user.com", 

                    password: "password" 

                })

            }

        }, function (error, res){

            if(!error){

                var data = res.json();

                pm.environment.set("access_token", data.access_token);

            } else {

                console.log(error);

            }

        });

    }

})

Drawbacks

A drawback might be, that this lowers the time required to perform a request a little bit, because we are actually performing multiple requests (at leaste two) behind the scenes.
But this is pretty much neglectable, as it's probably only noticeable when running a complete collection of requests and not just a single one.

In my opinion, the advantages clearly outweigh the disadvantages in this case.

Quickly ignore .DS_Store files globally

Lukas Heller — Thu, 12 Nov 2020 13:50:46 +0000

A global .gitignore file is a very useful thing - if you use one. Personally i didn't, until recently. But there is one special file that allways bothered me in my workflow: .DS_Store
For this post, it doesn't matter what these files are or why they exist. What matters is that these small files are annoying because they are often created and committed without notice.

So here's a quick one-line command solution for anyone, who doesn't use a global .gitignore yet.*

TL:DR

git config --global core.excludesfile "~/.gitignore" &&  echo .DS_Store >> ~/.gitignore

Explanation

This command

configures the path to a global exclude file (we'll just call it .gitignore, but it could also be .global_gitignore or somehting else) to the home directory (~/), where your global .gitconfig usually resides too.
then this new .gitignore file is created in your home folder (if it doesn't already exists) and a new line with .DS_Store is appended.

*If you are already using a global .gitignore, i'll assume that you are already ignoring these type of files globally. If not - please do so, as it should not be necessary to ignore these an a per project basis.

Heres a quick gist if you want to bookmark this command.