Forem: Akshit Arora

Top 5 things a Framework is NOT responsible for!

Akshit Arora — Wed, 02 Aug 2023 12:49:22 +0000

We often complain that an XYZ framework is slow, made my application crappy, or even claim that the Framework won't be able to handle the high traffic! So, is a framework guilty for the allegations we put on it?

We always use Programming Frameworks to make development an easy job. But we must understand that frameworks are here to make our job easy, that's it. So, let us understand what framework is NOT responsible for.

1. Security

Yes, Frameworks do provide security at various points like making your files inaccessible directly and sanitising inputs. But, ultimately it's our responsibility to make sure everything remains secure. Making folder permissions to 777 or Disabling security features of Framework just because iT's aNnOyInG! 🙄 will lead your application to destruction no matter what cutting-edge framework you use! 🤷‍♂️

2. Application Speed

Application speed depends on the System on which the application is loaded, the traffic on the system and how optimised your code/database is to handle the traffic/host. Even the benchmark tests give you a response speed in milliseconds. If your application is taking 2 minutes to load the page, it's you! Not the framework.

3. Optimisation

There's a Kaplan's law:

Give a boy a hammer and everything he meets has to be pounded

Frameworks provide you with a lot of tools. That doesn't mean that you have to use them all to get your things done! If the new shiny feature you are using is taking a lot of resources, just skip it. Not every feature is worth using. It depends on your problem statement. True optimisation lies only in using the right method at the right moment.

4. Extensibility

Writing extensible apps are totally in the hands of the developer. Frameworks always provide extensibility out of the box. That is why we can build our code on them. But we have to make sure that whatever we are building, must be extensible. Pro-Tip: To excel in creating extensible applications, get your basics of OOPs cleared and practice SOLID principles.

5. Errors and exceptions

Frameworks can provide you with great debugging and testing tools. But, It is we, the developers who have to make sure that our code has no errors and all the possible exceptions are properly managed.

So, if you're ditching a framework because of any of the above-mentioned issues, think again...

Happy Coding!

Laravel: How To disable Login for deactivated user?

Akshit Arora — Sun, 12 Mar 2023 15:49:37 +0000

There are cases where you just need to "Deactivate" (Not delete) the user. The use case may also be to block access temporarily for someone.

Initial steps

Add a column in the user table where you can manage the user activation status. Keeping the column name is_active as of now.

php artisan make:migration add_is_active_to_users_table

Add the column in migration file's up() and down() functions as required.

public function up()
{
    Schema::table('users', function (Blueprint $table) {
        $table->boolean('is_active')->default(1);
    });
}

public function down()
{
    Schema::table('users', function (Blueprint $table) {
        $table->dropColumn('is_active');
    });
}

Run the migration

php artisan migrate

Authenticating user

To check if the user is active along with their credentials, Check out the Laravel documentation to manually authenticate the users and simply add the required column's information in the $credentials variable in the authenticate() function of LoginController.php

$credentials = $request->validate([
    'email' => ['required', 'email'],
    'password' => ['required'],
]);

$credentials['is_active'] = 1;

That's it! You're done! The user will not be able to login into the application if their is_active value is false/0.

But, What about the Middleware way?

When I was implementing this functionality, I found several blogs online which suggest creating the Middleware and checking your user there (Like this and this). But I found a flaw in this approach.

The flow goes like this:

The deactivated user tries to log in
The user gets authenticated successfully,
The request goes to the Middleware.
Middleware checks if the user is deactivated
Middleware finds the user as deactivated, it logs out the user

In this flow, the Illuminate\Auth\Events\Authenticated event will still get triggered as the deactivated/blocked user tries to log in. This should not be the case. The event that should be triggered is Illuminate\Auth\Events\Failed .

The catch:

If you follow the Laravel way, it will simply show the user a generic message same as when the credentials don't match as per our records. But in the middleware example, you can inform the user that you've been blocked.

So, should we follow the middleware approach if we want to notify the user that you're blocked?

I would still not recommend it as this flow is not as per how the Authentication works. We have to use the attemptWhen functionality for additional conditions and setting up custom flash messages if required. Please check Laravel's documentation here for more details. This functionality with examples may be covered later in another blog.

How to log your heavy database queries in your Laravel project?

Akshit Arora — Sun, 18 Sep 2022 17:23:50 +0000

I work in data intensive Laravel based applications. So, the biggest problem occurs as your application grows is that your application getting slowed down. Or, sometimes, the client keeps on saying that application is running slow, but it is just one query that only client is running (and God knows why and from where!).

This is a common scenario when your application starts to age, the database keeps getting heavy, and somewhere, that new guy added a database query which was not optimized at all!

Then we need to start the debugging process and check what went wrong! Just to overcome such a problem, (and taking this as an excuse to start my open source contribution journey), I built a Laravel package to help me track down such heavy queries. I named it as DBLog

Just another Database Logger?

Well... Not actually. I found some great logging tools already available for Laravel. One of my favorite was Laravel Query Logger. But, I needed some more feature from that.

Why DBLog?

Track the slow queries.: Track slow queries in the log files. (Common feature, I know)
Track queries on triggers: Inspired from Laravel Query Logger. Only log the queries based on the triggers.
Get the page from which the query ran!: Again, inspired from Laravel Query Logger, I must know the page which is running slow, not just the slow query.
Duration Bifurcated Logs: That's a unique feature I wanted. Just logging the slow queries was not enough, sometimes, we need to know the queries which were really slooooow. So, just set up the time brackets and it will log the query based on the time taken. Now, I have the logs of the queries which needs immediate attention and then going down the duration list.
Datewise Logs:

Client: Hey! I ran this page last week, can you please check that page why was it slow? It's running good today though!

A very common dialog we hear! That feature, just because of that. I don't have to search a single 10 MB log file which contains queries from the past 6 months. I just need to find that date logs and check out the issues. :)

So, I just started my journey to the open source contribution, (finally!!) I really hope that I can be at the service for the community. Please check the package on this Github Link and try it once. I appreciate your reviews, feedback and criticism on it. :)