DEV Community: MD Shahin Mia Robin

Workflow of Laravel Eloquent ORM behind the scenes

MD Shahin Mia Robin — Fri, 01 Aug 2025 15:16:55 +0000

Laravel Eloquent ORM is an Active Record implementation that abstracts SQL operations into expressive PHP syntax using models. Behind every Eloquent call, Laravel translates your methods into raw SQL using a layered structure of classes.

🔁 Eloquent Internal Workflow

When you call an Eloquent method (e.g., User::where(...)->first()), Laravel processes it through these core steps:

1. Model Instantiation:
Laravel bootstraps your model (e.g., User extends Model) and applies traits (like HasAttributes, HasRelationships, etc.).

2. Query Builder Initialization:
The newQuery() method returns an instance of Illuminate\Database\Eloquent\Builder, which wraps the core Illuminate\Database\Query\Builder.

3. SQL Compilation:
Query Builder methods like ->where() or ->with() are chained and eventually converted into raw SQL by the toSql() method.

4. Database Connection & Execution:
Laravel uses DB::connection() and PDO to execute the query.

5. Hydration into Models:
The raw database rows are converted (hydrated) into fully functional Eloquent model instances.

6. Model Events & Mutators:
Laravel triggers lifecycle events like retrieved, saving, etc., and applies accessors/mutators if defined.

🧪 Example 1: Query Builder

$user = User::where('email', 'jane@example.com')->first();

💡 Behind the scenes:

SELECT * FROM users WHERE email = 'jane@example.com' LIMIT 1;

Laravel executes this, then hydrates the result into a User object.

🧪 Example 2: hasOne Relationship

// app/Models/User.php
public function profile()
{
    return $this->hasOne(Profile::class);
}

// On Controller
$user = User::find(1);
$profile = $user->profile; // Auto-fetches from DB

🔍 Internally:

SELECT * FROM profiles WHERE user_id = 1 LIMIT 1;

Laravel hydrates the result into a Profile model and attaches it to the $user object.

🧪 Example 3: belongsTo Relationship

// app/Models/Profile.php
public function user()
{
    return $this->belongsTo(User::class);
}

// On controller
$profile = Profile::find(10);
$user = $profile->user;

🔍 Internally:

SELECT * FROM users WHERE id = [profile.user_id] LIMIT 1;

Again, Laravel hydrates the User result and associates it with the Profile instance.

✅ Key Takeaways:

Eloquent sits on top of Laravel's Query Builder and PDO.
Relationships like hasOne and belongsTo internally generate foreign key–based queries.
Eloquent uses hydration, events, and casting to make model objects fully interactive.
Under the hood, it’s still structured SQL, just with expressive syntax and clean abstraction.

Standardizing Git Commit Messages: The Role of Tags like wip and Beyond

MD Shahin Mia Robin — Mon, 05 May 2025 01:22:05 +0000

In modern software engineering, the clarity of your Git commit messages significantly impacts project maintainability, collaboration, and release workflows. While wip (Work In Progress) is often used to denote an incomplete task, teams should adopt standardized tags that better reflect the intent and nature of each change.

Understanding the `wip` Tag

wip is a temporary marker indicating that the commit includes unfinished work. It is useful during active development to back up code or share early drafts. However, wip commits should not be merged into main or release branches. Before merging, squash, or clean these commits into meaningful messages.

Example:

wip(ui): started implementing dashboard layout

Recommended Commit Tags and Examples

Below are the standard commit tags, widely used in the Conventional Commits specification:

feat: New feature addition
Use when adding a new capability or feature.
Example:
```
feat(auth): add JWT-based authentication middleware
```
fix: Bug fix or error resolution
Use when resolving a defect or error in the code.
Example:
```
fix(payment): resolve rounding error in tax calculation
```
docs: Documentation-only changes
Use for updates to markdown, code comments, or technical guides.
Example:
```
docs(readme): update API usage section with latest endpoints
```
style: Formatting and style updates
Use when making changes that do not affect code logic—e.g., indentation, whitespaces, or semicolon adjustments.
Example:
```
style(ui): reformat button component for consistency
```
refactor: Code refactoring
Use for structural changes that neither fix a bug nor add a feature.
Example:
```
refactor(order-service): simplify loop logic for item parsing
```
test: Adding or updating tests
Use for adding new tests or modifying existing test coverage.
Example:
```
test(profile): add integration tests for avatar upload
```
chore: Maintenance tasks
Use for routine tasks like dependency upgrades or tool configuration updates.
Example:
```
chore(deps): update laravel/framework to v10.3.0
```
perf: Performance improvements
Use for code changes that enhance performance.
Example:
```
perf(query): optimize join condition to reduce query time
```
ci: CI/CD pipeline or config updates
Use for changes related to continuous integration or deployment.
Example:
```
ci(github): add linting step to pull request workflow
```

Commit Message Structure Format

To standardize further, follow this format:
<type>(<scope>): <short description>

Where:

type = tag from above
scope = optional module or component name
description = concise message summarizing the change

Final Recommendations

Avoid leaving wip in history; squash or reword before merging.
Use tags consistently across all commits.
Validate commit messages with a Git hook or CI job for enforcement.
Maintain readability and professionalism in all messages.

A well-maintained commit history is a living logbook of a project’s evolution. Adopt structured commit standards today for long-term agility and clarity.

Note: The Article was written and the cover image generated by ChatGPT.

The Importance of Writing Meaningful Code and Documentation

MD Shahin Mia Robin — Wed, 15 Jan 2025 20:40:32 +0000

As developers, many of us believe that our primary responsibility is to understand the requirements and hastily write code to meet them. However, this is a flawed notion. Among the many responsibilities of a developer, writing proper documentation is also crucial. Unfortunately, this is often misunderstood or poorly executed. Some developers write so extensively that the core requirements or business logic get lost—a case of "using a cannon to kill a mosquito."

Simply writing line-by-line documentation doesn't automatically make your code readable. Documentation should focus only on what is essential, especially when it explains critical project requirements or business logic. This doesn't mean you should neglect documentation entirely for straightforward cases; instead, well-written, self-explanatory code often eliminates the need for excessive documentation.

Striking the Right Balance in Documentation and Code

A common scenario involves working with database tables to check if data exists or to count the number of rows for further processing. For repetitive tasks like this, a helper function is an excellent solution. Consider the following example:

class BaseModel extends Models
{
    function getTotalCount($table_name, $condition = []) {
        $query = "SELECT COUNT(*) AS total_rows FROM " . $table_name;
        if (!empty($condition)) {
            $query .= " WHERE " . $condition;
        }
        return $this->db->query($query)->get();
    }
}

// Usage
$productTotalCount = $this->BaseModel->getTotalCount('products', ['brand_id' => $brand_id]);
if ($productTotalCount > 0) {
    // Further processing...
}

This approach is clear and concise, with no unnecessary complexity. The function serves its purpose effectively, and its usage is intuitive. However, let’s look at a contrasting example:

class My_Model extends Models
{
    /**
     * Get Simple Read Of Method
     * to get a specific row of a table
     */
    function simple_read($table_name, $condition, $column_name = "*") {
        if ($table_name == '' || $condition == '') {
            return false;
        }
        return $this->db->select($column_name, false)->where($condition)->get_where($table_name)->row();
    }
}

// Usage
$productTotalCount = $this->My_Model->simple_read('products', ['brand_id' => $brand_id]);
if ($productTotalCount > 0) {
    // Further processing...
}

Here, the simple_read function is being misused for a task it wasn’t designed for. If the products table has 20 rows, the function will return only the first row of the table. If no data is present, it returns NULL. This creates a problem: is NULL comparable to 0? Absolutely not. Consequently, the code will throw an error if the table has no data. Writing detailed documentation for such flawed code won’t make it better. It’s akin to adding layers of explanation to a fundamentally broken solution.

Lessons Learned:

Prioritize Clarity in Code: Strive to write clear and self-explanatory code. If your code is easy to understand, it reduces the need for extensive documentation.
Avoid Misuse of Functions: Understand the purpose of each function and use it appropriately. Avoid bending a function's behavior to fit a task it wasn’t designed for.
Focus on the Essentials: Documentation should highlight what truly matters, such as critical business logic or non-obvious functionality.
Think Before You Code: As the saying goes, "Think before you act." Similarly, write code after careful thought and planning. Don’t defend flawed practices under the guise of meeting deadlines.

By balancing meaningful documentation and well-structured code, developers can ensure their work is efficient and easy to maintain. Ultimately, it’s not just about writing code; it’s about writing good code.

Integrate Swagger UI with Codeigniter4

MD Shahin Mia Robin — Mon, 16 Dec 2024 10:03:32 +0000

Swagger is a widely used API documentation and testing tool that seamlessly integrates with popular web frameworks like Laravel, Spring Boot, CodeIgniter, and ExpressJS. In this article, we will focus on integrating Swagger with CodeIgniter.

Installing Dependencies:

composer require zircote/swagger-php doctrine/annotations

Downloading the SwaggerUI `.zip` or SwaggerUI GitHub repo:

Download link: SwaggerUI latest releases Download the Swagger UI release that best fits your requirements.

Writing the Controller:

To generate the swagger.json file for Swagger UI we will have to create a controller. Name the controller as your choice we are giving it SwaggerDocGenerator.php. In the controller, we will have to use OpenApi\Generator from zircote/swagger-php to convert all the @OA syntax into a JSON.

<?php
namespace App\Controllers;

use OpenApi\Generator;

class SwaggerDocGenerator extends BaseController
{
    /**
     * Generate OpenAPI documentation for the API ...
     * @return string
     */
    public function generate(): string
    {
        // Specify the path where your API controllers are located
        $openapi = Generator::scan([APPPATH . 'Controllers']);

        $swaggerContent = $openapi->toJson();

        // Save the generated OpenAPI content to a file
        $filePath = FCPATH . 'swagger_ui/swagger.json';
        file_put_contents($filePath, $swaggerContent);

        return $swaggerContent;
    }

    /**
     * Render the SwaggerUI ...
     * @return string
     */
    public function index()
    {
        return view('swagger_docs/index');
    }
}

?>

Creating Routes:

By creating a route on Config/Routes.php we will be able to generate the expected sawgger.json file.

// Create API documentation ...
$routes->get('api/v1/docs/generate', 'SwaggerDocGenerator::generate');
$routes->get('api/v1/docs/ui', 'SwaggerDocGenerator::index');

Rendering Swagger UI:

There are many ways to render your swagger.json file into SwaggerUI:

Importing the swagger.json file into the POSTMAN.
Using the SwaggerUI with your own views to render the SwaggerUI.
Setting up the environment into your frontend application to render the SwaggerUI by requesting on backend-API for the swagger.json file.

In this, we will see the first two ways. We will talk about the 3rd way in another article.

Importing the swagger.json file into the POSTMAN:

Copy the swagger.json.
Open the POSTMAN.
Click on the Import button in the top-left corner.
Paste the copied swagger.json.

Using the SwaggerUI with your own views to render the SwaggerUI:

Create a .php file on your views folder app/Views/swagger_docs/index.php to render the SwaggerUI.
Extract the downloaded SwaggerUI .zip file into the public/swagger_ui/ folder.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>Swagger UI</title>
    <link rel="stylesheet" type="text/css" href="<?= base_url('swagger_ui/swagger-ui.css') ?>" />
    <link rel="stylesheet" type="text/css" href="<?= base_url('swagger_ui/index.css') ?>" />
    <link rel="icon" type="image/png" href="<?= base_url('swagger_ui/favicon-32x32.png') ?>" sizes="32x32" />
    <link rel="icon" type="image/png" href="<?= base_url('swagger_ui/favicon-16x16.png') ?>" sizes="16x16" />
  </head>

  <body>
    <div id="swagger-ui"></div>
    <script src="<?= base_url('swagger_ui/swagger-ui-bundle.js') ?>" charset="UTF-8"> </script>
    <script src="<?= base_url('swagger_ui/swagger-ui-standalone-preset.js') ?>" charset="UTF-8"> </script>
    <script src="<?= base_url('swagger_ui/swagger-initializer.js') ?>" charset="UTF-8"> </script>
  </body>
</html>

Now, we have to update the url of public\swagger_ui\swagger-initializer.js with the following code.

url: "http://your-local-server/swagger_ui/swagger.json"

Note:

Make sure to run the php spark serve command to run the Codeigniter4 application.
Every time you make changes in the OpenAPI documentation syntax, you will have to run the http://localhost:8080/api/v1/docs/generate URL to generate the updated swagger.json file.
Make sure to update the swagger-initializer.js file with the updated URL of the swagger.json file.

Conclusion:

In this article, we explored integrating Swagger with CodeIgniter 4, generating the swagger.json file, rendering it in Swagger UI, and importing it into Postman. We also demonstrated how to render Swagger UI within custom views. However, manually generating the swagger.json file and updating the URL in the swagger-initializer.js file is not ideal.

In the next article, I will demonstrate automating this process using custom CLI commands and aim to develop an open-source package for this purpose. Feel free to share your suggestions or queries in the comments section.

Getting migration and seeder files from connected DB using db_craft

MD Shahin Mia Robin — Sun, 06 Aug 2023 06:45:12 +0000

DB-Craft

DB-Craft is a package for CodeIgniter 4 that provides convenient commands to generate migration and seeder files from a connected database.

Installation

You can install the DB-Craft package via Composer by running the following command:

composer require robinncode/db_craft

Dependencies

DB-Craft has the following dependencies:

PHP: ^7.0.* || ^8.0.*
CodeIgniter/Framework: ^4.0.*

Usage

DB-Craft comes with the following commands:
Generate Migration Files

To generate all migration files from the connected database, run the following command:

php spark get:migration

To generate migration files for a specific table, run the following command:

php spark get:migration table_name

Replace table_name with the name of the specific table for which you want to generate migration files.
Generate Seeder Files

To generate all seeder files from the connected database, run the following command:

php spark get:seed

To generate seeder files for a specific table with table data, run the following command:

php spark get:seed table_name

Replace table_name with the name of the specific table for which you want to generate seeder files.