Forem: Hesam Rad

How to Bring ChatGPT into Your Laravel Application?

Hesam Rad — Thu, 02 Nov 2023 16:06:40 +0000

Recently, I've been seeing a lot of developers trying to integrate ChatGPT into their web application and seem to be confused about it; so I decided to create a package that simplifies the process of integrating ChatGPT into a Laravel application.

Let's see how it works.

The only thing you need to worry about is the API key from openAI website; apart from that, everything else is taken care of.

Click here to generate your own API key.

Ok! Now that you have your API key ready, let's install the package.

composer require hesamrad/laravel-chatgpt

Then, publish the configuration file:

php artisan vendor:publish --provider="HesamRad\LaravelChatGpt\LaravelChatGptServiceProvider" --tag="chatgpt-config"

And lastly, head over to your .env file and paste your API key so that the package can use it to connect to ChatGPT:

CHATGPT_API_KEY="{YOUR-API-KEY}"

And you're done! How easy was that? You now have ChatGPT inside your application.

Wanna try?

There are a couple ways to use the package to connect to ChatGPT.

Method #1 - Using built-in routes.

The package comes with a built-in route so you can send a request from anywhere inside your client application; whether it's a separate JavaScript-powered front-end, or anything else.

Simply send a POST request to /api/chatgpt/ask with a body parameter question to get your answer.

Method #2 - Using global helper function.

There is a chatgpt() global helper function which takes one parameter as the question you want to ask. You could use this method anywhere you like.

If you want to use this package inside any controller you could go about it like this:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Http\Response;
use App\Http\Controllers\Controller;

class ImaginaryController extends Controller
{
    /**
     * This method connects to ChatGPT servers
     * and asks the given question.
     *
     * @param  string  $question
     * @return \Illuminate\Http\Response
     */
    public function ImaginaryMethod($question)
    {
        $answer = chatgpt($question);

        return response($answer, Response::HTTP_OK);
    }
}

I think this is a very simple but useful package for developers who just want to use ChatGPT without having to deal with its implementation.

I will certainly add more details to the package and update this post; but I would really appreciate it if you'd be so kind to drop a star on its GitHub repository.

Feel free to give me more ideas to implement on this package; I'd love nothing more than to contribute to the open-source community.

Cheers!

Developing Quality API with Laravel - Tip #4

Hesam Rad — Sat, 03 Jun 2023 19:20:38 +0000

Tip #4 - Create a consistent response structure.

What do I mean by this?

I've been developing APIs for the better part of my career, and there is nothing more annoying than an API with an inconsistent structure.

Sometimes it returns a status_code, sometimes it doesn't! Believe me, I've seen it; and they were not dummy APIs, they were very well known and publicly used, but since there was no other alternatives, people couldn't switch to a better one.

So I thought to myself, if I want to see some changes, why not start it myself?

I started thinking, there SHOULD be a rule, or a convention to suggest a structure for web APIs. I searched for it and found RFC-7808.

But wait, RFC-7807 is only for error reporting side of an API, what about the time when there are no errors? What about that structure?

I couldn't find a good answer to this question, and frankly I got tired of searching the web for something that apparently doesn't exist.

So I wore my engineering hat and started thinking.

I wanted to come up with a structure for APIs that could handle both error and non-error responses and after a bit of thinking, I came up with this:

{
  "status": null,
  "title": null,
  "detail": null,
  "data": [],
  "errors": []
}

Let me explain:

status: The HTTP status code sent from the server, ranging from 1xx to 5xx.
title: A general, human-friendly message to show to the client.
detail: A specific, human-friendly message explaining the situation in finer detail.
data: The data that is fetched from the server to be displayed to the client.
errors: An array of errors with a specific message explaining the error.

Think about it; not only it supports errors, but also, it supports non-error responses. Right? So the structure would never change inside the API. That's cool.

Let's see some examples:

Let's say you want to see a list of all the products in your web shop:

{
  "status": 200,
  "title": "Data successfully fetched.",
  "detail": null,
  "data": [
    {
      "id": 1,
      "name": "Some Imaginary Product",
      "price": 10,
      "currency": "USD"
    },
    {
      "id": 2,
      "name": "Another Imaginary Product",
      "price": 15,
      "currency": "USD"
    }
  ],
  "errors": []
}

Or maybe when you want to create a new product for the web shop:

{
  "status": 201,
  "title": "Record successfully created!",
  "detail": "A new product was added to the web shop.",
  "data": [
    {
      "id": 1,
      "name": "Some Imaginary Product",
      "price": 10,
      "currency": "USD"
    }
  ],
  "errors": []
}

What about when you fail to send valid data to create a product?

{
  "status": 400,
  "title": "Request failed!",
  "detail": "Request parameters did not pass validation tests; please fix them and retry again.",
  "data": [],
  "errors": {
    "name" : "Field `{name}` is required.",
    "price" : "Field `{price}` needs to be an integer."
  }
}

What do you think? Is this a reliable structure? Could you think of any problems with it?

I may publish this idea as a third party package on GitHub (if it's any good); I've applied to one of my projects and so far it holds up pretty good.

I'm looking forward to hearing from you and improving this idea.

Link to cover image

Developing Quality API with Laravel - Tip #3

Hesam Rad — Sat, 04 Jun 2022 09:44:15 +0000

Tip #3 - Extract all your constant values (non-variables) into one config file.

What do I mean by this?

Imagine a scenario where you're developing an API for an e-commerce application. There is going to be model named Product in this application and you (the back-end developer) have to make queries to fetch those products and send them to the front-end client. It would be something like this:

/*
 * Return a list of available products.
 *
 * @return Collection
 */
public function index()
{
    return Product::query()
        ->where('available', true)
        ->paginate(20);
}

And later down the road you have to make another query to fetch all Payment records in your system and it would look like this:

/*
 * Return a list of successful payments.
 *
 * @return Collection
 */
public function index()
{
    return Payment::query()
        ->where('status', 'successful')
        ->paginate(20);
}

And there is NOTHING wrong with this.

I am here to suggest a way to make your codebase cleaner and more maintainable in case of future changes.

Let's say you have around 50 controllers in your Laravel application and all the index methods are returning a collection of 20 items. Imagine if the clients asks you to return only 10 items instead of 20. Now you have to go through all 50 controllers and change ->paginate(20) into ->paginate(10). It's pretty easy right?

If you're using vscode or phpstorm you could ctrl + shift + f to find and replace every ->paginate(20) with ->paginate(10) and your job would be done in a matter of seconds. But that's not a nice way.

This is what I would do and suggest you do as well:

I would create a file called constants.php inside Laravel's config file and put everything I use through out the application inside it:

<?php 

/**
 * Every constant that is used through out the application is 
 * defined here.
 * 
 * Note that if you're caching your application's configuration 
 * you should clear it after each modification to see the change.
 * 
 */

return [

    /*
    |-----------------------------------------------------
    | Items to Paginate
    |-----------------------------------------------------
    | Number of records to paginate in each query.
    |
    */
    'items_to_paginate' => 20,

    //and many other things...
];

Looks clean, right?

Now I would change my controllers like this:

/*
 * Return a list of available products.
 *
 * @return Collection
 */
public function index()
{
    return Product::query()
        ->where('available', true)
        ->paginate(config('constants.items_to_pagiante'));
}

Now if client wants me to change the number of paginated items, I could change one value inside my config file without touching my controllers and the whole system would change with that.

Now this feels clean, right?

Note
Of course you can add as many values as you want. This is not just for pagination. I, personally have a lot of values in my constants.php file; so the usage is up to you.

One more thing, if you're caching your application's configuration you should clear it after each modification to see the change.

Last Words
Hope you found this tip helpful. If you have any suggestions for future tips, please comment down below. I'd be more than happy to get in touch with you.

Link to cover image

Developing Quality API with Laravel - Tip #2

Hesam Rad — Mon, 14 Feb 2022 14:43:45 +0000

Tip #2 - Divide Major Route Groups in Specific Files

What do I mean by this?

Imagine a scenario where you are developing a complex API which has different consumers with different route groups.

It is 100% ok to keep all the routes in api.php file under routes directory; but you know me, I'm looking for a cleaner solution.

As a backend developer, I tend to spend some time searching through routes to do something like debugging, logging and all other sort of things.

It is going to get really painful to find the exact route you're looking for if you have +1000 routes, right?

What I would suggest to do is dividing each major group into their specific files and then include said files in your api.php file.

Let's see an example.

//This is routes/api.php

/*
 * Api version 1 routes.
 * 
 * All v1 routes of the application live here.
 * 
 * 
 */

Route::prefix('v1')->group(function () {

    /*
     * Authentication routes.
     * 
     * 
     */
     Route::prefix('auth')->group(function () {
        Route::get('/route-1', [SomeController::class, 'method-1']);
        Route::get('/route-2', [SomeController::class, 'method-2']);
        Route::get('/route-3', [SomeController::class, 'method-3']);
        Route::get('/route-4', [SomeController::class, 'method-4']);
        Route::get('/route-5', [SomeController::class, 'method-5']);
        //...
    });

    /*
     * Admin routes.
     * 
     * 
     */
     Route::prefix('admins')->group(function () {
        Route::get('/route-1', [AnotherController::class, 'method-1']);
        Route::get('/route-2', [AnotherController::class, 'method-2']);
        Route::get('/route-3', [AnotherController::class, 'method-3']);
        Route::get('/route-4', [AnotherController::class, 'method-4']);
        Route::get('/route-5', [AnotherController::class, 'method-5']);
        //...
    });
});

It's seems ok now, right? But is it going to be ok two years from now? What about when there is a version 2 or 3 for this API?

I can see routes piling up and making it harder for us to work with them.

So what can we do to avoid a messy routes file and keep things clean?

This is what I do in my own projects.

I would create a folder inside routes folder and name it the same as the API version I'm developing.

- app
- bootstrap
- config
- database
- public
- resources
- routes
    + v1              <--- This is that folder
    + api.php
    + channels.php
    + console.php
    + web.php
- storage
- tests

And then I would extract major route groups in their respective files.

Following the above example, I extract all authentication routes and store them in a new file called auth.php under routes/v1 folder that I just created.

//This is routes/v1/auth.php

/*
 * Authentication routes.
 * 
 * 
 */
 Route::namespace('Auth')->group(function () {
    Route::get('/route-1', [SomeController::class, 'method-1']);
    Route::get('/route-2', [SomeController::class, 'method-2']);
    Route::get('/route-3', [SomeController::class, 'method-3']);
    Route::get('/route-4', [SomeController::class, 'method-4']);
    Route::get('/route-5', [SomeController::class, 'method-5']);
    Route::get('/route-6', [SomeController::class, 'method-6']);
    Route::get('/route-7', [SomeController::class, 'method-7']);
    //...
});

I would follow this approach until there are no routes left in the api.php file.

Then I end up with something like this:

- app
- bootstrap
- config
- database
- public
- resources
- routes
    + v1
        * admins.php  <--- All admin routes
        * auth.php    <--- All authentication routes
    + api.php
    + channels.php
    + console.php
    + web.php
- storage
- tests

Now that we have extracted all the routes in their respective files, it's time to declutter our api.php file.

//This is routes/api.php

/*
 * Api version 1 routes.
 * 
 * All v1 routes of the application live here.
 * 
 * 
 */

Route::prefix('v1')->group(function () {

    /*
     * Authentication routes.
     * 
     * 
     */
    Route::prefix('auth')->group(function () {
        require_once(__DIR__ . '/v1/auth.php');
    });

    /*
     * Admins routes.
     * 
     * 
     */
    Route::prefix('admins')->group(function () {
        require_once(__DIR__ . '/v1/admin.php');
    });
});

Much better now!

It certainly is cleaner and a lot less intimidating for newer developers who join our team.

Now every time that I want to check a route, I ask myself, which group was this route in? As soon as I answer this question, I'm already done! I can look inside the respective file and find that route with ease.

Note
This little tip can be applied to all projects, but if your project has less than 100 routes, you might not want to go though all this trouble to make things cleaner. Keep things simple and it'll be fine.

Last Words
Hope you found this tip helpful. If you have any suggestions for future tips, please comment down below. I'd be more than happy to get in touch with you.

Link to cover image

How does TLS handshake work?

Hesam Rad — Sun, 13 Feb 2022 04:19:50 +0000

Ever wondered what happens when you request a website?

Sure there are many many things happening behind the scenes and it will take forever if I wanted to explain all of that in one article, but I can take each step at a time and try to explain what happens in each step.

Ready?

In today's world, using HTTPS is no longer an option. It's a necessity and everyone should use it, but how does it work? What is this secure version of HTTP that everyone is talking about?

Ok, relax and sit back down and listen to me.

We all know that HTTPS is the 'secure' version of HTTP. Duh! The 'S' at the end of it says it all. Of course everyone knows that. But we are here to take a little peak behind the curtain and see what's happening in the dark.

There is a specific chain of events that are happening when a TLS handshake occurs:

ClientHello
ServerHello
Authentication
The Premaster Secret
ClientFinish
ServerFinish

Let's break them down one by one.

ClientHello

First the client sends a Hello message to the server indicating that it wants to initiate a TLS handshake.
This Hello message includes which TLS version the client supports, the cipher suites supported, and a string of random bytes known as the client random.

ServerHello

Then the server replies with a Hello message of its own indicating that it's ready to create the handshake.
This Hello message includes the server's SSL certificate, the server's chosen cipher suite, and the server random, another random string of bytes that's generated by the server.

Authentication

Now the client tries to verify the server's SSL certificate with it's issuer to make sure of its validity.

The Premaster Secret

Now that the client has successfully verified that the SSL certificate is valid, it will generate one more random string, and encrypts it with the server's public key that it obtained from the SSL certificate in step #2 and sends it to the server.

ClientFinish

The client is now ready to finish the process of handshake. It will send a Finish message encrypted with the premaster secret to the server.

ServerFinish

To finish the process, the server will send an encrypted Finish message to the client, indicating that the handshake is now complete.

After this process, the client and the server can safely exchange messages.

Link to cover image

Log HTTP Requests in Laravel.

Hesam Rad — Sun, 30 Jan 2022 05:40:30 +0000

I just finished releasing a new package for Laravel and wanted to share with you first.

It's called Flashlight and it's a package for logging HTTP request in a Laravel application.

It is highly customizable and easy to install.

All you have to do is download it and add it to the routes you want to log and monitor.

Here's a link to its Github repository.

I hope it is useful for you.

If you had any questions regarding how it work, how I built and so on, I'll be more than happy to help you.

✌

Developing Quality API with Laravel - Tip #1

Hesam Rad — Sun, 18 Jul 2021 15:39:29 +0000

Developing quality API is one of the most important factors in an application's success. In this series I try to bring easy but helpful tips to help you develop quality APIs.

So let us begin...

Tip #1 - Do not hardcode response messages into your codebase.

What is mean by this is that you don't have to hardcode every message into the codebase. You can simply store them in a file so in case of any change so you can handle the situation with ease.

Don't do this.

return response()->json([
    'message' => 'Yo, everything is cool!'
], Response::HTTP_OK);

What if you use this piece of code in, say, 100 functions and now you want to change the message because your boss is not ok with it?

The easiest way is to ctrl + shift + f that string in vscode and replace all of it in a matter of seconds; and let's not even think about the idea of manually replacing each string ourselves.

But why do this when there's an easier and more professional way?

Let's do this instead.

Create a response.php file in /resources/lang/en folder of your Laravel project and create an array of whatever keys and values you want. But for the purpose of this article we can do this:

return [
    'successful_action' => 'Yo, everything is cool!',
];

And modify that return statement with this:

return response()->json([
    'message' => __('response.successful_action')
], Response::HTTP_OK);

Now even if there are a million of these return statements in your codebase and you want to change that message to something more appropriate you can easily change the value of successful_action key inside you response.php file and you're good to go.

Note
Please remember to return proper HTTP status code with each response you send back to front-end guys. They'll greatly appreciate it.

Last Words
If you know a better way or any tips at all, please feel free to share it with me, I'd be more than happy to learn something from you.

Link to cover image

How to take care of yourself as a developer?

Hesam Rad — Sat, 17 Jul 2021 16:45:01 +0000

Like it or not, as much as we love our job, if we don't take care of ourselves, we're not going to last long.

In this very short article, I decided to write about self-care instead of some technical issue I'm trying to fix.

There are different ways to approach this but I'm going for the easy ones. (Because we are all lazy here... no shame in that ;) )

The first thing we need to understand is that in order to have a healthy mind we first need to have a healthy body.

So how to have a healthy body?

These are the ESSENTIAL ones.

Having a good diet
Getting enough sleep
Spending more off-the-screen time
Getting some kind of exercise

And these are the OPTIONAL ones.

Meditating
Spending some time in the nature
Reading books (Duh! Not the pdf version!)
Perusing some kind of hobby

By doing these you will slowly feel the change taking place in your life.

You will feel more alive, content and you'll realize you're exactly where you're supposed to be.

Pay attention to the bold word I wrote above; you are not going to feel anything for a while after doing this. Change takes time and you have to realize that breaking the old habits and making new ones is the key to move forward.

There is no better time to be a developer than right now. So if you wanna be in this game for the long run, I suggest you start taking care of that beautiful body of yours.

Take care🖤

Link to cover image

Beautiful Code

Hesam Rad — Sun, 29 Nov 2020 21:14:53 +0000

What is art?

If I were to answer this question, I'd say that ANYTHING in its finest state is art.

Code is no different.

To me, a programmer, high quality code is the absolute form of art. Recognizing beautiful code is not a hard thing to do. Do you find it hard to appreciate Mona Lisa? NO! You just have to see it and that's it.

Again, code is no different.

So why do many of us write something just to get it to run?

These are the reasons:

The deadline is close.
The boss needs it right away.
The codebase is trash.
I'm frustrated, I just want it to be over.
I need more money so the more projects I can get, the more money.
Oh yeah! This should work. [Copying code from Stackoverflow.]

I can go on but I you get the point.

These are the scenarios which lead to low quality code.

High quality code VS low quality code

High quality code:
1. is cleaner.
2. is more readable.
3. is maintainable.
4. is faster.
5. is reusable.
6. is better!
Low quality code:
1. is NOT clean.
2. is NOT readable.
3. is NOT maintainable; and if you doubt me, ask me in 2 years!
4. is NOT fast.
5. is NOT reusable.
6. is horrible!

I know you love code, and to demonstrate my point, I brought a little piece of code that I wrote over a year ago.

It's a simple function that receives a coupon from database and marks it as used.

public function revokeCoupon(Request $request) {
    $request->validate([
        'code' => 'required | integer'
    ]);
    $code = $this->checkIfCodeIsValid($request);
    if($code) {
        $flag = $this->checkIfCodeIsNotRevoked($code);
        if($flag) {
            $order = $this->getOrderAssociatedWithCode($code);
            if($order) {
                DB::connection('my_online_shop')
                    ->table('revoke_list')
                    ->where('code' , $code->code)
                    ->update(['revoked' => 1 ]);
                return redirect()->back()->with('message' , self::SUCCESSFUL_UPDATE_MESSAGE);
            }
        } else {
            return redirect()->back()->with('warning' , self::CODE_ALREADY_REVOKED);
        }
    } else {
        return redirect()->back()->with('error' , self::NO_SUCH_CODE);
    }
    return redirect()->back()->with('error' , self::UNSUCCESSFUL_UPDATE_MESSAGE);
}

Oh humanity! How could I have written this? This is exactly what I was referring to as low quality code.

So I decided to make it better.

public function revokeCoupon(Request $request) {
    $request->validate([
        'code' => 'required | integer'
    ]);

    $code = $this->checkIfCodeIsValid($request);
    if(!$code) {
        return redirect()->back()->with('error' , self::NO_SUCH_CODE);
    }

    $flag = $this->checkIfCodeIsNotRevoked($code);
    if(!$flag) {
        return redirect()->back()->with('warning' , self::CODE_ALREADY_REVOKED);
    }

    $order = $this->getOrderAssociatedWithCode($code);
    if(!$order) {
        return redirect()->back()->with('error' , self::UNSUCCESSFUL_UPDATE_MESSAGE);
    }

    DB::connection('my_online_shop')
        ->table('revoke_list')
        ->where('code' , $code->code)
        ->update([
            'revoked' => 1 
        ]);
    return redirect()->back()->with('message' , self::SUCCESSFUL_UPDATE_MESSAGE);
}

I KNOW! I KNOW! It's still too long and it breaks the SOLID. I just wanted to get rid of all the nested if statements to make it a little cleaner.

Next step was to get rid of the validation. I'm not going to go over the details of the process because that is topic for another post. (Click for more details.)

public function revokeCoupon(RevokeCouponRequest $request) {

    $code = $this->checkIfCodeIsValid($request);
    if(!$code) {
        return redirect()->back()->with('error' , self::NO_SUCH_CODE);
    }

    $flag = $this->checkIfCodeIsNotRevoked($code);
    if(!$flag) {
        return redirect()->back()->with('warning' , self::CODE_ALREADY_REVOKED);
    }

    $order = $this->getOrderAssociatedWithCode($code);
    if(!$order) {
        return redirect()->back()->with('error' , self::UNSUCCESSFUL_UPDATE_MESSAGE);
    }

    DB::connection('my_online_shop')
        ->table('revoke_list')
        ->where('code' , $code->code)
        ->update([
            'revoked' => 1 
        ]);
    return redirect()->back()->with('message' , self::SUCCESSFUL_UPDATE_MESSAGE);
}

Much cleaner!

I could have done more and cleaned those functions a bit more but I was satisfied with the results; So I saved the code and pushed it to my gitlab.

As you can see this last version of the code is certainly better than the first version, more readable and maintainable.

Now that you know the benefits of high quality code, you might be asking how to write such code? Am I right? If so, let's get to it.

How to write high quality code?

There are actually to sides to this:

The non-technical side
The technical side

The non-technical side

In order to write good code you need to develop a few characteristic traits.

Patience. Let's face it; we are going to fail. If you wanna give up after a few times, you better change you career! I'm just being honest. Software engineering is a field in which you have to solve a problem you have never solved before.
Passion. I found that being passionate about something can make you tireless and undefeated and this can get you anywhere you want in this world.
Persistence. Remember, it doesn't matter that you have failed
1000 times, I only has to work once! So code again.

The technical side

Ok here's the part you've been waiting for. To write high quality code you need to follow these simple rules.

Pay attention to your variable/method names. revokeCoupon is way better that my_cool_function.
Sometimes it's better to consider the false side of your if condition because that might make you code easier to understand; for example:

//textbook
if($condition) {
    return $jobNumberOne
} else {
    return $jobNumberTwo
}

//using this tip
if(!$condition) {
    return $jobNumberTwo
}
return $jobNumberOne

Don't repeat yourself when coding. This is actually a famous principle also known as DRY!
Split up long functions into shorter functions. I'm happy that I knew this tip back when I was writing that nightmare in the beginning of the post. Imagine if it was just one long function! Gosh!

These were a few simple rules to get you started. I'll try think of more ways to share with you.

If you have your own ways of clean coding, I'd be more than happy to know about them.

Until the next post, take care 🖤

Link to cover image

Database indexing in Laravel - Everything you need to know

Hesam Rad — Fri, 27 Nov 2020 12:37:25 +0000

Imagine this

You're a high school student and you're assigned a project in which you need calculate the mass of the Earth and you're not allowed to use the internet. The only resource available to you is the school's old library; plus you need to hand in the results in 2 hours!

So you head to the library as fast as you can to start working on your project. As you organize your desk an idea pops into your head that can easily find the answer you're looking for; but in order to use that idea you need one complicated math formula which you forgot.
So what do you do? Of course! You start looking for that formula in the books!

Since it's an old library and there are no indexes to use you start from the very first aisle an go through each book page by page!
After a couple hours you find the formula you were looking for. Great! But wait a second. You look at your wristwatch and realize you're out of time.

What a shame.

If only the library had indexes for each aisle and each book you would've found the formula much faster and would've got an A on the project!

Point of the stroy

The point of the story is that when there are no indexes on the database you data retrieval can take a LOT of time and this will result in users leaving your website/application.

You might be wondering how exactly database indexes are related to book indexes?

Well, did you know that the idea of database indexing came from book indexing? and did you know that database indexes work exactly like book indexes?

There's the answer you were looking form

So what is a database index?

Let's ask wikipedia

A database index is a data structure that improves the speed of data retrieval operations on a database table at the cost of additional writes and storage space to maintain the index data structure. Indexes are used to quickly locate data without having to search every row in a database table every time a database table is accessed.

Now that we know what an index is, how can we use it in our database?

As always there are a couple ways to do this:

Way no. 1 - Using migration files

This is probably is easiest way to add an index inside a table. The only thing you need to do it to add the code inside your migration file and then migrate the table. That's it.

Let's have a look.

Schema::create('comments', function (Blueprint $table) {
    $table->increments('id');

    //column we want as an index
    $table->integer('post_id')->unsigned();
    //defining the index
    $table->foreign('post_id')->references('id')->on('posts')
        ->onDelete('cascade');

    $table->string("comment");
    $table->timestamps();
});

Notice that the foreign key post_id corresponds to column's name.

But that's not all of it. Behind the scenes, Laravel changes a few details so if you log into your MySQL you'll find out that the index name is not what you set in the migration file.
Laravel changes your foreign key name to comments_post_id_foreign for more clarity but there's a pattern to it:
(NameOfTheTable + NameOfTheColumn + 'foreign')

Way no. 2 - Using SQL

What if you're application is in production and you're scared you might break something with migration? or maybe you have already migrated the table? If these are the cases then this way is the way to go.

What you need to do is simply log into your MySQL database and run the following command:

ALTER TABLE `comments` ADD CONSTRAINT `comments_post_id_foreign` FOREIGN KEY (`post_id`) REFERENCES `posts`(`id`) ON DELETE CASCADE ON UPDATE RESTRICT;

Notice that we are following Laravel's footsteps in naming our index.

That's it.

By using this simple technique you can make huge difference in your application performance; but be aware that too many indexes can do more harm than good. (It can drastically slow down insert operation; more on this here.)

There might be a few more ways that I'm not familiar with. If you know any other way you're more than welcome to share it with us.

Until the next post, take care. 🖤

Laravel ORM vs Query Builder vs SQL: SPEED TEST!

Hesam Rad — Thu, 26 Nov 2020 16:01:58 +0000

Ever wondered which one of these is faster?

ORM
Query Builder
SQL

I don't know about you guys but for me this is a BIG question; so I looked into it and I decided to share what I got.

First of all, for small projects and personal blogs it doesn't matter which one you choose, because the database is not that big and either of these three will work just fine.

But what if you're working on an application or a website with a HUGE database?

This is where the answer to this question can be a game changer for you.

So let's find out.

I prepared a database with over 100,000 users and 100,000 articles assigned to each users. (Assigning articles to users was completely random and because of that some users might have 10 articles or have none assigned to them.)

It's fair to say that it's quite a big database, right? ;)

WARNING
I'm pretty sure everybody here already know this but it's worth mentioning that you should NEVER EVER try to get all the records in the database in one query.

If you unknowingly try to do so on a big database you could easily break you application.

For the purpose of this article I tried to get all 100,000 articles with their users.

Here's what happened:

See? It doesn't look good; and here's the code that caused it:



$articles = Article::with('user')
    ->get();

The reason for this exception is that the application simply ran out of ram. The database was too big that the ram couldn't handle all the rows of information.

How to avoid this?
To avoid this kind of exception you could get the data in smaller chunks. For example we could modify the code above to avoid the exception:



$articles = Article::with('user')
    ->limit(1000)
    ->get();

The limit(1000) limits the query to take only 1000 records at a time and this will keep a part of ram unused.

Ok; enough with the warning. Let's get to the good stuff.

In this example, I wrote queries that returned the same data using ORM, Query Builder and raw SQL; plus I calculated the time of execution and returned it alongside the fetched information so I can compare which one is faster.

Let's take a look.

ORM



$articles = Article::with('user')
    ->limit(1000)
    ->get();

time of execution: 0.07746

Query Builder



$articles = DB::table('articles')
    ->join('users', 'articles.user_id', '=', 'users.id')
    ->limit(1000)
    ->get();

time of execution: 0.04171

SQL



$articles = DB::select("select * FROM articles JOIN users ON articles.user_id = users.id limit 1000");

time of execution: 0.04461

To be honest I was expecting the raw SQL to be a bit faster than Query Builder but I was wrong. (I tested a couple more times to be sure.)

So there you have it. The winner of this test is Query Builder.

Of course there's another way to make each of these methods a bit faster, but that's a topic for another post.

Until the next post, take care. 🖤