DEV Community: Md. Asif Rahman

Mastering Background Job Processing with Supervisor and Laravel Queues

Md. Asif Rahman — Tue, 24 Dec 2024 12:01:05 +0000

In complex systems where large-scale background processing is essential—like fetching weather data for multiple cities or processing customer transactions —tools such as Supervisor and Laravel queues are indispensable. They help you manage long-running processes efficiently, ensuring jobs run continuously, restart automatically when they fail, and scale dynamically. This article dives deep into how Supervisor works, including its interaction with the Linux kernel, and explores how to optimize job processing for maximum performance.

What is Supervisor, and Why Should You Care?

Supervisor Overview

Supervisor is a process control system that helps manage background processes on Unix-based systems. Think of it as a system manager that:

Ensures jobs continue running.
Restarts jobs if they fail.
Logs output and errors for easier debugging.
Monitors system resources to prevent overload.
It's like having an experienced manager who ensures tasks in your team are executed and adjusted when things go wrong.

Key Features of Supervisor

Process Management: Supervisor keeps processes running by starting, stopping, and restarting them when needed. It ensures long-running tasks stay up and running, even after crashes or failures.
Logging: It tracks the output and error logs of processes, which helps in debugging and monitoring.
Notifications: Alerts you when a process crashes or restarts, providing vital insights into system health.
Scalability: You can configure multiple worker processes (instances) to handle high loads and ensure timely task processing.

Still, if you are not clear about what Supervisor is, have a look on the following analogy to grab it well in mind.

Analogy: Supervisor as a Factory Manager

Imagine a factory that manufactures cars. The factory has multiple assembly lines (processes), and the manager (Supervisor) ensures each line is operational:

Each Line (Process): Handles a specific task—such as assembling the chassis, attaching the wheels, and painting the car.

The Manager: Ensures the lines are always active. If a worker (process) falls behind or crashes, the manager replaces them. When the workload increases (more cars to build), the manager hires more workers (processes).

I hope now, you are totally clear about what supervisor actually is.

Now, lets have a dive into how it works on the kernel level.

How Supervisor Works on the Kernel Level

Supervisor interacts closely with the Linux kernel to manage system resources effectively. Understanding this interaction is crucial for optimizing Supervisor's performance.

Kernel Process Management

At its core, the Linux kernel is responsible for managing system resources, such as:

Process Scheduling: Determines which processes get CPU time and for how long.
Resource Allocation: Ensures each process gets access to memory and CPU without interfering with others.
Process Termination and Restart: The kernel tracks processes and terminates or restarts them if necessary.

Supervisor’s Interaction with the Kernel

Supervisor Process: Supervisor itself is a process managed by the kernel. It spawns other processes (workers) and monitors their state using kernel system calls.
Process Control: Supervisor uses the kernel’s process control functions to start, stop, and restart worker processes based on your configuration (e.g., autostart=true and autorestart=true).
Resource Management: Supervisor can adjust the number of worker processes (using numprocs) based on system resources like available CPU cores and memory. It can also set resource limits to prevent workers from overconsuming resources.
Kernel Signals: When a process crashes or stops, Supervisor sends kernel signals (SIGTERM to stop, SIGKILL to forcefully kill) to handle failed workers.

How to Set Up Supervisor for Laravel Queues

Basic Configuration

To configure Supervisor for Laravel queue workers, follow these steps:

Create a configuration file at /etc/supervisor/conf.d/laravel-worker.conf.

Add the following setup to the configuration file:

[program:laravel-worker]
command=php /path/to/your/laravel/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
stderr_logfile=/var/log/laravel-worker.err.log
stdout_logfile=/var/log/laravel-worker.out.log
numprocs=4
process_name=%(program_name)s_%(process_num)02d

Explanation

command: Specifies the command to run the Laravel queue worker.
- Example: php artisan queue:work executes the Laravel queue.
numprocs: Defines how many worker processes should run simultaneously.
- Example: Setting numprocs=4 runs four worker processes.
autostart and autorestart: Ensure that workers:
- Start automatically when Supervisor starts.
- Restart automatically if they crash.
stderr_logfile and stdout_logfile: Specify log files for:
- Error logs (e.g., /var/log/laravel-worker.err.log).
- Standard output logs (e.g., /var/log/laravel-worker.out.log).
process_name: Uniquely identifies each worker process.
- Example: Workers are named laravel-worker_00, laravel-worker_01, etc., based on the process_num.

Save and Apply Configuration

Save the configuration file.

Update Supervisor to recognize the new configuration:

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start laravel-worker:*

Monitor Workers

To check the status of your workers, use:

sudo supervisorctl status

What Happens When You Have Too Many Jobs?

Let’s consider an example where you are processing 100 jobs (e.g., fetching weather data for 100 cities), but your Supervisor configuration only allows 13 workers (numprocs=13). Here’s how the system manages it:

1. FIFO Queueing

Supervisor handles jobs using a First In, First Out (FIFO) queue.
With 13 workers, only 13 jobs can run simultaneously, while the remaining 87 jobs wait in the queue.

2. Batch Processing

Once a worker completes a task, it immediately picks up another job from the queue.
This creates a continuous cycle where jobs are processed in batches until all are completed.

3. Time to Completion

To calculate the approximate total time required to process all jobs, use this formula:

Total Jobs: 100
Number of Workers: 13
Time per Job: 5 seconds

Total Time = (Total Jobs ÷ Number of Workers) × Time per Job
Total Time = (100 ÷ 13) × 5 = ~38.46 seconds

Does `numprocs` Equal CPU Cores?

No, numprocs does not directly correlate with CPU cores.

For CPU-Intensive Tasks:

If your tasks are CPU-bound (e.g., data processing, video encoding), the number of workers should be limited to the number of available CPU cores to avoid overloading the system.

For I/O-Intensive Tasks:

If your tasks are I/O-bound (e.g., making API calls, reading from disk), you can run more workers than the number of cores, since these tasks spend much of their time waiting for I/O operations to complete.

Example:

On an 8-core machine, you might run 16 workers for API-heavy jobs.

To check the number of CPU cores:

nproc   # Shows the number of CPU cores.
lscpu   # Provides detailed CPU information.

Scaling Your Job Processing in Laravel

Scaling your job processing setup ensures your system remains responsive under heavy workloads. Below are key strategies for scaling:

1. Add More Workers

Increase the number of worker processes (numprocs) to handle more jobs simultaneously. However, be mindful of resource consumption:

numprocs=20

Ensure the server has adequate resources (CPU, memory) to handle the extra load.

2. Prioritize Critical Jobs

You can create separate queues for different job priorities. This ensures that critical tasks are processed first:

[program:high-priority-worker]
command=php artisan queue:work --queue=high
numprocs=6

[program:low-priority-worker]
command=php artisan queue:work --queue=low
numprocs=7

3. Scale Horizontally

Distribute job processing across multiple servers to balance the load. Use a shared queue system like Redis to allow all servers to pull jobs from the same queue:

Set up multiple Supervisor instances on different servers.
Use a distributed queue (e.g., Redis) to synchronize jobs between servers.

4. Monitor and Adjust Configurations

Use tools like Laravel Horizon to monitor your queue workers' performance in real-time. Horizon provides visual insights into job processing, queue lengths, and resource consumption, allowing you to fine-tune configurations as needed.

Finally, given below is a pictorial presentation on how supervisor works:

Conclusion

Supervisor is a powerful tool for managing background processes in large-scale systems. When paired with Laravel’s queue system, it ensures tasks are processed efficiently and reliably, even during peak workloads. By understanding its configuration options, interaction with the Linux kernel, and scaling strategies, you can optimize job processing, ensuring minimal downtime and smooth operations for your users.

By following best practices and leveraging tools like Laravel Horizon and Redis, you can ensure your system remains responsive, scalable, and reliable.

Commit vs. Rollback: Database Transaction Essentials

Md. Asif Rahman — Tue, 25 Jun 2024 19:25:07 +0000

In the world of databases, transactions are akin to journeys—comprising a series of steps or operations performed as a single, cohesive unit of work. Whether you're booking a flight, ordering groceries online, or transferring funds between accounts, transactions play a vital role in ensuring that database operations are reliable, consistent, and resilient. Let's take on a journey through the commit and rollback processes in database transactions, exploring each step with relatable analogies to make the journey more understandable, followed by the technical details.

The Commit Process

1. Initiating the Journey: Begin Transaction

Analogy:

Think of it as the moment you decide to embark on a trip. You gather your essentials and map out your route before setting off. This planning phase ensures that you're prepared for the journey ahead.

Technical Detail:

A transaction begins with the BEGIN TRANSACTION statement. This marks the start of a series of operations that must be executed atomically. All changes made during the transaction are initially tentative and only become permanent upon commit.

2. Logging the Voyage: Write-Ahead Logging (WAL)

Analogy:

Before setting sail, it's wise to create a list of everything you're bringing along. Similarly, the WAL records all changes made by the transaction in a log before they're applied to the database. This log serves as a safety net, allowing for recovery in case of unforeseen circumstances—much like referring back to your list if you forget something during your journey.

Technical Detail:

Before making any changes to the database, the system writes these changes to a write-ahead log (WAL). The WAL is a sequential record of all modifications. By logging changes before they are applied, the database can ensure durability and support recovery in case of a crash.

3. Planning the Itinerary: In-Memory Data Modification

Analogy:

With your journey underway, you begin planning your itinerary and mentally preparing for the adventure. It's akin to mapping out your route and making mental notes of the places you'll visit before physically setting foot on your journey.

Technical Detail:

Changes are initially made in-memory, within the database's buffer cache. This allows for quick response times and reduces the immediate need for disk I/O. The in-memory data structures are updated first, and these changes are later propagated to the disk.

4. Securing the Record: Log Flush

Analogy:

Just as you ensure your list is safely stored in your backpack before hitting the road, the database flushes the log entries to disk to ensure they're durably recorded. This step guarantees that there's a persistent record of the transaction's changes, providing a safety net in case of unexpected detours or interruptions along the way.

Technical Detail:

The log entries recorded in the WAL are flushed to disk to ensure their durability. This means writing the log entries from memory to stable storage, ensuring that they are not lost even if there is a system crash.

5. Confirming the Voyage: Commit Record

Analogy:

As you progress on your journey and decide to commit to the adventure, you officially confirm your plans by signing your name on a travel document. Similarly, in a database, a special commit record is written to the log to mark the transaction as complete. This commitment ensures that the changes made by the transaction are finalized and applied to the database.

Technical Detail:

A commit record is written to the WAL to indicate that the transaction has been successfully completed. This commit record marks the point at which all changes made by the transaction become permanent.

6. Ensuring Durability: Data Page Flush (Deferred)

Analogy:

While you've committed to your journey, you may not immediately load all your belongings onto the transport. Similarly, in a database, modified data pages in the buffer cache are eventually flushed to disk, but not necessarily immediately. This delayed flushing optimizes performance while still ensuring durability, much like waiting for the right moment to load your belongings for maximum efficiency.

Technical Detail:

While the commit ensures the changes are durable, the actual data pages containing the changes might not be immediately written to disk. The database employs a lazy writing strategy, flushing these pages to disk at a later time, optimizing for performance.

The Rollback Process

1. Identifying Uncommitted Changes: Identifying Mistakes in Your List

Analogy:

Suppose you suddenly realize you've forgotten to pack something essential. You identify the items you haven't packed yet. In a database, this means identifying changes made by the transaction that need to be undone.

Technical Detail:

If a transaction needs to be rolled back, the database first identifies all changes made by the transaction that have not been committed. This involves scanning the WAL to find all operations that need to be undone.

2. Undo Log Entries: Erasing Mistakes

Analogy:

You refer back to your packing list to see what items you haven't yet packed and need to remove. Similarly, in a database, undo log entries are used to find information to undo each change made by the transaction.

Technical Detail:

The database uses the WAL to undo each change made by the transaction. For each operation recorded in the WAL, a corresponding undo operation is performed to revert the data to its previous state.

3. Apply Undo Operations: Fixing Mistakes

Analogy:

You unpack the items you previously packed incorrectly, ensuring you're only taking what you need for the trip. In a database, undo operations are applied to in-memory data structures to reverse the changes made by the transaction.

Technical Detail:

The database applies the undo operations to the in-memory data structures, effectively rolling back the changes. This ensures that the database is returned to its state prior to the start of the transaction.

4. Log Rollback: Recording the Change of Plans

Analogy:

You make a note in your travel log that you've decided not to proceed with the trip, keeping a record of the change in plans. Similarly, in a database, a rollback log entry indicates that the transaction was rolled back.

Technical Detail:

A rollback log entry may be written to indicate that the transaction has been rolled back. This helps in maintaining an accurate log for recovery purposes.

5. Release Locks: Freeing Resources

Analogy:

Any reservations or bookings you made for the trip are canceled, freeing up resources for others to use. In a database, releasing locks ensures that other transactions can access the database and make changes without any problems.

Technical Detail:

Any locks held by the transaction on database objects are released. This allows other transactions to access these objects and proceed with their operations.

Conclusion:

In the domain of databases, transactions are like well-planned voyages. Just as you prepare for a trip by packing your essentials and mapping out your route, databases begin transactions by organizing the changes they need to make.

During transaction’s journey, data changes are logged so that nothing gets lost along the way. For example, this log acts as a safety net for databases helping them in recovering after something unexpected happens.

When it is time for a transaction to be committed, it’s just like finalizing plans and making them official. The database ensures all changes are securely saved.

However, if there is an error and a rollback is required it’s just like changing your mind about taking a journey after all. The database cancels out any modifications made by the transaction and restores everything back to how it was before.

Releasing locks at the end of a transaction is like canceling reservations freeing up resources for others to use.

Understanding these processes will help you maintain smooth running of your database systems, reliable data, consistent operations. Whether using apps or shopping online or managing finances those background processes matter which can keep thing running smoothly. Thus next time you communicate with a data base remember committing and rolling back- ensuring you

A Thorough Guide to Redis Data Persistence: Mastering AOF and RDB Configuration

Md. Asif Rahman — Mon, 15 Apr 2024 06:15:18 +0000

Introduction

Redis is a highly efficient, in-memory data structure store that delivers exceptional performance and throughput. However, as an in-memory database, it faces the potential risk of data loss in the event of unexpected server shutdowns. To get rid of this issue, Redis offers two built-in persistence mechanisms: Append Only File (AOF) and Redis Database file (RDB). This article will help you navigate the ins and outs of configuring AOF and RDB for optimal data durability, performance, and reliability.

Redis Persistence: A Closer Look

AOF and RDB are complementary persistence methods with different strengths and trade-offs:

1. AOF Persistence: AOF maintains a log of every write operation performed on the Redis server and uses this log to reconstruct the dataset upon server restart. It's well-suited for applications requiring minimal data loss, as AOF can be fine-tuned to minimize potential data loss.

2. RDB Persistence: RDB generates periodic snapshots of your Redis dataset or based on specific conditions. With its faster operation, RDB is suitable for applications where occasional data loss is acceptable.

Setting Up AOF Persistence

Configure AOF persistence using the following steps:

Open the Redis configuration file (redis.conf) with a text editor.
Search for the appendonly directive.
Set appendonly to yes:

appendonly yes

4.Specify a file path for the AOF file using appendfilename:

appendfilename "appendonly.aof"

5.Optionally, set appendfsync to control how often the AOF file is synced to disk (always, everysec, or no):

appendfsync everysec

6.Save the changes and exit the text editor.

Configuring RDB Persistence

Enable RDB persistence by modifying the redis.conf file as follows:
1.Find the save directive in redis.conf.

2.Set the desired conditions for RDB snapshots. For instance, to save the dataset every 15 minutes if at least 1 key has been changed:

save 900 1

3.Add additional save directives for other conditions, such as save 300 10. It tells redis server to create a snapshot if at least 10 modifications (writes or deletions) have occurred within 300 seconds (5 minutes):

save 900 1
save 300 10

4.Save the changes and exit the text editor.

After updating redis.conf, restart the Redis server for the new settings to take effect.

Optimizing Performance and Durability

Redis allows you to simultaneously utilize AOF and RDB persistence for increased data durability. This combination can minimize data loss by employing AOF for write operations and RDB for accelerating recovery times. Fine-tune AOF's appendfsync and RDB's save directives to achieve a balance between performance and durability.

Monitoring and Backup Strategies

Regularly monitor Redis' performance and disk usage to ensure persistence mechanisms function optimally. Additionally, consider implementing periodic external backups as an extra precautionary measure to enhance data safety.

Conclusion

Configuring AOF and RDB persistence in Redis is essential to ensure data integrity and reliability. This comprehensive guide offers the knowledge and best practices needed for a high-performing Redis deployment. By fine-tuning persistence settings, monitoring performance, and implementing backup strategies, you can create a secure and efficient Redis environment.

The JavaScript Riddle: Cracking the Code of typeof null

Md. Asif Rahman — Mon, 13 Nov 2023 17:21:16 +0000

Introduction:

JavaScript, a language known for its versatility, has a little surprise that can puzzle developers. It has to do with the typeof operator when used with the value null. Oddly, instead of saying null, it says object. In this article, we'll dig into why this happens, where it came from, and how developers can deal with this unexpected twist.

Historical Context:

In the early days of JavaScript, the language was crafted with a simple set of types: "undefined," "boolean," "number," "string," "object," and "function." When the null value was introduced to represent the intentional absence of any object or primitive value, a small design mistake (or perhaps a necessity at that time) occurred. Consequently, when using typeof with null, instead of identifying it as null, it mistakenly reports "object" due to this historical design hiccup.

Despite recognizing this as a mistake, correcting it poses challenges. JavaScript has a commitment to maintaining backward compatibility, and altering the behavior of typeof null might break existing code that relies on this historical quirk. So, developers are encouraged to be aware of this behavior and use other means, such as strict equality (===), to accurately check for null values. This reflects the evolution of the language and the complexities that can arise from decisions made in its early development stages.

According to the ECMAScript specification (the rules that govern JavaScript), null is officially defined as the special value that represents the deliberate absence of any object (you can find this in ECMA-262, section 11.4.3).
ECMA-262 - section 11.4.3

Let's inspect what the NULL actually is:

Even though the result of typeof null might seem odd, it's crucial to know that null isn't really an object like other things in JavaScript. It's a basic value, a special one that shows there's no specific object available. So, despite what typeof might say, null is more like a simple placeholder for the absence of an object.

Have a look at the below code snippets:

console.log(typeof null);  // Outputs: "object"
console.log(null instanceof Object);  // Outputs: false

The instanceof operator, commonly used for determining an object's type, reveals that null is not an instance of the Object constructor.

Conclusion:

Let's sum it up in simpler terms. The odd behavior we observed is like a peculiar artifact from JavaScript's past. Don't let it throw you off! Think of it as a little surprise left by the language's creators.

So, how do you handle it? Well, just use a trick you probably already know: strict equality. Instead of relying on typeof, stick with === when you want to check if something is null. It's like saying, "Hey, are you exactly null? No funny business!"

A real life example of using Late Static Binding in PHP.

Md. Asif Rahman — Wed, 27 Sep 2023 08:42:06 +0000

Introduction:

In the world of software development, creating flexible and dynamic systems is most important. One essential feature of a dynamic system is the ability for subclasses to override and customize functionality inherited from a base class. In PHP, Late Static Binding is a powerful feature that enables this flexibility, allowing subclasses to access their own static properties and methods, even when called through the base class. In this article, we will explore the concept of Late Static Binding through a practical example of a dynamic database query system.

Understanding Late Static Binding:

Late Static Binding (LSB) is a feature in PHP that allows a child class to reference its parent class's static properties or methods using the static keyword. This feature opens the door to dynamic behavior within your classes. It's especially useful when dealing with inheritance and customization of functionality in subclasses.

The Scenario:

Consider a scenario where you are developing a web application with a database. You have a base Database class that contains common functionality for interacting with the database, such as querying and data retrieval. Additionally, you have two subclasses, User and Product, each representing a different entity in your application. These subclasses need to perform database queries specific to their respective tables.

Implementing Late Static Binding:

Let's dive into the code to see how Late Static Binding can help us achieve dynamic database queries:

<?php
class Database {
    protected static $tableName = '';

    public static function getTableName() {
        return static::$tableName;
    }

    public static function query() {
        $tableName = static::getTableName();
        return "SELECT * FROM $tableName";
    }
}

class User extends Database {
    protected static $tableName = 'users';
}

class Product extends Database {
    protected static $tableName = 'products';
}

//Example usage:
User::query(); // Outputs: SELECT * FROM users
Product::query(); // Outputs: SELECT * FROM products

Explanation:

In the Database class, we define a static property $tableName, which represents the name of the database table.
The getTableName() method returns the table name using Late Static Binding with static::$tableName.
The query() method constructs and returns a query string that includes the specific table name obtained using static::getTableName()

Conclusion:

Late Static Binding in PHP is a powerful tool that allows developers to create flexible and dynamic systems. In the example provided, we demonstrated how to use Late Static Binding to implement dynamic database queries in a web application. This feature empowers subclasses to access their own static properties and methods while maintaining a clear and organized class hierarchy. Incorporating Late Static Binding in your PHP applications can greatly enhance their flexibility and maintainability, ultimately leading to more robust and adaptable codebases.

When to use Repository and Service layer and when NOT

Md. Asif Rahman — Wed, 27 Sep 2023 07:50:33 +0000

Are you building RESTful APIs and wondering when to leverage the repository and service layer? Let's dive into this topic!

🔍 Repository Layer: The repository layer acts as an intermediary between your API and the data storage mechanism. It handles data access operations like retrieval, creation, updating, and deletion. It ensures code modularity and provides a consistent interface.

💡 Service Layer: The service layer implements the core business logic of your API. It coordinates different components and enforces business rules, workflows, and data integrity. It also handles authentication and authorization. #BusinessLogic

🚫 When to Avoid Repository and Service Layers:

✅ Lightweight Operations: Simple CRUD operations can be handled directly in your API endpoints or controllers to keep things simple.

✅ External Integrations: Directly make API calls without introducing layers unless there are complex rules or transformations involved.

✅ Middleware: Implement middleware functions without the layers if they don't require complex data access or business logic.

🔎 When to Use Repository and Service Layers:

✅ Complex Business Logic: Use the service layer for intricate business rules, validations, and workflows beyond basic CRUD. #ComplexLogic

✅ Modularity and Reusability: Layers promote code modularity and reuse. Encapsulate common data access or operations within repositories for consistency.

✅ Unit Testing: Separate concerns aid unit testing. Mock the repository layer for focused, granular tests of service layer logic. #UnitTesting

Strike a balance between code organization, maintainability, and performance in your REST API projects. Happy coding! 😄🚀

Implementing Payment Gateways with the Liskov Substitution Principle

Md. Asif Rahman — Fri, 15 Sep 2023 12:40:07 +0000

Introduction

In Laravel, integrating payment gateways while maintaining clean, maintainable, and extensible code can be simplified by applying the Liskov Substitution Principle (LSP), one of the SOLID principles of Object-Oriented Programming (OOP).

LSP suggests that objects of a derived class should be able to replace objects of the base class without affecting the correctness of the program. In the context of Laravel payment gateway integration, you can achieve this by creating a common interface or abstract class for all payment gateways. This ensures that different payment gateways can be easily swapped in and out without disrupting the core functionality of your application.

So, did you get anything?

Ok, No problem.
Let's do it practically. I am using Laravel here but concept is the same for other languages and frameworks.

The Scenario: Processing Payments

Imagine you are building an e-commerce platform, and you need to support multiple payment gateways, such as credit card payments and PayPal. You want to ensure that you can seamlessly switch between these gateways without making extensive changes to your codebase.

Folder Structure:

Note: You can follow any folder structure as per your need

Implementation Steps

1. Create a Base PaymentGateway Class

Start by creating a base PaymentGateway class that defines the common payment processing logic:



<?php

namespace App\Components\PaymentGateways;

class PaymentGateway
{
    public function processPayment($amount)
    {
        // Common payment processing logic
        $transactionId = $this->generateTransactionId();
        $this->logPayment($transactionId, $amount);

        return "Processed a payment of $$amount with Transaction ID: $transactionId";
    }

    protected function generateTransactionId()
    {
        // Generate a unique transaction ID
        return uniqid();
    }

    protected function logPayment($transactionId, $amount)
    {
        // Log payment details
        // Example: Log to a database or external service
    }
}

In base PaymentGateway class, we have added common payment processing logic, including generating a unique transaction ID and logging payment details. This common logic will be shared by all payment gateway subclasses.

Step 2: Implement Subclasses for Payment Gateways

The subclasses are CreditCardPaymentGateway and PaypalPaymentGateway.

CreditCardPaymentGateway Class:



<?php

namespace App\Components\PaymentGateways;

use App\Components\PaymentGateways\PaymentGateway;

class CreditCardPaymentGateway extends PaymentGateway
{
    public function processPayment($amount)
    {
        // Credit card payment specific logic
        $creditCardFee = $this->calculateCreditCardFee($amount);

        // Call the parent class's processPayment method to execute common logic
        $result = parent::processPayment($amount + $creditCardFee);

        // Additional credit card specific logic can be added here if necessary

        return $result;
    }

    protected function calculateCreditCardFee($amount)
    {
        // Calculate and return credit card processing fee
        return $amount * 0.03; // 3% fee as an example
    }
}

In this code, we've defined the CreditCardPaymentGateway class, which serves as a specialized payment gateway for handling credit card payments within our Laravel application. It inherits from the PaymentGateway base class, which likely encapsulates shared payment processing functionality.

The primary function within this class is the processPayment($amount) method. Here, we introduce credit card-specific processing logic. Notably, it calculates a credit card processing fee by invoking the calculateCreditCardFee($amount) method. In this example, we've applied a 3% fee rate for illustrative purposes.

Additionally, the CreditCardPaymentGateway class adheres to the Liskov Substitution Principle (LSP) by calling the processPayment method of the parent class (PaymentGateway). This ensures that any common payment processing logic, such as logging or transaction tracking, from the base class is also executed.

Let's create another subclass called PaypalPaymentGateway

PayPalPaymentGateway Class:



<?php
namespace App\Components\PaymentGateways;

use App\Components\PaymentGateways\PaymentGateway;

class PaypalPaymentGateway extends PaymentGateway
{
    public function processPayment($amount)
    {
        // PayPal payment specific logic
        $paypalFee = $this->calculatePayPalFee($amount);

        // Call the parent class's processPayment method to execute common logic
        $result = parent::processPayment($amount + $paypalFee);

        // Additional PayPal specific logic can be added here if necessary

        return $result;
    }

    protected function calculatePayPalFee($amount)
    {
        // Calculate and return PayPal processing fee
        return $amount * 0.02; // 2% fee as an example
    }
}

Similarly, we've implemented the PayPalPaymentGateway class to manage PayPal payments within our Laravel application. This class extends the PaymentGateway base class to leverage shared payment processing capabilities.

The focal point of this class is the processPayment($amount) method, where we've incorporated PayPal-specific processing steps. It calculates the PayPal processing fee by making use of the calculatePayPalFee($amount) method, which assumes a 2% fee rate as an example.

Just like the CreditCardPaymentGateway, the PayPalPaymentGateway class adheres to the Liskov Substitution Principle (LSP) by invoking the processPayment method of the parent class (PaymentGateway). This ensures that common payment processing logic shared across various payment gateways is consistently executed.

These two classes provide a structured and extensible approach for integrating different payment gateways into our Laravel application, promoting code maintainability and ease of use.

Step 3: Configure the payment gateways in Laravel's route service provider as we pass gateway name from url.



<?php

namespace App\Providers;

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;
use Illuminate\Support\Facades\Route;
use Illuminate\Support\Str;

class RouteServiceProvider extends ServiceProvider
{
    /**
     * The path to your application's "home" route.
     *
     * Typically, users are redirected here after authentication.
     *
     * @var string
     */
    public const HOME = '/home';

    /**
     * Define your route model bindings, pattern filters, and other route configuration.
     */
    public function boot(): void
    {

        RateLimiter::for('api', function (Request $request) {
            return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
        });

        $this->routes(function () {
            Route::middleware('api')
                ->prefix('api')
                ->group(base_path('routes/api.php'));

            Route::middleware('web')
                ->group(base_path('routes/web.php'));
        });

        //Here is the logic to bind route params to respective class to intentiate gateway classes

        Route::bind('gateway', function ($gateway) {
            // Define the namespace where your payment gateway classes reside.
            $namespace = 'App\\Components\\PaymentGateways\\';

            // Create the fully qualified class name based on the route parameter.
            $className = $namespace . Str::studly($gateway) . 'PaymentGateway';

            // Check if the class exists.
            if (class_exists($className)) {
                // Instantiate the class dynamically.
                return app()->make($className);
            }
            // Handle the case when the provided $gateway parameter does not correspond to a valid class.
            return abort(404); // Or any other appropriate action.
        });
    }
}

Step 4: Create a route to handle the payment



use Illuminate\Support\Facades\Route;
use App\Http\Controllers\CheckoutController;

Route::get('/', function () {
    return view('welcome');
});

Route::get('/checkout/{gateway}', [CheckoutController::class, 'processPayment']);

Step 5: Create a CheckoutController to process the payment.



// app/Http/Controllers/CheckoutController.php
namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\PaymentGateway;

class CheckoutController extends Controller {
    public function processPayment(Request $request, PaymentGateway $gateway) {
        // Common checkout logic

        $amount = 100; // Example amount

        // Process payment using the provided gateway
        $result = $gateway->processPayment($amount);

        return view('checkout', ['result' => $result]);
    }
}

Step 6: Create a view file just to see the result



<!-- resources/views/checkout.blade.php -->
<!DOCTYPE html>
<html>
<head>
    <title>Checkout Result</title>
</head>
<body>
    <h1>Payment Result</h1>
    <p>{{ $result }}</p>
</body>
</html>

With this code, you can now make payments using different gateways by specifying the gateway in the URL. For example, /checkout/credit-card or /checkout/paypal. The controller will use the appropriate payment gateway without needing to change the controller's code, demonstrating the Liskov Substitution Principle.

Conclusion

In this practical guide, we've demonstrated how to integrate payment gateways into a Laravel application while adhering to the principles of Object-Oriented Programming (OOP), specifically the Liskov Substitution Principle (LSP). By following these steps, you can maintain clean, maintainable, and extensible code for handling payments in your e-commerce platform.

Summary of Achievements

1. Created a Base PaymentGateway Class: We established a PaymentGateway base class containing common payment processing logic, such as generating transaction IDs and logging payment details. This base class acts as a blueprint for all payment gateway implementations.

2. Implemented Subclasses for Payment Gateways: We developed two specialized payment gateway subclasses, CreditCardPaymentGateway and PayPalPaymentGateway. These subclasses extend the PaymentGateway base class and provide payment-specific logic while preserving the ability to replace one gateway with another seamlessly.

3. Configured Payment Gateways: Laravel's service provider was utilized to bind instances of the payment gateway classes. This setup allows for easy switching between payment gateways by changing configuration settings.

4. Created a Route and Controller: We defined a route that accepts the selected payment gateway as a parameter and a controller that handles the payment processing. The controller utilizes the selected payment gateway instance to process payments.

5. Developed a Checkout View: A simple view was created to display the payment processing result to the user.

By applying the Liskov Substitution Principle and following these steps, your Laravel application can accommodate various payment gateways without extensive code changes, enhancing code maintainability, extensibility, and flexibility in handling payments for your e-commerce platform. This approach simplifies the integration of new payment gateways in the future, ensuring a smooth payment processing experience for your users.

Now, you have a solid foundation to expand your payment processing capabilities and adapt to changing payment methods or providers as your business needs evolve.

Here is the code https://github.com/asifzcpe/laravel-solid-principles

Resetting MySQL Root Password in Ubuntu: A Step-by-Step Guide

Md. Asif Rahman — Tue, 25 Jul 2023 22:14:18 +0000

Introduction:
Losing or forgetting the MySQL root password can be a stressful situation, but don't worry; there's a way to regain access to your MySQL database in Ubuntu. In this article, I will walk you through a step-by-step guide on how to reset the MySQL root password on your Ubuntu system. We will use a method that involves stopping the MySQL service, creating a temporary configuration file, and setting a new password for the root user.

Step 1: Stop the MySQL Service
The first step is to stop the MySQL service to ensure we can safely proceed with the password reset process. Open your terminal and run the following command:

sudo service mysql stop

Step 2: Create a Temporary Configuration File
Next, we'll create a temporary configuration file to start the MySQL service without password authentication. This will allow us to reset the root password. Run the following command to create the file:

sudo nano /etc/mysql/mysql.conf.d/reset-mysql-password.cnf

Step 3: Add Configuration to the File
In the nano editor, add the following lines to the reset-mysql-password.cnf file.

[mysqld]
skip-grant-tables

To save the changes and exit the editor, press CTRL + X, then type Y, and finally, press Enter.

Step 4: Start MySQL Service in Safe Mode
With the temporary configuration file in place, start the MySQL service in safe mode:

sudo mysqld_safe --skip-grant-tables &

Step 5: Connect to MySQL Without Password
Now, we can connect to the MySQL server without entering a password. Open a new terminal window and run the following command:

mysql -u root

Step 6: Set a New Password for Root User
Once you are connected to the MySQL prompt, it's time to set a new password for the root user. Execute the following SQL commands:

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'YOUR_NEW_PASSWORD';

Replace 'YOUR_NEW_PASSWORD' with your desired password. The FLUSH PRIVILEGES; command ensures that the changes take effect immediately.

If you get the following error while using weak password

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

You can fix this like below, if you want to use weak password(Not recommended)

SHOW VARIABLES LIKE 'validate_password%';
SET GLOBAL validate_password.policy=LOW;

Now again run the password update sql:

Step 7: Exit MySQL and Remove the Configuration File
After setting the new password, exit the MySQL prompt:

exit;

Remove the temporary configuration file:

sudo rm /etc/mysql/mysql.conf.d/reset-mysql-password.cnf

Step 8: Restart MySQL Service
Finally, restart the MySQL service to apply the changes:

sudo service mysql restart

Congratulations! You have successfully reset the MySQL root password on your Ubuntu system. Now you can access your MySQL database using the new password you set. Always make sure to keep your MySQL root password secure .

Choosing Between Static and Non-Static Methods in PHP: Real-World Use Cases and Code Examples

Md. Asif Rahman — Fri, 07 Jul 2023 19:18:52 +0000

Introduction

In PHP development, selecting between static and non-static methods holds significant importance when it comes to code organization and functionality. Both approaches provide unique benefits and are applicable in different scenarios. This article aims to examine the utilization of static and non-static methods in PHP using practical illustrations. By comprehending the appropriate usage of each approach, you can design code that is more effective and easier to maintain.

Scenarios to use static methods:

1. Data validation utility:
Demonstrating a static method for email validation, which can be accessed without instantiating the class.

2. Logging utility:
Implementing a static method to handle logging functionality for easy access throughout the application.

3. Factory Methods:
Static methods can be used as factory methods to create instances of a class, encapsulating the object creation logic.

3. Configuration Handling:*
Static methods can be useful for handling configuration settings or retrieving values from a configuration file.

Scenarios to use non-static methods:

1. Order Processing:
Illustrating a non-static method to add items to an order and process the order using instance-specific data.

So, now you may have a question here, something like - what would happen, if we used static methods here.
Don't worry, here is the reason :

If we were to use static methods in the Order class instead of non-static methods, several consequences would arise. Firstly, static methods do not have access to instance-specific data, such as the items array, as they operate at the class level rather than on individual objects. This would lead to shared data among all instances of the class, making it impossible to maintain separate order details. Secondly, encapsulation and re-usability would be compromised, as static methods cannot encapsulate functionality and data within specific instances, hindering code organization and modularity. Lastly, static methods lack the flexibility of dependency management, as they are not designed to handle dynamic dependencies, making it difficult to inject additional services or dependencies.

In summary, using static methods would result in shared data, reduced encapsulation, limited re-usability, and inadequate dependency management within the Order class.

2. Database Connection Wrapper:
Creating a non-static method to establish a database connection and perform queries using the instance-specific connection.

So far, I have shown the example code for static and non-static methods separately. Now, it is turn to show an example code to use both static and non-static methods together:

I hope, by this far, you have understood when to use static method and when not to use.

I can share with you one more scenario that we have faced or face many times while writing code in for example, service classes. We need to think which methods in a service class will be static or non-static. So, here is a check list to identify if you need to write a method static or non-static:

Use Non-Static Methods When:

Instance-Specific Data: When you need to access or modify data specific to each object instance.
Encapsulation and Reusability: When you want to encapsulate functionality and data within individual instances, promoting better code organization and modularity.
Independent Processing: When each object should be able to perform operations independently without affecting other instances.
Dependency Management: When you require the flexibility of injecting additional services or dependencies as constructor arguments or method parameters.

Use Static Methods When:

Class-Level Operations: When the functionality does not depend on or modify instance-specific data and can be performed at the class level.
Utility Functions: When the method provides common utility functions that do not rely on instance state.
Global Operations: When the functionality is applicable across multiple instances and does not require individual data.

By taking these guidelines into consideration, you can make well-informed choices regarding the usage of static or non-static methods that align with the specific requirements of your PHP code.

Enhancing Memory Efficiency in Ecommerce Applications with the Flyweight Pattern

Md. Asif Rahman — Sun, 11 Jun 2023 20:45:31 +0000

Introduction:
Efficient memory management is essential for building high-performing ecommerce applications that can handle large product catalogs and provide a seamless user experience. One powerful design pattern that can significantly improve memory efficiency is the Flyweight pattern. By leveraging this pattern, ecommerce applications can reduce memory consumption by sharing common data among similar objects. In this article, we will explore how the Flyweight pattern can be implemented in a real-world ecommerce application using code examples.

Understanding the Flyweight Pattern:
The Flyweight pattern is a structural design pattern that focuses on minimizing memory usage by sharing data between objects. It achieves this by splitting object state into intrinsic and extrinsic parts. The intrinsic state, which is shared among multiple objects, is stored externally and can be accessed by these objects. The extrinsic state, which is unique to each object, is stored separately. This separation eliminates the need to duplicate the intrinsic state, resulting in significant memory savings.

Flyweight Pattern in Ecommerce:
In an ecommerce application, product images are an integral part of the user experience. However, if multiple products share the same image, storing individual instances of the image for each product can lead to memory wastage. Let's consider a simplified example of an ecommerce product listing page to demonstrate the implementation of the Flyweight pattern.

class Product
{
    private $name;
    private $price;
    private $image;

    public function __construct($name, $price, $image)
    {
        $this->name = $name;
        $this->price = $price;
        $this->image = $image;
    }

    // Other methods...

    public function display()
    {
        echo "Product: {$this->name}, Price: {$this->price}, Image: {$this->image->getUrl()}\n";
    }
}

class Image
{
    private $url;

    public function __construct($url)
    {
        $this->url = $url;
    }

    public function getUrl()
    {
        return $this->url;
    }
}

class ImageFlyweightFactory
{
    private $images = [];

    public function getImage($url)
    {
        if (!isset($this->images[$url])) {
            $this->images[$url] = new Image($url);
        }

        return $this->images[$url];
    }
}

// Client code
$imageFactory = new ImageFlyweightFactory();

$products = [
    new Product('Product 1', 19.99, $imageFactory->getImage('product1.jpg')),
    new Product('Product 2', 29.99, $imageFactory->getImage('product1.jpg')),
    new Product('Product 3', 39.99, $imageFactory->getImage('product2.jpg')),
];

foreach ($products as $product) {
    $product->display();
}

In this example, the Product class represents a product with attributes such as name, price, and an image. The Image class encapsulates the image data, and the ImageFlyweightFactory acts as the flyweight factory, managing the creation and sharing of image instances.

When creating product objects, we utilize the flyweight factory to retrieve image instances. If the image with a specific URL has not been created before, the factory creates a new instance and stores it for future use. If the image has already been created, the existing instance is retrieved and reused.

By sharing image instances among products, the Flyweight pattern eliminates the need to duplicate image data, resulting in reduced memory consumption. The display() method in the Product class demonstrates how the shared image instance is used for displaying product information.

Benefits of Using the Flyweight Pattern in Ecommerce:

Memory Optimization: The Flyweight pattern significantly reduces memory consumption by sharing common data among objects, leading to efficient memory usage, especially when dealing with large product catalogs.

Improved Performance: By eliminating redundant data storage and duplication, the Flyweight pattern enhances application performance, resulting in faster response times and a smoother user experience.

Scalability: With reduced memory overhead, ecommerce applications can handle increased traffic and larger product catalogs without sacrificing performance or exhausting system resources.

Conclusion:
Efficient memory management is crucial for building high-performing ecommerce applications. The Flyweight pattern offers an elegant solution by minimizing memory consumption through the sharing of common data among objects. By implementing the Flyweight pattern in an ecommerce application, developers can optimize memory usage, improve performance, and provide a seamless shopping experience for users.

Crafting Custom Furniture and Seamless Database Queries: Unlocking the Power of the Builder Design Pattern

Md. Asif Rahman — Thu, 25 May 2023 19:15:19 +0000

Introduction
The Builder design pattern is a powerful tool in software development that facilitates the creation of complex objects in a step-by-step manner. While its application is often seen in software projects, the Builder pattern can also be applied to real-life scenarios, such as calculating the price of custom-made furniture. In this article, we will explore how the Builder pattern can simplify furniture price calculation by allowing customers to select different parts and configurations for their furniture pieces.

Understanding the Builder Design Pattern
The Builder design pattern is a creational pattern that separates the construction of an object from its representation. It allows the step-by-step creation of objects, where each step involves configuring different parts or aspects of the object. By utilizing method chaining, the Builder pattern provides an intuitive and readable way to construct complex objects.

Real-Life Example: Furniture Price Calculation
Imagine a furniture store that offers custom-made furniture, allowing customers to select different parts and configurations to build their ideal piece. Let's consider a furniture price calculator that applies the Builder pattern to calculate the price based on the selected parts. Here's an example implementation in JavaScript:

Result:

Explanation of the Code
In this example, we have a FurnitureBuilder class that represents the furniture price calculator. Here's a breakdown of the code:

The FurnitureBuilder class has methods to add different parts of the furniture and update the price accordingly.

addFrame(frame), addSeat(seat), and addBackrest(backrest) are methods to add the corresponding parts to the furniture.
Each part object has properties such as type, material, or style to represent different configurations.

The build() method returns an object with the selected parts and the total price of the furniture.
By using the Builder pattern, customers can select the desired parts for their furniture, such as the frame, seat, and backrest, and the price calculator automatically updates the price based on the selections.

Let's see another real life example of builder design pattern

Creating Query Builders for Database Interactions
The Builder pattern is also beneficial when constructing database queries dynamically. Let's explore an example using JavaScript and demonstrate the creation of a query builder for SQL database interactions:

In this example, the QueryBuilder class provides methods for constructing SQL queries step by step. Customers can specify the select fields, the table to query from, conditions for filtering, and the order of the results. The exec() method returns the final constructed query as a string. By utilizing the Builder pattern, the creation of dynamic and complex database queries becomes more readable and maintainable.

Conclusion

The Builder design pattern offers flexibility and maintainability in various real-life scenarios. By applying the Builder pattern, customers can easily create custom furniture with different parts and configurations. Additionally, developers can construct dynamic database queries using query builders, simplifying the process of interacting with databases. Whether it's building physical objects or constructing software components, the Builder pattern provides an elegant solution for step-by-step construction and customization.

Improving Your E-Commerce Shipping Module Efficiency: A Guide to Dynamic Class Instantiation using the Strategy Pattern in PHP

Md. Asif Rahman — Tue, 21 Mar 2023 16:18:19 +0000

In e-commerce platforms, shipping is an important part of the overall business strategies. The shipping module of an e-commerce platform needs to be designed in a way that allows for flexibility in shipping methods and pricing. This is where the strategy pattern can be used. In this blog post, we'll explore the strategy pattern in PHP using the shipping module of an e-commerce platform as an example.

Let's first try to understand what problems strategy design pattern solves.

The Strategy Pattern

The strategy pattern is a design pattern that allows you to define a family of algorithms, encapsulate each one, and make them interchangeable. This pattern lets the algorithm vary independently from the clients that use it. In other words, it allows you to interchange different algorithms without changing the code that uses them.

Problem Example

The shipping module of an e-commerce platform is a perfect use case for the strategy pattern. There are many different ways to handle shipping, and each method has its own set of rules and calculations. By using the strategy pattern, you can define each shipping method as a separate algorithm, and the e-commerce platform can easily switch between them without changing the code that handles the shipping.

Implementing the Strategy Pattern in PHP

To implement the strategy pattern in PHP, we'll need to create a few classes. First, we'll create an interface called ShippingStrategy. This interface will define the methods that all shipping strategies must implement.

Next, we'll create a class for each shipping method that implements the ShippingStrategy interface. For example, we could create a class called StandardShipping that implements the ShippingStrategy interface and handles the logic for standard shipping.

We may have another class for DomesticShipping and InternationalShipping that implements the ShippingStrategy interface and handles the logic for standard shipping.

DomesticShipping Class

InternationalShipping Class

Now, we will class a Shipping class that will calculate the shipping cost and estimated delivery date on the basis of the shipping type provided via its __construct() method.

In above image, the "Shipping" class represents a shipping service that calculates the shipping cost and estimates the delivery date based on the chosen shipping type. It uses the strategy pattern to dynamically select the appropriate shipping strategy based on the given shipping type, and delegates the calculation of the shipping cost and estimated delivery date to the selected strategy object.

Let's see how to use this class.

Here, we are passing $shippingType that can be of any type/strategy that we have implemented.

Here, you can find the github repo link to understand it in better way.

Gihub Repo

DEV Community: Md. Asif Rahman

Mastering Background Job Processing with Supervisor and Laravel Queues

What is Supervisor, and Why Should You Care?

Supervisor Overview

Key Features of Supervisor

Analogy: Supervisor as a Factory Manager

How Supervisor Works on the Kernel Level

Kernel Process Management

Supervisor’s Interaction with the Kernel

How to Set Up Supervisor for Laravel Queues

Basic Configuration

Explanation

Save and Apply Configuration

Monitor Workers

What Happens When You Have Too Many Jobs?

1. FIFO Queueing

2. Batch Processing

3. Time to Completion

Does numprocs Equal CPU Cores?

For CPU-Intensive Tasks:

For I/O-Intensive Tasks:

Example:

To check the number of CPU cores:

Scaling Your Job Processing in Laravel

1. Add More Workers

2. Prioritize Critical Jobs

3. Scale Horizontally

4. Monitor and Adjust Configurations

Conclusion

Commit vs. Rollback: Database Transaction Essentials

The Commit Process

1. Initiating the Journey: Begin Transaction

Analogy:

Technical Detail:

2. Logging the Voyage: Write-Ahead Logging (WAL)

Analogy:

Technical Detail:

3. Planning the Itinerary: In-Memory Data Modification

Analogy:

Technical Detail:

4. Securing the Record: Log Flush

Analogy:

Technical Detail:

5. Confirming the Voyage: Commit Record

Analogy:

Technical Detail:

6. Ensuring Durability: Data Page Flush (Deferred)

Analogy:

Technical Detail:

The Rollback Process

1. Identifying Uncommitted Changes: Identifying Mistakes in Your List

Analogy:

Technical Detail:

2. Undo Log Entries: Erasing Mistakes

Analogy:

Technical Detail:

3. Apply Undo Operations: Fixing Mistakes

Analogy:

Technical Detail:

4. Log Rollback: Recording the Change of Plans

Analogy:

Technical Detail:

5. Release Locks: Freeing Resources

Analogy:

Technical Detail:

Conclusion:

A Thorough Guide to Redis Data Persistence: Mastering AOF and RDB Configuration

Introduction

Redis Persistence: A Closer Look

Setting Up AOF Persistence

Configuring RDB Persistence

Optimizing Performance and Durability

Monitoring and Backup Strategies

Conclusion

The JavaScript Riddle: Cracking the Code of typeof null

Introduction:

Historical Context:

Let's inspect what the NULL actually is:

Have a look at the below code snippets:

Conclusion:

Does `numprocs` Equal CPU Cores?