DEV Community: Mohamed Fakhr

SaaS (Software as a Service)

Mohamed Fakhr — Sat, 29 Aug 2026 15:06:10 +0000

When building a SaaS (Software as a Service) project, the database architecture is one of the most important decisions.
There are two common approaches to multi‑tenant SaaS database design:

Option 1:
One database per client (separate database per tenant)
How it works:
Each client (tenant) gets their own database.

Your application (same codebase) connects dynamically to the tenant’s database based on their domain, subdomain, or login.

Pros:

Strong data isolation – clients’ data is completely separated.
Easier to migrate/export data or comply with regulations (e.g., GDPR).
Less risk that a bug or query exposes other tenants’ data.
You can scale some clients separately if needed (e.g., move a big client’s DB to a bigger server).

Cons:

Harder to manage upgrades or schema changes (you must migrate many databases).
Higher infrastructure cost (many DB instances).
More complex DevOps (backups, monitoring, migrations for each DB).

Option 2:
All clients share the same database (single database, multi‑tenant)
How it works:
One database contains all tenants’ data.

Every table that stores tenant-specific data has a tenant_id (or company_id) column to separate data logically.

Pros:

Easier to manage (only one DB schema to upgrade).
Cheaper to host (one DB server).
Easier to run analytics across tenants.
Simpler CI/CD pipeline.

Cons:

Security risk if not done carefully – you must always filter by tenant_id in every query, otherwise data leaks between tenants.
Harder to export one client’s data separately.
A large single DB can become a bottleneck if you have thousands of tenants.

What to consider if using a single database:

Add tenant_id to all tenant-specific tables.
Apply row-level security or strict query filters (e.g., in Laravel use global scopes or middleware).
Use indexes on tenant_id to keep queries fast.
Be careful with shared tables (like product catalog) vs tenant-specific tables (like orders).
Backups: you’re backing up everyone’s data together, so plan recovery carefully.
Scaling: eventually you may need read replicas, sharding by tenant_id, or moving heavy tenants to their own DB.

Which one should you choose:

If you expect a few big enterprise clients that might demand strict isolation or their own backups → use separate databases per client.
If you expect many small clients (e.g., hundreds/thousands of small shops) → use one shared database with tenant_id (multi‑tenant).

Single DB:

Add tenant_id to tables.
Use middleware to set where('tenant_id', $tenantId) globally.

Multi DB:

Have a tenants table in a main DB storing DB connection info (host, username, password).
On request, resolve the tenant and dynamically set the DB connection (using DB::purge() / DB::reconnect()).

Laravel Application Optimization

Mohamed Fakhr — Mon, 24 Aug 2026 17:46:52 +0000

A. Database & Eloquent Optimization
1- Eager Loading (N+1 Problem):
Avoid the N+1 query problem by eager loading relationships when querying models.
Bad (N+1):

$posts = App\Models\Post::all();
foreach ($posts as $post) {
    echo $post->user->name; // Each user call is a new query
}

Good (Eager Loading):

$posts = App\Models\Post::with('user')->get();
foreach ($posts as $post) {
    echo $post->user->name; // Only 2 queries (Post + User)
}

2- Select Specific Columns:
Don't select all columns select('*') if you only need a few.
$users = User::select('id', 'name', 'email')->get();

3- Use Indexes:
Ensure your database columns that are frequently used in WHERE, JOIN, ORDER BY clauses have proper indexes.
Add indexes in your migrations:

$table->string('email')->unique(); // Unique automatically creates an index
$table->index('category_id'); // Custom index

4- Pagination for Large Datasets:
Never load all records if you have a large table. Use paginate() or simplePaginate().

 $users = User::paginate(15);

5- chunk() for Processing Large Datasets:
When processing many records (e.g., for background jobs), use chunk() or cursor() to avoid loading all records into memory at once.

Post::chunk(200, function ($posts) {
      foreach ($posts as $post) {
          // Process post
      }
  });

6- exists() instead of count() for existence checks:
If you just need to know if a record exists, exists() is more efficient than count() as it stops at the first match.

if (User::where('email', $email)->exists()) 
{ /* ... */ }

B. Caching
1- Route Caching:
If you have many routes, caching them significantly speeds up route registration.
Run in production: php artisan route:cache
Remember to clear it php artisan route:clear and re-cache after any route changes.
2- Configuration Caching:
Combines all your configuration files into a single file for faster loading.
Run in production: php artisan config:cache
Clear php artisan config:clear and re-cache after config changes.
3- View Caching:
Caches your Blade compiled views, so they don't have to be recompiled on every request.
Run in production: php artisan view:cache
Clear php artisan view:clear after view changes.
4- Application Data Caching:
Cache frequently accessed data that doesn't change often (e.g., settings, categories, static content).
Use Cache::remember(), Cache::put(), Cache::get() with a suitable driver (Redis or Memcached are much faster than file-based).

C. Queues (Background Processing)
Offload Heavy Tasks:
Move time-consuming tasks (email sending, image processing, video encoding, complex calculations, third-party API calls) to background queues.
This allows your web requests to return a response quickly, improving user experience.
Example:
Instead of:
Mail::to($user->email)->send(new WelcomeEmail($user));
Use a job:
dispatch(new App\Jobs\SendWelcomeEmail($user));
Remember to configure a queue driver (e.g., database, redis, sqs) and run a queue worker php artisan queue:work.

D. Asset Optimization
1- CDN (Content Delivery Network):
Serve static assets (images, CSS, JS) from a CDN to reduce latency for users geographically distant from your server.
2- Image Optimization:
Compress images before deploying. (using tools like TinyPNG, ImageOptim, or build tools)
3- Minification:
Combine multiple CSS files into one and multiple JS files into one.
Minify CSS and JavaScript to remove whitespace and comments.

E. PHP & Server Environment
1- Use the Latest PHP Version:
Always use the latest stable PHP version. Each new version brings significant performance improvements.
2- Enable OPcache:
OPcache is a PHP extension that caches precompiled script bytecode in memory, avoiding the parsing and compilation on every request. It's crucial for PHP application performance.
Ensure it's enabled and configured correctly in your php.ini.
3- Composer Optimization:
In production, install Composer dependencies without dev dependencies:
composer install --no-dev --optimize-autoloader --optimize-autoloader builds a faster class map.
4- JIT Compiler (PHP 8+):
PHP 8's JIT (Just-In-Time) compiler can provide significant performance boosts for CPU-bound tasks.
Ensure it's enabled and configured in php.ini if your workload can benefit from it.
5- HTTP/2 and GZIP Compression:
Configure your web server (Nginx or Apache) to use HTTP/2 and GZIP compression.
HTTP/2: Allows multiple requests/responses over a single connection, reducing latency.
GZIP Compression: Compresses text-based assets (HTML, CSS, JS) before sending them to the client, reducing bandwidth usage.
6- Proper Server Configuration:
Use a fast web server like Nginx (preferred over Apache for performance).
Tune PHP-FPM settings (e.g., pm.max_children, pm.start_servers) based on your server's resources and traffic.
7- Choose a Good Hosting Provider:
A cheap, overloaded shared host will negate many of your optimization efforts. Invest in a good VPS or dedicated server.

F. Code Quality & Best Practices:
1- Remove Unused Packages & Services:
Audit your composer.json and config/app.php. Remove any packages or service providers you don't actually need.
2- Limit Middleware Usage:
Middleware adds overhead. Only apply middleware where absolutely necessary.
3- Don't Use APP_DEBUG=true in Production:
This is a major performance killer. Set APP_DEBUG=false in your .env for production.
4- Minimize Logging:
Adjust LOG_LEVEL in production (e.g., warning or error) to reduce disk I/O from excessive logging.

Security Features in Laravel

Mohamed Fakhr — Sun, 23 Aug 2026 18:11:04 +0000

1- Authentication
Laravel offers a complete authentication system that can be customized to fit your needs. The built-in Auth facade provides methods to manage user registration, login, logout, password reset, and email verification.

use Illuminate\Support\Facades\Auth;

// Check if the user is authenticated
if (Auth::check()) {
    // The user is logged in
}

2- Authorization
Laravel includes a simple and easy-to-use authorization system. You can use policies and gates to control user access to various parts of your application.

Using policy:

// Create a policy
php artisan make:policy PostPolicy

// Register the policy in AuthServiceProvider
protected $policies = [
    'App\Models\Post' => 'App\Policies\PostPolicy',
];

// Define a method in PostPolicy
public function update(User $user, Post $post)
{
    return $user->id === $post->user_id;
}

Using gates:

use Illuminate\Support\Facades\Gate;

Gate::define('update-post', function ($user, $post) {
    return $user->id == $post->user_id;
});

if (Gate::allows('update-post', $post)) {
    // The user can update the post
}

3- CSRF Protection
Laravel automatically generates a CSRF token for each active user session managed by the application. This token is used to verify that the authenticated user is the one actually making the requests to the application.

In HTML forms:

  <form method="POST" action="/example">
      @csrf
      <!-- Your form inputs here -->
  </form>

4- Hashing
Laravel provides a secure way to hash passwords using the Hash facade.

Usage:

use Illuminate\Support\Facades\Hash;

// Hashing a password
$hashedPassword = Hash::make('password');

// Checking a password against a hash
if (Hash::check('password', $hashedPassword)) {
    // The passwords match...
}

5- Input Validation
Laravel provides a powerful validation mechanism to ensure that the data received from the user is valid before it is processed.

Usage:

use Illuminate\Http\Request;

public function store(Request $request)
{
    $validated = $request->validate([
        'title' => 'required|max:255',
        'body' => 'required',
    ]);

    // The data is valid...
}

6- SQL Injection Protection
By using Eloquent ORM or the query builder, Laravel protects your application from SQL injection attacks.

Usage:

// Using Eloquent ORM
$user = User::where('email', $email)->first();

// Using query builder
$user = DB::table('users')->where('email', $email)->first();

7- XSS Protection
Laravel automatically escapes data that is output in views to prevent cross-site scripting (XSS) attacks.

Usage: Blade

<!-- Blade template -->
{{ $userInput }} <!-- This will be escaped -->
{!! $userInput !!} <!-- This will not be escaped -->

8- Rate Limiting
Laravel provides rate limiting to prevent abuse of your application by limiting the number of requests a user can make to your application.

Usage:

use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('global', function (Request $request) {
    return Limit::perMinute(60);
});

9- File Upload Security
When handling file uploads, Laravel provides methods to ensure that the uploaded files are of expected types and sizes.

Usage:

$request->validate([
    'photo' => 'required|file|mimes:jpeg,png,jpg,gif|max:2048',
]);

Best Practices:

Always use the latest version of Laravel to ensure you have the latest security updates.
Regularly update your dependencies using Composer.
Use environment variables to manage sensitive information.
Set proper permissions on your server to restrict access to files and directories.
Regularly back up your data and test your backup strategy.
Monitor and log your application for unusual activity and sensitive actions.

RESTful APIs

Mohamed Fakhr — Sat, 15 Aug 2026 22:05:11 +0000

First, what is the difference between RESTful APIs and REST APIs?
REST API:

Used for simple projects and doesn't require a complex system.
It offers flexibility and is easy to implement, especially for smaller applications or quick prototypes.
Based on REST principles, but not strictly following all constraints.
Might use POST or GET for all data transfers.
Can represent resources in various formats (XML, JSON, HTML, etc.)
Can be flexible and varied (e.g., /deleteUser?id=5).

RESTful APIs:

Used for large-scale, Complex Applications.
For performance and scalability if the project requires optimized performance with high scalability and handles large volumes of data and high traffic.
Strictly according to REST standards.
Strictly uses HTTP methods in a RESTful manner (GET, POST, PUT, DELETE)
Follows a uniform format for resources, typically JSON or XML
Uses a standardized and uniform URL structure (e.g., DELETE /users/5).

Representational state transfer (REST) is a set of architectural principles that define how to build application programming interfaces (APIs), which allow data to be communicated between web applications.

When a request for data is sent to a REST API, it’s usually done through hypertext transfer protocol (commonly referred to as HTTP).
Once a request is received, APIs designed for REST (called RESTful APIs or RESTful web services) can return messages in a variety of formats: HTML, XML, plain text, and JSON.
In this way, RESTful APIs are more flexible and can be easier to set up.

Note: JSON (JavaScript Object Notation) is favored as a message format because it can be read by any programming language, is human- and machine-readable, and is lightweight.

REST supports all HTTP methods: GET, POST, PUT & DELETE.
GET: Retrieve particular resources by an ID
POST: Create a new resource.
PUT: Update a particular resource by an ID.
DELETE: Remove a particular resource.

Note about PUT & PATCH:
PUT is used when you have all the updated data, while PATCH is suitable for partial updates.

Laravel Eloquent ORM (Object-Relational Mapper) Relationships

Mohamed Fakhr — Thu, 13 Aug 2026 10:21:05 +0000

One-to-One Relationship:

users
id - integer
name - string

phones
id - integer
user_id - integer

In the User model:

public function phone()
{
   return $this->hasOne(Phone::class);
}

In the Phone model:

public function user()
{
   return $this->belongsTo(User::class);
}

One-to-Many Relationship:

posts
id - integer
name - string

comments
id - integer
post_id - integer

In the Post model:

public function comments()
{
     return $this->hasMany(Comment::class);
}

In the Comment model:

public function post()
{
        return $this->belongsTo(Post::class);
}

Many-to-many Relationship:

users
id - integer
name - string

roles
id - integer
name - string

role_user (Pivot table)
user_id - integer
role_id - integer

In User model

public function roles()
{
    return $this->belongsToMany(Role::class, 'role_user');
}

In Role model:

public function users()
{
     return $this->belongsToMany(User::class, 'role_user');
}

Important Note:

The pivot table is always singular; if you give it another name, make it plural.
The name of the pivot table is ordered alphabetically.
If the pivot table has more than two foreign keys, you use it as a normal table and create a model for it.

One-to-One (Polymorphic):
posts
id - integer
name - string

users
id - integer
name - string

images
id - integer
url - string
imageable_id - integer
imageable_type - string

In the Image model

public function imageable(): MorphTo
{
     return $this->morphTo();
}

In the User model:

public function image(): MorphOne
{
    return $this->morphOne(Image::class, 'imageable');
}

In the Post model:

public function image(): MorphOne
{
    return $this->morphOne(Image::class, 'imageable');
}

One-to-Many (Polymorphic):
posts
id - integer
title - string
body - text

videos
id - integer
title - string
url - string

comments
id - integer
body - text
commentable_id - integer
commentable_type - string

In the Comment model:

public function commentable(): MorphTo
{
      return $this->morphTo();
}

In the Video model:

public function comments(): MorphOne
{
     return $this->morphMany(Comment::class, 'commentable');
}

In the Post model:

public function comments(): MorphOne
{
    return $this->morphMany(Comment::class, 'commentable');
}

Many-to-Many (Polymorphic):
posts
id - integer
name - string

videos
id - integer
name - string

tags
id - integer
name - string

taggables
tag_id - integer
taggable_id - integer
taggable_type - string

In the Tag model:

public function videos(): MorphToMany
{
      return $this->morphedByMany(Video::class, 'taggable');
}

public function posts(): MorphToMany
{
     return $this->morphedByMany(Post::class, 'taggable');
}

In the Video model:

public function tags(): MorphToMany
{
     return $this->morphToMany(Tag::class, 'taggable');
}

In the Post model:

public function tags(): MorphToMany
{
     return $this->morphToMany(Tag::class, 'taggable');
}

Has One Through Relationship:
The "has-one-through" relationship defines a one-to-one relationship with another model.
mechanics
id - integer
name - string

cars
id - integer
model - string
mechanic_id - integer

owners
id - integer
name - string
car_id - integer

In the Mechanic Model:

public function carOwner(): HasOneThrough
{
   return $this->hasOneThrough(Owner::class, Car::class);
}

Has Many Through Relationship:
The "has-many-through" relationship defines a many-to-many relationship with another model.
projects
id - integer
name - string

environments
id - integer
project_id - integer
name - string

deployments
id - integer
environment_id - integer
commit_hash - string

In the Project Model:

public function deployments(): HasManyThrough
{
    return $this->hasManyThrough(Deployment::class, Environment::class);
}

Choosing between Eloquent ORM and Query Builder:

Use Eloquent when you:

Want readable, expressive, object-oriented code.
Are working with relationships (hasMany, belongsTo, etc.).
Want to take advantage of features like accessors/mutators, events, casts, etc.
Don’t need extreme query performance.

Use Query Builder when:

You need complex joins, groupings, aggregates.
You care more about raw performance.
You don’t need to manipulate model objects (e.g., User model).
You’re building reports, analytics, or API endpoints returning raw JSON.
You still get Laravel’s database abstraction and security (no SQL injection risk).

OOP Object-Oriented Programming

Mohamed Fakhr — Tue, 11 Aug 2026 18:35:31 +0000

Advantages of using OOP:

Is faster and easier to execute.
Provides a clear structure for the programs.
Helps to keep code DRY "Don't Repeat Yourself" and makes code easier to maintain, modify, and debug.
Makes it possible to create fully reusable applications with less code and shorter development time.

Define a Class:
A class is defined by using the class keyword, followed by the name of the class and a pair of curly braces {}. All its properties and methods go inside the braces.

Delegation:
Delegation means that you use an object of another class as an instance variable.
We can create multiple objects from a class. Each object has all the variables and functions defined in the class. An object of a class is made using the new keyword.

Note:
The $this keyword refers to the current class and is only available inside methods.

__construct() function:
Automatically runs at the beginning of the class.

__destruct() function:
Automatically runs at the end of the class.

Encapsulation:
The wrapping up of data and methods is a protection mechanism for the variables and functions inside the class.

Access Modifier:
Public: Variables or functions can be accessed from everywhere.

Private: Variables or functions can ONLY be accessed inside the class.

Protected: Variables or functions can be accessed inside the class and by child classes that extend from the parent class.

Constants:

It can’t be changed once it is declared.
Declared inside a class with the const keyword.
It is recommended to name the constants in all uppercase letters.
Access outside the class by using the class name followed by the scope resolution operator ::.
Access a constant inside the class by using the self keyword.

Static Functions and Variables:

Static functions or variables can be called directly - without creating an instance of the class first.
Static functions or variables are declared with the static keyword.
To access a static function or variable, use the class name, double colon ::, and the function name.
A static function can be accessed from a function in the same class using the self keyword and double colon ::.
To call a static method from a child class, use the parent keyword inside the child class.
The static method can be public or protected.

Note:
The final keyword can be used to prevent class inheritance or to prevent method overriding.

Polymorphism:
is one of the OOP features that allows us to perform a single action in different ways.
Like declaring a function in the parent class and giving the function a different implementation in the children's classes.

Abstract:

Can have both abstract methods (without body) and regular methods (with implementation).
Can have properties (variables).
A class can extended single abstract (single inheritance).
Cannot be instantiated directly — only extended (inherited) by other classes.
Used when classes share some common behavior, but also need to implement some parts individually.

Interface:

Can only contain method declarations (no implementation).
No properties — only method signatures.
A class can implement multiple interfaces (multiple inheritance).
Forces the class to implement all methods defined in the interface.

Traits
PHP only supports single inheritance: a child class can inherit from only one parent.
So, what if a class needs to inherit multiple behaviors?
OOP traits solve this problem.

Traits are used to declare functions that can be used in multiple classes. Traits can have functions and abstract functions that can be used in multiple classes, and the functions can have any access modifier (public, private, or protected).
Traits are declared with the trait keyword.
To use a trait in a class, use the use keyword.

Difference between Traits and Interfaces in PHP
many classes implement the same interface but have different behavior, while traits are just chunks of code injected into a class in PHP.

SOLID Principles

Mohamed Fakhr — Wed, 29 Jul 2026 18:29:36 +0000

S for Single Responsibility
Mistake:
Fat Controllers and Models
Developers often cram too much logic into controllers and models, making them hard to maintain and test.
Solution:
Suggests that a class should have only one reason to change, meaning each class should only have one responsibility.
O for Open–Closed
Mistake:
Modifying existing code to add new functionality
Developers sometimes directly modify existing classes to add new features, which can introduce bugs and make the code harder to maintain.
Solution:
States that software entities should be open for extension but closed for modification.
L for Liskov Substitution
Mistake:
Subclasses that do not adhere to the contract of their base classes
Developers may create subclasses that override base-class methods in ways that change their expected behavior, leading to bugs.
Solution:
States that subclasses should be substitutable for their base classes without altering the correctness of the program. Ensure that subclasses override methods in a manner consistent with the base class.
Example:
Violation of LS

class Bird
{
    public function fly()
    {
        // Fly logic
    }
}

class Penguin extends Bird
{
    public function fly()
    {
        throw new Exception("Penguins can't fly");
    }
}

Adhering to LS

interface Bird
{
    public function move();
}

class FlyingBird implements Bird
{
    public function move()
    {
        // Fly logic
    }
}

class Penguin implements Bird
{
    public function move()
    {
        // Swim logic
    }
}

I for Interface Segregation
Mistake:
Implementing large interfaces
Developers sometimes create large interfaces with methods that implementing classes don't need, leading to unused code.
Solution:
Suggests that clients should not be forced to depend on interfaces they do not use. Create smaller, more specific interfaces.
D for Dependency Inversion
Mistake:
High-level modules depending on low-level modules
Developers often make high-level classes depend directly on low-level classes, which makes the code rigid and hard to change.
Solution:
States that high-level modules should not depend on low-level modules, but both should depend on abstractions. Use dependency injection to adhere to DIP.

Service Container

Mohamed Fakhr — Tue, 28 Jul 2026 12:02:32 +0000

The Service Container is one of Laravel's core features. It is Laravel's implementation of the Dependency Injection (DI) and Inversion of Control (IoC) patterns.
It's also Laravel's way of managing dependencies and injecting them automatically.
Instead of creating dependencies manually with the new keyword, you let the container resolve and inject them for you.

How Laravel Uses the Service Container

Most Service Container bindings are registered inside Service Providers using the register() method.
Within a service provider, you have access to the container through the $this->app property.

class AppServiceProvider extends ServiceProvider
{
     public function register(): void
     {
        //
     }
}

Use the bind() method to tell Laravel how to create an object. Every time the dependency is resolved, Laravel creates a new instance.

Exaple
Whenever someone requests LoggerInterface, Laravel should create and return a new FileLogger instance.

$this->app->bind(LoggerInterface::class, function () {
    return new FileLogger();
});

Use singleton() when you want Laravel to create only one instance and reuse it throughout the application's lifetime.

Exaple
The first time CacheService is requested, Laravel creates the object.
Every subsequent request returns the same instance instead of creating a new one.

$this->app->singleton(CacheService::class, function () {
    return new CacheService();
});

$one = app(CacheService::class);
$two = app(CacheService::class);
var_dump($one === $two); // true

bind() vs singleton()
bind(): Creates a new instance every time the dependency is resolved.
singleton(): Creates one instance and reuses it for all future resolutions.

Note:

You will typically be interacting with the container within service providers; however, if you would like to interact with the container outside of a service provider, you may do so via the App facade
There is no need to bind classes into the container if they do not depend on any interfaces. The container does not need to be instructed on how to build these objects, since it can automatically resolve these objects using reflection.

Exaple
If your class has no constructor parameters (or only concrete classes, not interfaces), Laravel will automatically create it — you don’t have to register it.

class HelloService {
    public function sayHello() {
        return 'Hello!';
    }
}
$service = app(HelloService::class);

Compiled and Interpreted Languages

Mohamed Fakhr — Wed, 22 Jul 2026 11:23:54 +0000

The key difference lies in how the code is executed:

Compiled Languages:
The source code is translated into machine code by a compiler.it's a sequence of instructions the computer's CPU can directly understand. This process happens before the program is executed. The resulting machine code is then executed directly by the CPU.
Translation: Translated into machine code before execution
Execution: Generally faster
Debugging: Can be more difficult as errors may not be immediately apparent.
Examples: C, C++, Java, Go

Interpreted Languages:
The source code is executed line by line by an interpreter. The interpreter reads each line, translates it into machine code, and then executes it immediately.
Translation: Translated and executed line by line
Execution: Generally slower
Examples: Python, JavaScript, PHP, Ruby

PHP: PHP is primarily an interpreted language.
However, some PHP engines (like the popular PHP-FPM) use techniques like "just-in-time" (JIT) compilation to improve performance. JIT compilers translate parts of the PHP code into machine code during execution, which can significantly speed up performance.

In essence:

Compiled languages prioritize performance and efficiency, while interpreted languages prioritize ease of development and portability.
The choice between a compiled and interpreted language depends on the specific needs of the project.

Stateful vs Stateless Authentication

Mohamed Fakhr — Mon, 20 Jul 2026 12:38:38 +0000

Stateful Authentication
Session-based: Relies on server-side sessions to maintain user state.
How it works: When a user logs in, a session is created on the server, and a session ID is stored in a cookie on the client. Subsequent requests include the session ID, allowing the server to identify the user.
Advantages: Simple to implement, good for traditional web applications.
Disadvantages: Scalability issues with large user bases, vulnerability to session hijacking, and state management complexity.

Stateless Authentication
Token-based: Relies on tokens (usually JWTs) instead of sessions.
How it works: After successful authentication, a JWT containing user information is issued. Subsequent requests include the token in the authorization header. The server validates the token without maintaining user state.
Advantages: Scalability, security, and flexibility.
Disadvantages: Increased complexity in token management and potential for larger payloads.

When to Use Which
Stateful Authentication: Suitable for traditional web applications where user experience is prioritized and scalability is not a major concern.

Stateless Authentication: Ideal for APIs, mobile applications, and single-page applications (SPAs) where scalability, security, and statelessness are essential.

Laravel Request Lifecycle

Mohamed Fakhr — Sun, 19 Jul 2026 16:59:03 +0000

1. Request Entry Point

The request begins at public/index.php. This file is the entry point for all incoming requests by your web server (Apache / Nginx) configuration.
It loads the Composer autoloader and instantiates the Laravel application from bootstrap/app.php.

2. Kernel Initialization
This kernel is responsible for handling HTTP requests and managing middleware. The request is sent to either the HTTP kernel or the console kernel, depending on the type of request. Kernels serve as the central location where all requests flow. Just focus on the HTTP kernel, which is located in app/Http/Kernel.php.

The Illuminate\Foundation\Http\Kernel class is instantiated, which defines "an array of bootstrappers", which refers to a list of classes that will be run before the request is executed. These bootstrappers configure

Error handling
Logging
Authentication & Authorization
Detect the application environment

Also defines a list of HTTP middleware that all requests must pass through before being handled by the application. This middleware handles

Reading and writing the HTTP session
Verifying the cross-site request forgery (CSRF) token.

Call the handle method in all middlewares, then after the response, call the terminate method, which runs after the request

3. Service Providers

One of the most important kernel bootstrapping actions is loading the service providers for your application.
Service providers are responsible for bootstrapping all of the framework's various components, such as the database, queue, validation, and routing components.
Service Providers are listed in config/app.php. This is the master list or array of all the service providers Laravel will load for your application.
Laravel loops through them. When Laravel starts up (bootstraps), it goes through each provider in that list and creates (instantiates) an object of each service provider class.
register() is called first on all providers. Purpose of register(): You tell Laravel’s service container how to build certain classes, bind interfaces, or configure services.
After all providers are registered, Laravel then calls the boot() method on each one.

-Why does Laravel call the boot() method after register() in a service provider?
Because by the time boot() runs, all other service providers have been registered, you can safely use the services that those providers have registered.

-Why are Service Providers so important?
Essentially, every major feature offered by Laravel is bootstrapped and configured by a service provider. Everything in Laravel — routing, queues, events, mail, validation, etc. — is set up by these providers. When you install a package (like Cashier, Horizon, etc.), you often add its service provider to config/app.php so Laravel knows how to register and boot it.

4. Route Matching

One of the most important service providers in your application is the App\Providers\RouteServiceProvider. This service provider loads the route files contained within your application's routes directory.
Once the application has been bootstrapped and all service providers have been registered, the Request will be handed off to the router, which will dispatch the request to a route or controller.

5. Controller Invocation

Once a matching route is found, the associated controller method is executed.
The controller handles the request logic, interacts with models, and prepares the response.
The controller returns a response, which can be a view, JSON, or other formats.
Laravel converts the response into an HTTP response object.

7. Middleware Termination
The request passes through the middleware again, allowing for any final actions (e.g., logging, error handling).

8. Response Sending
The HTTP kernel's handle method returns the response object, and the index.php file calls the send method on the returned response. The send method sends the response content to the user's web browser.

Laravel Autoloader

Mohamed Fakhr — Sat, 18 Jul 2026 19:00:27 +0000

What is an Autoloader?
An autoloader is a piece of code that automatically loads classes when they are needed, without requiring explicit include or require statements. This saves developers from manually managing file inclusion and improves code organization.

How it works:
Composer Installation: When you create a new Laravel project, Composer installs the required packages and generates the autoloader file. Composer also is a package management system as npm for nodejs.
Autoloader Activation: Laravel's autoloader is triggered. It examines the class name and tries to locate the corresponding file. If the file is found, it's included, making the class available for use.

The Concept Behind Laravel's Autoloader
(PSR-4) Autoloading Standard: PHP Standard Recommendation for autoloading. This standard defines a mapping between class names and file paths.
Namespace Mapping: Laravel uses namespaces to organize classes. The autoloader maps namespaces to specific directories within your project structure.
Classmap Generation: Composer creates a classmap, which is a lookup table that maps class names to their file paths, optimizing performance.

What is composer.lock?
The composer.lock file is auto-generated by Composer.
Purpose:
It locks exact versions of every package (and their dependencies).
Ensures the project runs the same way for every developer or deployment.
Keeps installs consistent across environments.

That's why some developers don't commit and push composer.lock file so every package is installed with dependence on every developer environment.