Codelite

"Works on My Machine" Isn’t Defense: Fix Your Local PHP Environment

Samer Moustafa — Thu, 08 Jan 2026 22:44:13 GMT

You’ve seen it a thousand times. Someone pushes code to production, a bug appears, and that message pings loudly

For some, it’s a joke. For most teams and senior developers, it’s a moment of frustration, mixed with dread.

The truth is simple: your local environment is silently failing you. That green checkmark or status [200] on your laptop doesn’t guarantee that production will behave the same way. And this mismatch is one of the most common sources of wasted hours, heated debates, and stress in development teams.

This guide isn’t here to lecture you or tell you that you’re bad at your job. It’s here to help you understand why this keeps happening, and what you can do to prevent it, for your projects, your team, and your own sanity.

The Title Claim

The title of this guide isn’t provocative for no reason or SEO oriented. “Stop Blaming Production: Fix Your Local Environment” is a statement of principle, not accusation.

When a bug only shows up in production, it’s tempting to assume production is at fault. Maybe the server is misconfigured, maybe someone deployed the wrong code, maybe the database is weird. But in most cases, the environment you’re running locally is incomplete, inconsistent, or subtly different from production.

If you are seeking professionalism and aiming for seniority level then your professional mindset has to be :

If you cannot reproduce a bug locally, you are debugging blind

This is a core discipline. It’s not about blame, it’s about engineering integrity.

Why “It Works” ≠ “It’s Correct”

We’ve all been there. You follow a tutorial, install PHP, run a script, and it works. Mission accomplished.

But the problem is that “works” is a very limited signal. Most tutorials and quick-start guides are optimized for first success. They rarely cover edge cases, multi-version support, OS differences, or nuanced configuration.

So when you or your team stops at “it works,” what you’re really doing is hiding gaps. These gaps quietly accumulate until production exposes them as bugs that are hard to debug, inconsistent, or seemingly random.

This is the “works on my machine” trap: the environment gives a false sense of security.

The Real Reasons Bugs Don’t Reproduce Locally

Here’s what I see over and over in real-world teams and projects. Any one of these might be harmless, together, they’re a debugging nightmare

Runtime version mismatch

You might be on PHP 8.3 locally, while production runs 8.2. Minor differences in behavior, deprecations, or extensions can cause subtle failures.

Extensions and configuration differences

Production might have opcache, gd, or intl enabled. Local setups may skip some of these, leading to inconsistent behavior.

Environment drift

Memory limits, max execution time, error reporting — these tiny differences shape what works and what breaks.

Filesystem & permissions differences

Linux vs Windows line endings, user permissions, or ownership can silently block code that seems fine on a dev machine.

Email, cache, or queue shortcuts

Using Mailtrap everywhere feels safe, but it masks real SMTP or queue behavior. Cache or session shortcuts can hide race conditions.

OS-level dependencies

Missing libraries, system tools, or background services can make code fail in ways that only production exposes.

Environment security level

Production is usually more restricted, controlled and hand-configured, you default assumptions my been blocked there for a security reason

Individually, these feel minor. Together, they make debugging production a guessing game with blind eyes.

The Dangerous Mental Model

Many developers unconsciously adopt this assumption : If it works locally, production must be wrong, this is a mental trap. It shifts responsibility away from professional engineering to finger-pointing.

As developers we don’t point fingers, find the guilty one. Instead we find the cause, explain the scenario, introduce the fix and maintain stability and logically workflow.

The mature model flips this into :

If it fails in production but not locally, my environment is incomplete

This mindset shift is huge. It stops wasted arguments, hours of meetings, spams of email messages and sets the stage for systematic improvement.

Local ≠ Production (But It Must Be Comparable)

Let’s be clear on this point: your local environment does not need to be an exact copy of production. Docker, VMs, Networking, Security level or configurations. Mirrors are great (in some cases), but overkill for most cases.

What matters is comparability:

PHP version alignment : same minor version at minimum
Extensions that matter : match production for key behaviors
Execution model : CLI vs FPM vs CGI differences
Configuration assumptions : error reporting, memory limits, timezone
Data and environment flow : caching, queues, and email delivery

When these points match, you can reproduce bugs reliably and reduce fighting.

Note: understanding the difference between how each OS / Kernel behaves is a must and adds a great bonus for your to spot the “cause” so early, but this is a large topic, so we will talk about this separately.

You can ignore this .. but it costs much

Ignoring environment drift is deceptively cheap, until it isn’t. Below is the real cost of ignoring

Debugging becomes a guessing game
Logs are confusing or misleading
Simple upgrades feel risky
Developers avoid touching the environment
“Works on my machine” excuses multiply
Getting locked in “I don’t know why” zone

Eventually, these small inefficiencies become team-wide pain. Every fight, every late-night patch, every long meeting, every subtle production bug is a symptom of local environments that aren’t trusted.

The Rule — Keep this in mind

Here is what i usually repeat almost daily and i keep remind myself as well :

It’s not production’s fault. If you cannot reproduce it, you’re doing it wrong.

Let’s unpack that carefully.

Empathy First

You are not being blamed. You are not failing. If you’ve ever been stumped by a bug that disappears locally, you’ve been in this exact situation. That feeling of doubt is normal and universal.

A Career-Saving Principle

This rule exists to protect your career. Reproducible environments save hours, reduce stress, and make you the developer others trust. Master this, and you’ll debug faster, upgrade versions confidently, and avoid wasting team time.

Support, Not Shame

This is guidance, not criticism. Applying this principle builds habits that protect your projects and your sanity. You’re creating predictable, maintainable local setups, and that’s a skill that separates good developers from great ones.

Lens for Evaluation

Every pain point you’ve seen, version mismatches, permissions errors, email shortcuts can be seen through this lens. Ask yourself:

If this bug were in production, could I reproduce it locally? If not, my environment needs improvement

It’s only first step

Reproducing a bug is only the first step. How you approach it, the questions you ask, the tools you choose, and the order in which you test hypotheses matters just as much. A reliable local environment gives you the canvas, but your thinking and debugging habits are the brush

It’s not about blame. It’s about building a reliable, professional career path.

Practical Mini-Framework for Thinking

When a bug only shows up in production, your mindset and debugging process matter as much as your environment. Here’s a simple mental checklist you can use every time:

Observe – Start by looking at logs, errors, and actual behavior. Don’t guess; gather evidence first.
Hypothesize – Ask: “What might be different between my local machine and production?” Consider PHP version, extensions, OS differences, permissions, or service availability.
Reproduce – Can you make the bug appear locally? If not, your environment or assumptions need adjustment.
Test Tools – Check that your developer tools are showing accurate information. Are xdebug breakpoints working? Is your mail server setup reflecting real SMTP flows?
Reflect – Finally, review your assumptions and shortcuts. Did you mask a symptom? Did a convenience tool hide the root cause?

Following this simple framework turns “works on my machine” from an excuse into a repeatable debugging habit, giving you confidence and control over production issues.

What a Correct Local Environment Optimizes For

A proper local environment doesn’t just “work.” It is deliberately designed to:

Reproducibility → every bug can be reproduced
Predictability → behavior matches production where it matters
Version Awareness → multiple PHP versions handled safely
Replaceability → easy to reset or rebuild
Confidence → upgrades, tests, and experiments are safe

When these are in place, “works on my machine” becomes irrelevant, because production behaves as expected.

Responsibility Without Blame

This is a solvable problem.

A professional environment isn’t just about installing runtime or spinning up Docker. It’s about thinking like a senior engineer:

Evaluate assumptions
Align critical behavior with production
Reproduce issues locally
Automate or document what matters

If you adopt this mindset, your future and your team will thank you. Firefighting becomes predictable. Deployments are smoother. Debugging stops feeling like guesswork.

You’ll eventually feel more confident about your skills, cause no more myths. If it’s not working then you easily recognize the cause.

Logical workflow builds trust, experience and confidence.

Next Articles in this Series

Fixing the “works on my machine” mystery is not a one task, it’s a mindset and skill set you build over time. To tackle the root causes systematically, the following articles will dive deeper into the practical aspects of reliable PHP development environments:

Multi-PHP Versioning Without Fear – Learn how to switch safely between PHP 8.2, 8.3, and 8.5 without breaking your projects.
FPM, CLI, or CGI: Why It Matters – Understand how PHP execution modes differ and why this impacts debugging and production behavior.
Local Mail Done Right – Explore Mailpit, Mailhog, and strategies for debugging real SMTP flows locally.
Linux Permissions Without Chmod Chaos – Avoid the common “permission denied” traps that derail even experienced developers.
When Containers Actually Help – Discover when tools like Docker or Podman make sense and when they’re overkill.
OS Awareness – Understand the subtle differences between Windows and Linux environments that often cause hidden bugs.
Common Security Restrictions – Real-world examples of production limitations that can surprise you if not accounted for locally.
XDebug: The Swiss Army Knife for Confident Developers – Harness the power of debugging like a pro.
Editor — It Really Matters – Learn how your code editor can mislead you and how to configure it for reliable results.
NGINX vs Apache – A practical look at architecture and behavior differences that affect local testing and production parity.

Each of these articles will build on the principle introduced here: your local environment and workflow is part of the system, and it must be reliable. Together, this series will give you the tools, habits, and knowledge to debug with confidence, reproduce production issues locally, and work like a senior developer.

How to Apply Laravel Modular Approach Architecture in 9 Easy Steps

Samer Moustafa — Wed, 31 Dec 2025 22:00:00 GMT

Laravel is powerful and very intelligent PHP Framework that can serve you from a very simple web application to large and enterprise level applications, Well that’s a good news but in other hand using such a large framework without any architecture approach in mind can lead to a massive mess and downfalls in the process of expanding and in production environment.

While Laravel has it’s own design system we can’t only rely on this. Imagine an Application with tons of Features that heavily depends on Each others, in this case maintaining any little refactoring or improvements can cause much problems and bugs. That’s we need to start with a modular architecture that helps separate and maintain each feature as a standalone package.

What is Modular Architecture

Modular Architecture is a way of your Laravel Project where each Feature is considered a standalone Block that can nicely work with other Blocks or Features. Its also serves the concept of Separation of Concerns so when you develop a Feature you have to only focus on that Feature and its Logic and how it can be used by any other Feature. So each Feature is a Module, for example we have Modules like :

Users, Blog, Pages, Products, .... etc

The Big Picture

In order to Apply the Modular Architecture we will need to separate each module in a dedicated directory which will contain the module’s Controller, Migrations, Views, Routes, Models, Providers and each piece of code that’s related to this Module. So we will need to instruct Laravel how to load each component of each module correctly.

To Achieve this separation we will rely on Service Providers, where each module will contact a Module Service Provider that will instruct Laravel how to interact with and Load that Module.

Create our Project

Lets create our laravel project which we will use to apply modular architecture

composer create-project "laravel/laravel" modular

Give composer few time to download and install required packages then after installation complete go to the installation directory using cd command and run the serve command to start up our application

cd modular
php artisan serve

Now you can visit your application in the browser using the link http://127.0.0.1:8000 , Note : keep eye on terminal output as the port 8000 may change.

Modules Structure

We will start by creating a directory called Modules that will contain all our modules, Each Module will by consist of multiple directories and files, so our directory tree for our Modules directory will look something like this

Modules
- Blog
-- Config
-- Database
-- Http
-- Models
-- Providers
-- View
-- Routes
+ Pages
+ Products

Configure Composer

Its very important to tell composer where to find and how to load our modules files and classes and before that we have to keep in mind that we will use namespaces to differentiate modules so each module fille will be prefixed by namespace of Modules\MODULE_NAME so for example


So we need to add the base namespace Modules pointing to the Modules directory in composer.json file under autoload > psr-4 as follows

don’t forget to run composer dump-autoload command
Module Service Provider
Now Composer can find our Modules classes, so it’s the time to create the module Service Provider that will instruct laravel how to interact with our module, we will apply this to our Blog module as demonstration. Go to Modules > Blog > Providers and create a new class file ModuleServiceProvider.php, with following contents
function register()
    {
        //...
    }

    public function boot()
    {
        //...
    }
}

Load Modules Providers
As we have seen before, each module should has it’s own Service Provider that we will use to instruct laravel how to load and interact with out module, but how laravel will know about this Service Provider ?
We will need to tell Laravel to Scan the Modules Directory to find installed modules and for each module we will look for the ModuleServiceProvider class and load it in the System. Best place to do this is in AppServiceProvider.php located in app/Providers Directory. withint the Register method as follows :
function register()
    {
        //Search for Modules
        $modulesBasePath = base_path('Modules');
        foreach(File::directories($modulesBasePath) as $moduleDirectory)
        {
            //Get Module Name from the owner Directory name
            $moduleName = basename($moduleDirectory);
            $providerClassName = '\\Modules\\'.$moduleName.'\\Providers\\ModuleServiceProvider';
            if(class_exists($providerClassName))
            {
                //Register Module Service Provider if Exist
                $this->app->register($providerClassName);
            }
        }
    }

    //....
}

Now Laravel will be aware of every module Service Provider, so next steps will be all included inside that providers
Routes Discovery
As each module will contain its own routes then we will create a new directory into the module named Routes which will contain a web.php file, that file where we will define the module routes, and as a start will will add just one route to test if it’s working
'/blog', function(){
    return 'Yay, Blog Routes Working';
});

If we tried to visit that route, it will give us 404 Not Found error as Laravel not yet aware of that file, so we will add a RouteServiceProvider.php that will load our web.php routes file, in the directory of Modules/Blog/Providers
function map()
    {
        $this->registerWebRoutes();
    }

    protected function registerWebRoutes()
    {
        //Add Web Routes with web Guard
        Route::middleware('web')
            //Set Default Controllers Namespace
            ->namespace('Modules\\Blog\\Http\\Controllers')
            ->group(base_path('Modules/Blog/Routes/web.php'));
    }
}

Note that we are now extending the Illuminate\Foundation\Support\Providers\RouteServiceProvider not the regular Service provider, this will tell laravel to call the map function automatically
Before we test we need to tell Laravel to also load that RouteServiceProvider inside the register method of the ModuleServiceProvider
function register()
    {
        //...
        $this->app->register(RouteServiceProvider::class);
    }

    //...
}

Now if we visit the test route at http://127.0.0.1:8000/blog it should work.

Module Views
Until now we can create routes but we only return a String, what if we want to return a Blade view, and how to differentiate views for each module using views namespacing.
It’s very easy, all we need to do is to register our custom Views path to Laravel views sources inside the ModuleServiceProvider boot method
$moduleName = 'Blog';

    //...

    public function boot()
    {
        $this->registerViews();
        //...
    }

    protected function registerViews()
    {
        $moduleViewsPath = __DIR__.'/../Views';
        $this->loadViewsFrom($moduleViewsPath, strtolower($this->moduleName));
    }
}

Lets test that by creating a new view inside Views directory and return it from our test route.
'/blog', function(){
    return view('blog::index');
});

Blog Module
This view is loaded directly from Blog Module /Views directory

Continue using Controllers
We can take that a step further and create our first modular controller for our module at the path of Modules\Blog\Http\Controllers named BlogController
function index()
    {
        return view('blog::index');
    }
}

'/blog', [BlogController::class, 'index']);


Register Migrations
Each module may contain its own database migration, that why we need to make laravel aware of this migrations which will once again be done inside ModuleServiceProvider boot method
?php

namespace Modules\Blog\Providers;

use Illuminate\Support\ServiceProvider;

class ModuleServiceProvider extends ServiceProvider
{
    //...
    public function boot()
    {
        $this->registerViews();
        $this->registerMigrations();
        //...
    }
    //...    
    protected function registerMigrations()
    {
        $this->loadMigrationsFrom(base_path('Modules/'.$this->moduleName.'/Database/Migrations'));
    }
    //...
}

Lets create a new Migration at path /Modules/Blog/Database/Migrations , which we will name as create_posts_table.php
return new class extends Migration {

    public function up()
    {
        Schema::create('posts', function(Blueprint $table){
            $table->string('title');
            $table->text('content')->nullable();
            $table->unsignedBigInteger('author_id')->default(0);
            $table->unsignedBigInteger('category_id')->default(0);
            $table->timestamps();
        });
    }

    public function down()
    {
        Schema::drop('posts');
    }

};

Now let’s run the migration command to make sure it works
php artisan migrate


Merge Configurations
Since your modules may contains a configuration files, then we need to tell laravel to merge this files into main configurations to be able to retrieve it with config() function, this is once again can be done in the ModuleServiceProvider as follows
function boot()
    {
        $this->registerConfig();
        //...
    }
       //...
    protected function registerConfig()
    {
        $this->mergeConfigFrom(
            base_path('Modules/'.$this->moduleName.'/Config/config.php'), strtolower($this->moduleName)
        );
    }
}

Now we can reference our config file using config() function by prefixing with the lower-case module name for example
config('blog.post_per_page', 10);

Models, Middlewares and Events, What about ?
Those type of files is just regular classes like controllers, so laravel don’t need any extra work to be aware of as long as you use the right classes namespacing and directory structure.
#Final ModuleServiceProvider
$moduleName = 'Blog';

    public function register()
    {
        $this->app->register(RouteServiceProvider::class);
    }

    public function boot()
    {
        $this->registerConfig();
        $this->registerViews();
        $this->registerMigrations();
    }

    protected function registerViews()
    {
        $moduleViewsPath = __DIR__.'/../Views';
        $this->loadViewsFrom($moduleViewsPath, strtolower($this->moduleName));
    }

    protected function registerConfig()
    {
        $this->mergeConfigFrom(
            base_path('Modules/'.$this->moduleName.'/Config/config.php'), strtolower($this->moduleName)
        );
    }

    protected function registerMigrations()
    {
        $this->loadMigrationsFrom(base_path('Modules/'.$this->moduleName.'/Database/Migrations'));
    }
}

Final Words
Good Applications starts with a good structure and design pattern so it’s always the best to spend sometime designing your application structure.
I would also like to mention that our new Laravel Package has been release which will help developers to add Actions and Filters feature in Laravel Application like WordPress Apps, You can check out full tutorial of Eventual Events Package Here
Also i’m waiting for your questions and requests if you have any.



How to use Laravel Eventual Free Package from Scratch
Samer Moustafa — Thu, 18 Dec 2025 22:00:00 GMT
Laravel Eventual Package is the Newly released Package for Actions and Filters Management system through Laravel Framework and PHP

Concept
In this Guide we will take a general overview about how this package work and basic concepts to get more familiar when working with Eventual Package.
The main purpose of this Package is to add the ability for the developer to inject code and logic pieces in a clean and standalone way, which will lead to better decoupling. Concept is inspired by WordPress Hooks System which allows developers to execute code on certain events and also filters data passing through application without touching the core code.
Filters vs Actions
We will use those terms a lot in from now on so you need to have a clear understanding of how they work and defer from each others
**Actions **: can be considered as an event that happens in some certain situations and may need further sequential actions to be taken upon that event, so for example consider saving a new blog post (Action), then you can inject a piece of code (Handler) to send an email to subscribers afterwards.
**Filters **: Actually it’s a piece of data that been collected or manipulated by the application and may need to be altered or filtered, lets say for example in our application we returning a list of blog posts in order to show it to our visitors, in this case we may want to filter this posts and exclude a private ones before returning them to the visitor
Installation
First make sure you have composer installed first, but in case you already working with laravel then likely you’ll have it installed already.
Open your terminal and CD in your laravel project root
Run the following composer command to install the package
composer require codersamer/eventual

Once installed you can start using this package.
Note : if you have a laravel project with version less than 6, then you’ll need to add the corresponding service provider to your application
Add Service Provider (Laravel Below 6)
Go to your config/app.php file and open it with your preferred code editor and add the following provider to the “providers” array
Codersamer\Eventual\Providers\EventualServiceProvider

Basic Usage
Eventual Package depends mainly on four methods doAction, onAction, doFilter, onFilter. The “do” part means fire or apply and find the all registered handlers for that event or filter which the “on” part means when that thing happens run the following piece of code accordingly .
At the very basic Level we can use this methods on the Eventual Facade
Codersamer\Eventual\Facades\Eventual

Register an Action
Before Handling an action we need to know how we fire or tell laravel that some action happening now and need to take further actions afterwards. This can be achieved simply by calling the method doAction like so
'blog_post_saved', $argument1, $argument2);

First parameter indicates the action name that all handlers should use to respond to this action, other arguments indicates the data that will be carried to all handlers.
**Note **: Arguments are not limited to some number, you can pass as many arguments as you need and all of them will be carried to handlers, also it support all types of data so it can be primitive type, model, custom object … etc
Handle an Action Now our application fires events and actions in some points of app life cycle, it’s the time for us to learn how to handle this actions and act accordingly which can be achieved by called the method **onAction **as following
'blog_post_saved', function($argument1, $argument2){
    //Act to the Action
    //Send some email to subscribers
});

This piece of code tells Eventual Package to take some steps / run piece of code only when some action occurred, in this case it’s “blog_post_saved“, and as we mentioned before all handlers will receive the corresponding arguments been sent via the dispatcher
Register a Filter As we registered an action before we can also register a filter before handle it later using the method doFilter , this way we can later modify that piece of data in any point of the application
$post = Eventual::doFilter('posts_list', $posts, $extraArgument);

As you may notice here we could pass more than one argument to be carried on to the handlers / filters, but keep in mind that the filters system will only look for updates happen on the first argument, in this case “$posts”, also it returns the first argument again after been modified by all handlers added to this filter, so consider the extra arguments are just a reference information regarding this filter but actually the filters system doesn’t really care about it.
Handle a Filter
In the Previous part we learned how to register a filter, now it’s the time to add handlers for this filter, it’s some how identical to how to handle actions but with some key differences
'posts_list', function($posts, $extraArguments = null){
    //Add Updates to the posts if needed, then return it
    return $posts;
});

As you can see it’s very similar to handling actions but the key difference here is that you MUST return the first argument again after your modifications as the dispatcher now waiting for it.
Conclusion
Working with Filters and Actions Pattern is very fun and helps with code decoupling, so you can modify application core logic and manipulate data without touching the core code which may be useful when developing a modular laravel application, multi-theme system, multi-plugins system.
Now let me tell you that you are now familiar and capable of working with this package but this is not all, we have more advanced features and techniques to discuss later, so keep reading and exploring.



Javascript Fetch API Simplified
Samer Moustafa — Tue, 16 Dec 2025 22:00:00 GMT
History
One of the most usages of javascript is making Requests to backends using Ajax without Page Reload. The ancient way of doing request is use XMLHttpRequest API, that was just fine but requires long code and not really simple to achieve. JQuery came to solve complexity of XMLHttpRequest and provided an API to make Ajax Requests which we so popular for long period of time.
Fetch API Compared to jQuery Ajax

Fetch API is native to javascript, thats means it doesn't add more load to your application as jQuery do, also it makes it usable whatever JavaScript Framework you are using as it has no dependencies.

Fetch API Promise won't fail or reject on HTTP error response like 404 ... etc, instead it will just continue and set ok value to false, but it will only fails and reject on Network errors.

jQuery Ajax is just a wrapper for XMLHttpRequest so it's safer to use on very old Browsers for competabiliy but almost every modern browser now supports Fetch API.

Fetch API won't send Cookies by default, so some authentication processes may fail but of course you can set the cookies manually with initial options.

Fetch API doesn't support timeouts, which means request will keep going trying yo get response until browser decides not to. For sure you can overcome this using Promise.race() . We will learn more about this.


Getting Started
In this tutorial we going to use JSONPlaceHolder API as for demonstration purposes, it's Free and more than enough for our tutorial
Fetch API is totally native to Javascript so we don't need to add any packages or libraries, just a typical HTML document to work with
html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Fetch APItitle>
head>
<body>

    <script type="text/javascript">
        //Our Javascript code to be Here
    script>
body>
html>

HTTP GET Request
Now we going to learn how to issue a GET request to get list of posts

EndPoint : https://jsonplaceholder.typicode.com/posts/

//Execute one DOM Fully Loaded
document.addEventListener('DOMContentLoaded', () => {
     //GET Request -> https://jsonplaceholder.typicode.com/posts
     fetch('https://jsonplaceholder.typicode.com/posts')
         .then(response => response.json())
         .then(jsonResponse => console.log(jsonResponse));
});

Code Explainations

First we wrapped our code within DOMContentLoaded event to make sure code executes once Page fully loaded to avoid any further issues.

fetch function is used to issue ajax request, it takes 2 arguments. First argument indicates the endpoint or url you are issuing request to, second arguments is initial options where you can specify more options regarding your request and we don't use it here as we has nothing special. Note : fetch by default consider you are making a GET request unless you specify something else.

fetch will always return a Promise that's why we used then method to chain execution after request is done

After request completed we chained it with a callback to extract Response Body as Json using response.json() which also will return a Promise.

Finally we chained another callback to console.log the Json Response to the console.



Another Example
Let's try again to get a single post item and console.log its title

EndPoint : https://jsonplaceholder.typicode.com/posts/1

//Get Request -> https://jsonplaceholder.typicode.com/posts/1
fetch('https://jsonplaceholder.typicode.com/posts/1')
     .then(response => response.json())
     .then(postItem => console.log(postItem.title));

HTTP POST Request
Since we now know how to make GET requests then POST request won't be any hard, it's almost similar with only few points

We need to tell Fetch API that we are using POST instead of GET

Mostly with POST requests we need to pass Data to the request

Optionally some APIs requires some headers to be sent with the Request

Also you may need to work on APIs that requires authentication and authorization. This Points can be achieved easily using the second argument of fetch method, actually it expects an object with some options modifier, so we gonna use method and body options, Optionally : we can use headers option.



EndPoint : https://jsonplaceholder.typicode.com/posts

//POST Request -> https://jsonplaceholder.typicode.com/posts
fetch('https://jsonplaceholder.typicode.com/posts', {
    method: 'POST',
    //Send Data as Json String
    body: JSON.stringify({
        title: 'Fetch API',
        body: 'Ajax is Awesome using Fetch',
        userId: 1
    }),
    //Set Extra Headers
    headers: {
        'Content-type': 'application/json; charset=UTF-8',
    },
})
.then(response => response.json())
.then(newPost => console.log(newPost));

HTTP PUT Request
Its similar to POST request but we set method option to PUT, PUT Requests usually used to update a resources.

EndPoint : https://jsonplaceholder.typicode.com/posts/1

//PUT Request -> https://jsonplaceholder.typicode.com/posts/1
fetch('https://jsonplaceholder.typicode.com/posts/1', {
        method: 'PUT',
        //Send Data as Json String
        body: JSON.stringify({
            title: 'Fetch API is Excellent',
        }),
        //Set Extra Headers
        headers: {
             'Content-type': 'application/json; charset=UTF-8',
        },
    })
    .then(response => response.json())
    .then(updatedPost => console.log(updatedPost));

HTTP DELETE Request
DELETE Request is usually used to delete a resource on server

EndPoint : https://jsonplaceholder.typicode.com/posts/1

//DELETE Request -> https://jsonplaceholder.typicode.com/posts/1
fetch('https://jsonplaceholder.typicode.com/posts/1', {
        method: 'DELETE',
    })
    .then(response => response.json())
    .then(jsonResponse => console.log(jsonResponse));

Extra Bonus
Now since we can work well with Fetch API it's time for some bonus tips and tricks
Timeouts
As we said before Fetch doesn't support timeouts , so how we can handle timeouts ? Well it's totally simple since fetch return a Promise so we can use race .
//GET Request -> https://jsonplaceholder.typicode.com/posts/1
Promise.race([
        fetch('https://jsonplaceholder.typicode.com/posts/1'),
        new Promise((resolve, reject) => {
            setTimeout(() => reject(new Error('Request Timeout')), 3000);
         })
    ])
    .then(response => response.json())
    .then(postItem => console.log(postItem.title))
    .catch((error) => console.log(error));

Final Code

"en">

    "UTF-8">
    "X-UA-Compatible" content="IE=edge">
    "viewport" content="width=device-width, initial-scale=1.0">
    Fetch API


    






Create Custom Laravel Artisan Commands : Getting Started
Samer Moustafa — Tue, 09 Dec 2025 22:00:00 GMT
As a Laravel developer you should be knowing what artisan is and how great addon it is to laravel, but if you are not very familiar with this then now worries, we have you covered
What is Artisan ?
ArtIsan is a Command line interface to interact with your laravel based Project, it’s shipped already with default laravel installation and you can also add it manually if not. Artisan comes with a lot of helpful and great command which helps generate and scaffold your project logic files as well as project control.
All artisan command can be executed simply through any command line like follows:
php artisan {command-name} {command-arguments} {command-attributes}

To get list of available Artisan Commands you can run this command :
php artisan list

Now you know the basic of Artisan Commands, so why not make your own custom artisan commands.
Create your Custom Command
Creating your custom commands will greatly help you automate and enhance your development experience, so lets image we want to make a command that will help us change users password through console interface, so we begin by create our command class file, once again we can do this using artisan command :
php artisan make:command SetUserPasswordCommand


Here we use command make:command and we passed the argument that identify the class name of our command

Voila, your custom command class created successfully and you can found it under path : /app/Console/Commands
Here is our Blank Command Class Content Looks Like
command.
     *
     * @var string
     */
    protected $signature = 'command:name';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Command description';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle()
    {
        return Command::SUCCESS;
    }
}

Lets Deep dive
** $signature Property : **
This Property is what tells laravel how you command should look like when executed, it’s like a Pattern that describe your command, so for example if we want our command to be called reset-password then the signature should be like this :
protected $signature = 'reset-password';

** $description Property : **
Consider this is the Help or description for your command, so make it meaningful and descriptive, and it’s just a string, that doesn’t affect how your command executes
protected $description = 'A Very Powerful command that helps you reset any user password through console';

** But wait… where this description will appear ? **
well you can check that using the artisan “help” command like this :
php artisan help reset-password

** __construct() method : **
This is just a regular class constructor method that runs just before executing your command logic.
** handle() method : **
This is the beating heart of your command, this the place where you command logic should reside, which means all logic procedures should be implemented there.
Now we know how this command structured but its actually doing nothing, and to be useful we need to accept arguments or parameters from the console to be more dynamic and responsive
Arguments
We need our Command to accept 2 Arguments (user email and the new password), if we try to just pass it when calling or command like this :
php artisan reset-password email@codersam.online TheNewPassword

as you may notice it will throw an Error

Defining Arguments
That’s means we need to tell laravel that our command can except 2 arguments, and this is done by modifying command $signature as follows :
protected $signature = 'reset-password {email} {password}';

Defining Arguments should be enclosed with curly braces ( { } ), to identify that this is an argument that our command can accept, and between the curly braces we give our arguments a name so we can retrieve the argument value later.
Retrieve Arguments Values
Retrieving Arguments Value is very simple by calling the method argument, it accepts argument name as a parameter, so in our handle method we can retrieve values as follows :
public function handle()
{
    $email = $this->argument('email');
    $password = $this->argument('password');
    return Command::SUCCESS;
}

Output to Console
Now we can create a command, define arguments and also retrieve its values, but it will be so mystery if we can’t return a feedback to console to tell if something went successful or failed, so we need to output some messages to the console as a feedback.
The Legacy Echo
Of course as this is just a php code then you can use a simple echo to output some messages to console
public function handle()
{
  $email = $this->argument('email');
  $password = $this->argument('password');
  echo 'Email : '.$email;
  return Command::SUCCESS;
}

Sure it works but it’s not the best and beneficial way to output to console. Laravel Artisan comes with so many helpers to help interact with the console during command execution, we will learn about some of them just right now.
Info Output
We can output a info message with the helper method of info
$this->info('We Receive your Email and new Password');

Error Output
Display errors to console can be done using helper method error
$this->error('We cannot find a user associated with this email address');

Warning Output
You can add warning to console using helper method warn
$this->warn('Changing Password cannot be reverted later');

Alert Output
Displaying Alert can be done using helper method of alert
$this->alert('Changing Password in Progress');

Note : Alerts may seems same like Warning but actually it has more decorated like to bring more attention
Empty Lines Output
You may need to add Empty Lines like line breaks to space your outputs away, this can be done using helper method newLine
$this->newLine();

Note if you need to add more than one empty line then you can pass number of lines to this method
$this->newLine(3);

Let’s Implement our Command
Now we have all knowledge need to create our command, so let’s sum it up and implement our command login to be like so
public function handle()
{
  $email = $this->argument('email');
  $password = $this->argument('password');

  $user = User::where('email', $email)->first();

  if($user == null)
  {
    $this->error('Cannot find user associated with this email address');
    return Command::INVALID;
  }

  $user->password= bcrypt($password);
  $user->save();

  $this->info('User '.$user->name.' Password has been changed successfully');

  return Command::SUCCESS;
}

Note About Return
Note that Laravel expects the handle method to return an Integer value which indicates the status of the command execution and we have 3 statuses that we can return as they are defined as a constants in the base Command class : **Command::SUCCESS ** , **Command::FAILURE ** and **Command::INVALID ** .
Final Code


namespace App\Console\Commands;

use App\Models\User;
use Illuminate\Console\Command;

class SetUserPasswordCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'reset-password {email} {password}';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'A Very Powerful command that helps you reset any user password through console';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle()
    {
        $email = $this->argument('email');
        $password = $this->argument('password');

        $user = User::where('email', $email)->first();

        if($user == null)
        {
            $this->error('Cannot find user associated with this email address');
            return Command::INVALID;
        }

        $user->password= bcrypt($password);
        $user->save();

        $this->info('User '.$user->name.' Password has been changed successfully');

        return Command::SUCCESS;
    }
}

Summary
In this tutorial we learned how to create our first Artisan command, Defining Arguments, Get Values, Display Feedback and Real world example of implementation.
In Next Part we will go more advanced with custom Artisan Commands and we will learn much more advanced features and techniques.
So if you have any questions or requests, please don’t hesitate to add it to comments below.