DEV Community: Vincent Tommi

Laravel for Django Developers: A Practical Guide to Laravel Architecture

Vincent Tommi — Fri, 04 Sep 2026 12:49:59 +0000

If you've spent some time building applications with Django and have decided to explore Laravel, you may initially feel like you're learning backend development all over again.

You're not.

The syntax is different. The project structure is different. The terminology is different. But many of the architectural ideas behind Laravel will feel surprisingly familiar if you've worked with Django.

This article is a practical guide for Django developers transitioning to Laravel. Instead of learning Laravel concepts in isolation, we'll map them to their Django equivalents and build a mental model of how a Laravel application works.

By the end, you should be able to look at a Laravel project and understand where routes, controllers, models, validation, authentication, business logic, and database operations belong.

1. Django vs Laravel: The Mental Translation

The easiest way to start learning Laravel as a Django developer is to create a mental translation table.

Django	Laravel
Django project	Laravel application
Django app	No exact equivalent
`urls.py`	`routes/web.php`, `routes/api.php`
View function / Class-Based View	Controller method
Django ORM	Eloquent ORM
Model	Model
`models.py`	`app/Models/`
DRF Serializer	API Resource / Form Request
Django Forms	Form Requests
Middleware	Middleware
`settings.py`	`.env` + `config/`
`manage.py`	`artisan`
Django migrations	Laravel migrations
Django templates	Blade
`JsonResponse` / DRF Response	`response()->json()`
Django signals	Events / Observers
Management commands	Artisan commands
`pip`	Composer
`requirements.txt`	`composer.json`
Celery	Laravel Queues / Jobs

The important thing is not to assume that these are exact one-to-one replacements.

They aren't.

They are simply useful mental bridges.

For example, a Laravel API Resource and a Django REST Framework Serializer both help shape API responses, but they work differently.

2. The Laravel Request Lifecycle

Before learning individual Laravel components, understand what happens when a request reaches your application.

Imagine a React frontend sends:

POST /api/properties

A simplified Laravel request lifecycle looks like this:

React / Browser / Mobile App
            |
            v
       HTTP Request
            |
            v
      public/index.php
            |
            v
        Bootstrap
            |
            v
        Middleware
            |
            v
          Router
            |
            v
        Controller
            |
       +----+----+
       |         |
       v         v
   Validation  Business Logic
                 |
                 v
              Model
                 |
                 v
             Database
                 |
                 v
              Resource
                 |
                 v
           JSON Response
                 |
                 v
               Client

This is the architecture you should keep in your head while learning Laravel.

3. Laravel Project Structure

A fresh Laravel project looks roughly like this:

my-project/
│
├── app/
│   ├── Console/
│   ├── Exceptions/
│   ├── Http/
│   │   ├── Controllers/
│   │   ├── Middleware/
│   │   └── Requests/
│   │
│   ├── Models/
│   └── Providers/
│
├── bootstrap/
│
├── config/
│
├── database/
│   ├── factories/
│   ├── migrations/
│   └── seeders/
│
├── public/
│   └── index.php
│
├── resources/
│   ├── views/
│   ├── css/
│   └── js/
│
├── routes/
│   ├── web.php
│   ├── api.php
│   └── console.php
│
├── storage/
│
├── tests/
│
├── vendor/
│
├── .env
├── artisan
└── composer.json

If you're coming from Django, this structure might initially feel strange.

Django encourages you to break functionality into applications:

project/
├── users/
├── properties/
├── bookings/
└── payments/

Laravel doesn't enforce that approach.

Instead, a typical Laravel application organizes code around responsibilities:

app/
├── Models/
├── Http/
│   ├── Controllers/
│   ├── Requests/
│   └── Middleware/
└── Services/

You can still organize a large Laravel project by domain or feature, but Laravel itself doesn't force you to create an "app" for every feature.

4. Routes: Django's `urls.py` vs Laravel Routes

If you've used Django, routing is easy to understand.

In Django you might have:

path(
    "properties/",
    views.properties
)

Laravel uses:

Route::get(
    '/properties',
    [PropertyController::class, 'index']
);

Laravel routes are commonly placed in:

routes/
├── web.php
├── api.php
└── console.php

For example:

Route::get('/properties', [
    PropertyController::class,
    'index'
]);

POST:

Route::post('/properties', [
    PropertyController::class,
    'store'
]);

PUT:

Route::put('/properties/{id}', [
    PropertyController::class,
    'update'
]);

DELETE:

Route::delete('/properties/{id}', [
    PropertyController::class,
    'destroy'
]);

Laravel makes the HTTP method explicit in the route definition.

5. Route Parameters

In Django you might write:

path(
    "properties/<int:id>/",
    views.property_detail
)

Laravel:

Route::get(
    '/properties/{id}',
    [PropertyController::class, 'show']
);

Then your controller can receive the ID:

public function show($id)
{
    //
}

A request such as:

GET /properties/10

gives:

$id = 10;

Laravel also supports a more powerful feature called route model binding, which we'll get to later.

6. Controllers: Django Views vs Laravel Controllers

This is one of the easiest concepts to transfer.

A Django function-based view might look like:

def properties(request):
    properties = Property.objects.all()

    return JsonResponse({
        "properties": list(
            properties.values()
        )
    })

A Laravel controller could look like:

class PropertyController extends Controller
{
    public function index()
    {
        $properties = Property::all();

        return response()->json([
            'properties' => $properties
        ]);
    }
}

Conceptually:

Django View
     ≈
Laravel Controller Method

Create a controller with Artisan:

php artisan make:controller PropertyController

Laravel creates:

app/Http/Controllers/PropertyController.php

7. Models and Eloquent

If there is one Laravel feature Django developers will understand almost immediately, it's Eloquent.

Eloquent is Laravel's ORM.

Django:

Property.objects.all()

Laravel:

Property::all();

Django:

Property.objects.get(id=1)

Laravel:

Property::find(1);

Django:

Property.objects.filter(
    status="available"
)

Laravel:

Property::where(
    'status',
    'available'
)->get();

Django:

Property.objects.filter(
    price__gt=10000
)

Laravel:

Property::where(
    'price',
    '>',
    10000
)->get();

The syntax is different, but the underlying idea is the same:

Application
     |
     v
ORM
     |
     v
Database

8. Creating Models

Create a Laravel model:

php artisan make:model Property

You will get something like:

app/Models/Property.php

A model might look like:

class Property extends Model
{
    protected $fillable = [
        'name',
        'location',
        'price',
    ];
}

You can then create records:

$property = Property::create([
    'name' => 'Apartment A',
    'location' => 'Nairobi',
    'price' => 25000,
]);

The Django equivalent is:

Property.objects.create(
    name="Apartment A",
    location="Nairobi",
    price=25000
)

9. Mass Assignment

One Laravel concept that might initially confuse Django developers is mass assignment.

You'll frequently see:

protected $fillable = [
    'name',
    'location',
    'price',
];

This controls which attributes can be assigned through methods such as:

Property::create([
    'name' => 'Apartment A',
    'location' => 'Nairobi',
    'price' => 25000,
]);

It's an important security mechanism.

You should understand $fillable and $guarded early when learning Eloquent.

10. Migrations

If you've worked with Django migrations, Laravel migrations will feel familiar.

Django:

python manage.py makemigrations
python manage.py migrate

Laravel:

php artisan make:migration create_properties_table

Then:

php artisan migrate

A migration might look like:

Schema::create('properties', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('location');
    $table->decimal('price', 10, 2);
    $table->timestamps();
});

Compare that with Django:

class Property(models.Model):
    name = models.CharField(max_length=255)
    location = models.CharField(max_length=255)
    price = models.DecimalField(
        max_digits=10,
        decimal_places=2
    )

The syntax is different, but you're expressing the same database structure.

11. Artisan: Laravel's `manage.py`

If Django has:

python manage.py

Laravel has:

php artisan

Artisan is one of the most important tools in the Laravel ecosystem.

Some commands you'll use frequently:

php artisan serve

Start the development server.

php artisan route:list

Display your application's routes.

php artisan make:model Property

Create a model.

php artisan make:controller PropertyController

Create a controller.

php artisan make:request StorePropertyRequest

Create a validation request.

php artisan make:resource PropertyResource

Create an API Resource.

php artisan migrate

Run migrations.

php artisan migrate:rollback

Roll back migrations.

php artisan migrate:fresh

Drop all tables and rebuild the database.

php artisan db:seed

Run seeders.

php artisan optimize:clear

Clear Laravel's cached configuration, routes, views, and other optimized files.

A good rule:

If you're wondering whether Laravel has a CLI command for something, check Artisan first.

12. Relationships

Laravel's Eloquent relationships are another area where Django developers should feel at home.

Suppose a property belongs to a landlord.

Django:

class Property(models.Model):
    landlord = models.ForeignKey(
        User,
        on_delete=models.CASCADE
    )

Laravel:

class Property extends Model
{
    public function landlord()
    {
        return $this->belongsTo(
            User::class
        );
    }
}

Now you can access:

$property->landlord;

13. One-to-Many Relationships

Suppose a landlord owns multiple properties.

Laravel:

class Landlord extends Model
{
    public function properties()
    {
        return $this->hasMany(
            Property::class
        );
    }
}

Then:

$landlord->properties;

Django might be:

landlord.properties.all()

assuming you configured the appropriate related_name.

14. Many-to-Many Relationships

Django:

class Student(models.Model):
    courses = models.ManyToManyField(
        Course
    )

Laravel:

public function courses()
{
    return $this->belongsToMany(
        Course::class
    );
}

Then:

$student->courses;

Again, the terminology changes but the database relationship remains the same.

15. Eager Loading

One of the most important ORM concepts is avoiding unnecessary database queries.

Laravel:

Property::with('landlord')->get();

Django's rough equivalent:

Property.objects.select_related(
    "landlord"
)

For collection relationships:

Property::with('bookings')->get();

is conceptually similar to:

Property.objects.prefetch_related(
    "bookings"
)

This is important because both Django and Laravel applications can suffer from the infamous N+1 query problem.

16. Validation: DRF Serializers vs Laravel Form Requests

This is where the architecture starts becoming noticeably different.

In Django REST Framework, you might put validation inside a serializer:

class PropertySerializer(
    serializers.ModelSerializer
):
    class Meta:
        model = Property
        fields = "__all__"

    def validate_price(self, value):
        if value < 0:
            raise serializers.ValidationError(
                "Price cannot be negative"
            )

        return value

Laravel commonly separates request validation into a Form Request.

Create one:

php artisan make:request StorePropertyRequest

Then:

class StorePropertyRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => [
                'required',
                'string',
                'max:255'
            ],

            'location' => [
                'required',
                'string'
            ],

            'price' => [
                'required',
                'numeric',
                'min:0'
            ],
        ];
    }
}

Then inject it into your controller:

public function store(
    StorePropertyRequest $request
) {
    //
}

Laravel automatically validates the incoming request before your controller method proceeds.

17. API Resources: Think DRF Serializer Output

Laravel has API Resources for transforming models into API responses.

Create one:

php artisan make:resource PropertyResource

Then:

class PropertyResource extends JsonResource
{
    public function toArray(
        Request $request
    ): array {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'location' => $this->location,
            'price' => $this->price,
        ];
    }
}

Then:

return new PropertyResource($property);

For collections:

return PropertyResource::collection(
    Property::all()
);

A useful mental model is:

DRF Serializer
       |
       +---- validation/input
       |
       +---- representation/output

Laravel
       |
       +---- Form Request
       |       -> validation
       |
       +---- API Resource
               -> representation

Laravel separates these responsibilities more explicitly.

18. Middleware

Django developers already understand middleware.

Django:

MIDDLEWARE = [
    ...
]

Laravel:

Route::middleware('auth')->group(
    function () {
        // protected routes
    }
);

You can create middleware using Artisan:

php artisan make:middleware CheckUserRole

For example:

if ($request->user()->role !== 'admin') {
    abort(403);
}

Middleware is useful for concerns that should happen before or after controller execution, such as:

Authentication
Logging
Rate limiting
CORS
Role checks
Request modification

19. Authentication and Authorization

Laravel supports several authentication approaches.

One commonly encountered solution for API and SPA applications is Laravel Sanctum.

A typical architecture might look like:

React
  |
  v
Laravel API
  |
  v
Authentication
  |
  v
Controller

If you're coming from Django REST Framework and JWT, don't assume Sanctum is simply "Laravel's JWT."

Sanctum provides API token authentication and SPA authentication capabilities, but its model and workflow differ from JWT-based authentication.

Laravel also provides:

Gates
Policies
Middleware
Authentication guards

These become especially important as your application grows.

20. Policies and Gates

Suppose a landlord should only be allowed to update their own property.

You could check this directly inside a controller, but Laravel provides authorization mechanisms such as Policies.

Conceptually:

User
  |
  v
Can this user update this property?
  |
  +---- YES ---> Continue
  |
  +---- NO ----> 403 Forbidden

This keeps authorization logic separate from your business logic.

If you've used Django permissions, this is an area you'll want to explore carefully.

21. Environment Variables and Configuration

Laravel uses a .env file for environment-specific configuration.

For example:

APP_NAME=Laravel
APP_ENV=local
APP_DEBUG=true

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=my_database
DB_USERNAME=root
DB_PASSWORD=

Django developers may recognize this approach from using packages such as python-decouple or django-environ.

Laravel configuration is stored under:

config/

For example:

config/
├── app.php
├── database.php
├── auth.php
├── cache.php
└── filesystems.php

Django developers can think of this as a more distributed equivalent of settings.py.

22. Blade Templates

Laravel's server-side templating engine is called Blade.

Django:

<h1>{{ property.name }}</h1>

Blade:

<h1>{{ $property->name }}</h1>

Django:

{% for property in properties %}
    {{ property.name }}
{% endfor %}

Blade:

@foreach($properties as $property)
    {{ $property->name }}
@endforeach

If you're building a Laravel API consumed by React, you may use Blade very little.

If you're building a traditional Laravel web application, Blade becomes much more important.

23. Dependency Injection and the Service Container

This is one of the Laravel concepts I recommend Django developers spend extra time understanding.

Suppose your controller depends on a service:

class PropertyController extends Controller
{
    public function __construct(
        PropertyService $propertyService
    ) {
        $this->propertyService =
            $propertyService;
    }
}

Laravel's Service Container can resolve that dependency for you.

Conceptually:

Controller
    |
    | requires
    v
PropertyService
    |
    v
Laravel Service Container

This is Laravel's dependency injection system.

Once you understand the Service Container, concepts such as service providers, bindings, interfaces, and dependency injection become much easier.

24. Services and Business Logic

Laravel applications often introduce service classes for complex business logic.

For example:

app/
└── Services/
    ├── PropertyService.php
    ├── BookingService.php
    └── PaymentService.php

A service might contain:

class PropertyService
{
    public function create(
        array $data
    ) {
        return Property::create($data);
    }
}

Then your controller becomes:

public function store(
    StorePropertyRequest $request
) {
    $property =
        $this->propertyService->create(
            $request->validated()
        );

    return new PropertyResource(
        $property
    );
}

The idea is to prevent controllers from becoming massive.

Instead of:

Controller
 ├── validation
 ├── authorization
 ├── payment
 ├── database logic
 ├── email
 ├── notifications
 └── business rules

you can have:

Controller
     |
     v
Service
     |
     +---- Model
     +---- Payment
     +---- Notification
     +---- Events

Don't create a service class for every two-line database query, though.

Use this architecture when it actually improves separation of responsibilities.

25. Events and Listeners

Laravel has an event-driven architecture available through Events and Listeners.

Imagine a user registers:

User registers
      |
      v
UserRegistered event
      |
      +----> SendWelcomeEmail
      |
      +----> CreateProfile
      |
      +----> NotifyAdmin

This keeps secondary operations out of the main request logic.

Django developers may find this somewhat similar to using signals, although Laravel Events and Listeners provide a different and often more explicit architecture.

26. Jobs and Queues

If you've used Celery with Django, Laravel's Jobs and Queues should make sense.

Suppose sending 10,000 emails would make a request slow.

Instead:

HTTP Request
     |
     v
Create Job
     |
     v
Queue
     |
     v
Worker
     |
     v
Send Emails

Create a job:

php artisan make:job SendNewsletter

Then dispatch it:

SendNewsletter::dispatch();

The user doesn't necessarily have to wait for the expensive operation to finish.

This is extremely useful for:

Emails
Notifications
Image processing
Reports
Payments
Imports
Exports
Heavy calculations

27. Scheduling

Laravel also includes a task scheduling system.

You might have a task that needs to run regularly:

Every day
    |
    v
Find overdue rent
    |
    v
Send reminders

Or:

Every hour
    |
    v
Clean expired sessions

This functionality can be combined with Artisan commands and queued jobs.

If you're coming from Django, think of this as part of the territory often handled by cron, Celery Beat, management commands, or similar tools.

28. Seeders and Factories

Laravel provides database seeders:

php artisan db:seed

For example:

Property::create([
    'name' => 'Apartment A',
    'location' => 'Nairobi',
    'price' => 25000,
]);

Factories allow you to generate test/development data.

For example:

Property::factory()
    ->count(50)
    ->create();

This is conceptually similar to using tools such as factory_boy in Django projects.

29. A Complete Laravel API Example

Let's put the pieces together.

Suppose we're creating:

POST /api/properties

The route:

Route::post(
    '/properties',
    [PropertyController::class, 'store']
);

The request validation:

class StorePropertyRequest
    extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => [
                'required',
                'string',
                'max:255'
            ],

            'location' => [
                'required',
                'string'
            ],

            'price' => [
                'required',
                'numeric',
                'min:0'
            ],
        ];
    }
}

The model:

class Property extends Model
{
    protected $fillable = [
        'name',
        'location',
        'price',
    ];
}

The controller:

class PropertyController extends Controller
{
    public function store(
        StorePropertyRequest $request
    ) {
        $property = Property::create(
            $request->validated()
        );

        return new PropertyResource(
            $property
        );
    }
}

The resource:

class PropertyResource extends JsonResource
{
    public function toArray(
        Request $request
    ): array {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'location' => $this->location,
            'price' => $this->price,
        ];
    }
}

The client sends:

POST /api/properties
Content-Type: application/json

{
    "name": "Apartment A",
    "location": "Nairobi",
    "price": 25000
}

Laravel processes it:

POST /api/properties
        |
        v
Route
        |
        v
PropertyController
        |
        v
StorePropertyRequest
        |
        v
validated()
        |
        v
Property::create()
        |
        v
Eloquent
        |
        v
MySQL
        |
        v
PropertyResource
        |
        v
JSON Response

That's a real Laravel API architecture.

30. Translating a Django Project to Laravel

Let's say you've already built a landlord/tenant system in Django.

Your Django architecture might look like:

Django
│
├── users
├── properties
├── bookings
├── payments
└── maintenance

The Laravel equivalent could look like:

Laravel
│
├── Models
│   ├── User.php
│   ├── Property.php
│   ├── Booking.php
│   ├── RentPayment.php
│   └── MaintenanceTicket.php
│
├── Http
│   ├── Controllers
│   │   ├── AuthController.php
│   │   ├── PropertyController.php
│   │   ├── BookingController.php
│   │   └── PaymentController.php
│   │
│   ├── Requests
│   │   ├── LoginRequest.php
│   │   ├── StorePropertyRequest.php
│   │   └── StoreBookingRequest.php
│   │
│   └── Resources
│       ├── UserResource.php
│       ├── PropertyResource.php
│       └── BookingResource.php
│
└── Services
    ├── AuthService.php
    ├── PropertyService.php
    └── PaymentService.php

Then your API flow becomes:

React
  |
  | POST /api/properties
  v
Laravel Router
  |
  v
PropertyController
  |
  v
StorePropertyRequest
  |
  v
Authorization
  |
  v
PropertyService
  |
  v
Property Model
  |
  v
MySQL
  |
  v
PropertyResource
  |
  v
JSON
  |
  v
React

This is a very useful architecture for someone already comfortable with Django REST Framework.

31. What You Should NOT Do as a Django Developer

One of the biggest mistakes when moving frameworks is trying to force your old framework's architecture into the new framework.

Don't assume:

Laravel = Django written in PHP

It isn't.

For example, don't automatically create:

PropertySerializer
PropertyView
PropertyForm
PropertyService

just because that's how you might structure something in Django.

Instead, understand what Laravel provides and use each component where it makes sense.

Likewise, don't put everything inside controllers simply because Laravel makes it easy.

A controller containing 500 lines of business logic isn't good Laravel architecture.

32. The Laravel Architecture to Learn

I'd recommend learning Laravel in roughly this order.

Level 1 — Foundation

Learn:

PHP
  ↓
Composer
  ↓
Laravel installation
  ↓
Project structure
  ↓
Artisan
  ↓
Routes
  ↓
Controllers

Level 2 — Database

Then:

Migrations
  ↓
Models
  ↓
Eloquent
  ↓
Relationships
  ↓
Query Builder
  ↓
Factories
  ↓
Seeders

Level 3 — API Development

Then:

HTTP Requests
  ↓
Validation
  ↓
Form Requests
  ↓
API Resources
  ↓
Pagination
  ↓
JSON responses

Level 4 — Security

Then:

Authentication
  ↓
Middleware
  ↓
Policies
  ↓
Gates
  ↓
Authorization
  ↓
Sanctum

Level 5 — Laravel Architecture

Then:

Service Container
  ↓
Dependency Injection
  ↓
Service Providers
  ↓
Services
  ↓
Events
  ↓
Listeners
  ↓
Jobs
  ↓
Queues

Level 6 — Production

Finally:

Caching
  ↓
Queues
  ↓
Scheduling
  ↓
Logging
  ↓
Testing
  ↓
Workers
  ↓
Deployment

33. The Most Important Concepts to Focus On

If you've already read the Django documentation, don't try to learn every Laravel feature immediately.

Focus heavily on these:

1. Eloquent

Understand:

Model::all();

Model::find();

Model::where();

Model::create();

Model::update();

Model::delete();

Then move into relationships and eager loading.

2. Form Requests

Understand how Laravel validates incoming data.

3. API Resources

Understand how Laravel transforms models into API responses.

4. Middleware

Understand where authentication, rate limiting, and request processing happen.

5. Policies and Gates

Understand authorization.

6. Service Container

This is one of Laravel's most important architectural concepts.

7. Dependency Injection

Understand how Laravel resolves dependencies.

8. Jobs and Queues

Especially if you're building production applications.

9. Events and Listeners

Learn how to decouple secondary operations from your main application flow.

10. Artisan

You'll use it constantly.

34. The Mental Model I Recommend

If you're transitioning from Django, remember this:

                       LARAVEL

                         Request
                            |
                            v
                       Middleware
                            |
                            v
                          Route
                            |
                            v
                       Controller
                            |
                 +----------+----------+
                 |                     |
                 v                     v
          Form Request             Policy
          Validation            Authorization
                 |
                 v
               Service
                 |
                 v
              Eloquent
                 |
                 v
              Database
                 |
                 v
              Resource
                 |
                 v
            JSON Response

You don't have to use every box in every request.

A simple endpoint might be:

Request
   ↓
Route
   ↓
Controller
   ↓
Model
   ↓
Response

A more complex endpoint might be:

Request
   ↓
Middleware
   ↓
Route
   ↓
Form Request
   ↓
Policy
   ↓
Controller
   ↓
Service
   ↓
Eloquent
   ↓
Event
   ↓
Job
   ↓
Resource
   ↓
Response

The architecture grows with the complexity of the application.

35. Final Thoughts

Moving from Django to Laravel isn't really starting over.

If you've already built applications with Django, you already understand most of the important backend concepts.

You know:

HTTP
Routing
REST APIs
Models
ORMs
Databases
Relationships
Migrations
Authentication
Authorization
Middleware
Validation
Serialization
Background tasks

Laravel simply implements many of these ideas differently.

The biggest shift is learning Laravel's way of organizing those responsibilities.

Instead of thinking:

"Where is the Laravel version of my Django file?"

start thinking:

"What responsibility am I trying to solve, and which Laravel component is designed for it?"

Once you start thinking that way, Laravel becomes much easier to understand.

And if you've already built a Django REST API, you're not beginning your Laravel journey as a beginner.

You're learning a new ecosystem using knowledge you already have.

The fastest way to make the transition stick is to build something you already understand in Django.

For example:

Landlord/Tenant API
       |
       +-- Authentication
       +-- Users
       +-- Properties
       +-- Bookings
       +-- Rent Payments
       +-- Maintenance Tickets
       +-- Roles
       +-- Authorization
       +-- Notifications

Build the same system in Laravel while consciously mapping:

Django              Laravel

urls.py          →  routes
views.py         →  controllers
models.py        →  Eloquent models
DRF serializers  →  requests/resources
ORM              →  Eloquent
middleware       →  middleware
manage.py        →  Artisan
Celery           →  Jobs/Queues
settings.py      →  config + .env

That's when Laravel stops looking like a completely different framework and starts becoming another way of solving problems you already know how to solve.

Fixing PDO::MYSQL_ATTR_SSL_CA Deprecation Errors in PHP 8.5 and Laravel

Vincent Tommi — Wed, 02 Sep 2026 20:33:59 +0000

If you've recently upgraded to PHP 8.5 and started seeing deprecation warnings in a Laravel application, you may run into an error similar to this:

Deprecated: Constant PDO::MYSQL_ATTR_SSL_CA is deprecated since 8.5,
use Pdo\Mysql::ATTR_SSL_CA instead

In my case, the warning was pointing to:

config/database.php

at line 62.

Here's how I fixed it and what I learned along the way.

The Problem

After upgrading to PHP 8.5, I ran:

php artisan config:clear

Instead of clearing the configuration cache, Laravel returned:

Deprecated: Constant PDO::MYSQL_ATTR_SSL_CA is deprecated since 8.5,
use Pdo\Mysql::ATTR_SSL_CA instead

In database.php line 62:
Undefined constant PDO::mysql_ATTR_SSL_CA

The important part is:

Undefined constant PDO::mysql_ATTR_SSL_CA

This happened because the constant had been changed incorrectly.

The Old Constant

Older PHP versions commonly use:

PDO::MYSQL_ATTR_SSL_CA

PHP 8.5 deprecates this form and recommends the MySQL-specific class instead.

The new form is:

Pdo\Mysql::ATTR_SSL_CA

Notice that PHP class and constant names are case-sensitive.

Incorrect

PDO::mysql_ATTR_SSL_CA

Correct

Pdo\Mysql::ATTR_SSL_CA

The difference is important:

PDO::mysql_ATTR_SSL_CA
^^^  ^^^^^^^^^^^^^^^

Pdo\Mysql::ATTR_SSL_CA
^^^  ^^^^^ ^^^^^^^^^

Fixing `database.php`

Open your Laravel project's database configuration:

config/database.php

Look for:

PDO::MYSQL_ATTR_SSL_CA

Replace it with:

Pdo\Mysql::ATTR_SSL_CA

For example, if you have:

'options' => extension_loaded('pdo_mysql') ? array_filter([
    PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
]) : [],

change it to:

'options' => extension_loaded('pdo_mysql') ? array_filter([
    Pdo\Mysql::ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
]) : [],

What If You Can't Edit the File With Nano?

If you're using Ubuntu and nano isn't working for you, there are several alternatives.

Using VS Code

If VS Code is installed:

code config/database.php

Or use the full path:

code /home/tommi/Desktop/Development/programmer/samupos/config/database.php

Then replace:

PDO::MYSQL_ATTR_SSL_CA

with:

Pdo\Mysql::ATTR_SSL_CA

Using the Terminal

If you only need to replace the constant, you can use sed:

sed -i 's/PDO::mysql_ATTR_SSL_CA/Pdo\\Mysql::ATTR_SSL_CA/g' config/database.php

If you get a permission error, you can use:

sudo sed -i 's/PDO::mysql_ATTR_SSL_CA/Pdo\\Mysql::ATTR_SSL_CA/g' config/database.php

Then verify the change:

grep -n "SSL_CA" config/database.php

You should see:

Pdo\Mysql::ATTR_SSL_CA

Verify That PHP Supports the New Constant

Before trying Laravel again, you can check whether PHP recognizes the new constant:

php -r 'var_dump(Pdo\Mysql::ATTR_SSL_CA);'

If everything is working correctly, PHP should return an integer value.

For example:

int(10023)

The exact integer isn't the important part. What matters is that PHP recognizes the constant without throwing an error.

Clear Laravel's Configuration Cache

Once the constant has been corrected, go back to your Laravel project:

cd /home/tommi/Desktop/Development/programmer/samupos

Then run:

php artisan config:clear

You can also rebuild the configuration cache:

php artisan config:cache

If those commands complete successfully, Laravel should no longer complain about:

PDO::MYSQL_ATTR_SSL_CA

Another PHP 8.5 Warning

During this process, I also encountered another warning:

Deprecated: Using null as an array offset is deprecated, use an empty string instead

It pointed to:

vendor/laravel/framework/src/Illuminate/Log/LogManager.php

This is a different issue from the PDO constant.

It's important not to directly edit files inside vendor/.

The vendor directory contains dependencies installed by Composer, so changes made there can be overwritten the next time you run:

composer install

or:

composer update

Instead, check your Laravel version:

php artisan --version

and your PHP version:

php -v

If you're running an older Laravel version with PHP 8.5, you may need to update Laravel or one of its dependencies to a version that properly supports PHP 8.5.

Don't Mix Ubuntu PPAs Just to Fix This

Another potential problem I encountered while setting up PHP was an Ubuntu repository error involving the Ondřej PHP PPA:

The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu resolute Release'
does not have a Release file.

If you're running a newer Ubuntu release and the PPA doesn't provide packages for that release, don't simply change the distribution name in the repository from something like:

resolute

to:

noble

just to make apt update work.

Mixing packages from different Ubuntu releases can cause dependency problems.

Instead, verify what PHP version and packages your current Ubuntu release provides.

Useful Diagnostic Commands

When troubleshooting PHP and Laravel compatibility issues, these commands are useful:

Check PHP version

php -v

Check Laravel version

php artisan --version

Check whether PDO MySQL is installed

php -m | grep pdo_mysql

Expected output:

pdo_mysql

Check the new PHP 8.5 constant

php -r 'var_dump(Pdo\Mysql::ATTR_SSL_CA);'

Find the SSL constant in Laravel's configuration

grep -n "SSL_CA" config/database.php

Final Fix

The key change is simply:

- PDO::MYSQL_ATTR_SSL_CA
+ Pdo\Mysql::ATTR_SSL_CA

Then clear Laravel's configuration:

php artisan config:clear

and, if necessary:

php artisan config:cache

Conclusion

PHP upgrades can expose deprecated functionality that previously worked without any problems. PHP 8.5 is a good example of this: code using the old PDO::MYSQL_ATTR_SSL_CA constant can start producing deprecation warnings.

The important thing is to distinguish between a deprecation warning, an actual PHP error, and a framework compatibility problem.

For this particular issue, the solution is straightforward:

Pdo\Mysql::ATTR_SSL_CA

instead of:

PDO::MYSQL_ATTR_SSL_CA

And when another warning points into vendor/, resist the temptation to edit the dependency directly. Check your Laravel and package versions first and upgrade them where appropriate.

Hopefully this saves someone else a few minutes when upgrading a Laravel project to PHP 8.5.

Understanding the Laravel `config` Folder: What I'm Learning as a Beginner

Vincent Tommi — Sat, 29 Aug 2026 11:58:51 +0000

I'm currently learning Laravel, and one of the things that caught my attention was the config folder.

Coming from a backend development background, I wanted to understand what all those PHP files were doing instead of simply knowing that they "contain configuration."

When I opened a fresh Laravel project, I found files like:

config/
├── app.php
├── auth.php
├── broadcasting.php
├── cache.php
├── concurrency.php
├── cors.php
├── database.php
├── filesystems.php
├── hashing.php
├── images.php
├── logging.php
├── mail.php
├── queue.php
├── services.php
├── session.php
└── view.php

At first, it looked like a lot to understand.

So I decided to go through them one by one and document what I'm learning. Hopefully, this can also help someone else who is starting with Laravel.

Note: The exact configuration files can vary depending on your Laravel version and the packages installed in your application.

What is the `config` folder?

The config directory contains PHP configuration files that control different parts of your Laravel application.

You can think of it as the place where Laravel learns things like:

How to connect to a database
How authentication works
How files are stored
How emails are sent
How caching works
How sessions work
How queues work
How logging works
How external services are configured

The structure looks roughly like:

Laravel Application
        |
        ↓
     config/
        |
   ┌────┼────┬────┬────┐
   ↓    ↓    ↓    ↓    ↓
  DB   Auth  Mail Cache Logging

1. `app.php`

app.php contains general configuration for your Laravel application.

For example:

return [
    'name' => env('APP_NAME', 'Laravel'),

    'env' => env('APP_ENV', 'production'),

    'debug' => (bool) env('APP_DEBUG', false),

    'url' => env('APP_URL', 'http://localhost'),

    'timezone' => 'UTC',

    'locale' => 'en',
];

It can contain settings related to:

Application name
Environment
Debug mode
Application URL
Timezone
Locale
Encryption
Service providers

For example, in .env:

APP_NAME=MyApplication

Laravel can retrieve that value using:

env('APP_NAME')

My understanding

I think of app.php as:

General settings for the Laravel application.

2. `auth.php`

The auth.php file deals with authentication.

Authentication is basically answering the question:

Who is this user?

This configuration can define things such as:

Authentication guards
User providers
User models
Password reset configuration

For example:

'providers' => [
    'users' => [
        'driver' => 'eloquent',
        'model' => App\Models\User::class,
    ],
],

This tells Laravel which model it should use when working with users.

For example:

User
  ↓
Login
  ↓
Authentication
  ↓
Authenticated request

My understanding

I think of auth.php as:

How Laravel identifies and authenticates users.

3. `broadcasting.php`

The broadcasting.php file is related to real-time events.

Broadcasting allows Laravel to send events from the server to clients in real time.

For example, imagine a chat application:

User A sends message
        ↓
Laravel
        ↓
Broadcast event
        ↓
User B receives message

This can be useful for:

Chat applications
Real-time notifications
Live dashboards
Real-time status updates

If you're building a simple CRUD API, you may not need to work with this configuration immediately.

My understanding

I think of broadcasting.php as:

Configuration for sending Laravel events to clients in real time.

4. `cache.php`

The cache.php file controls Laravel's caching system.

Caching allows your application to temporarily store data so that it doesn't have to perform the same expensive operation repeatedly.

For example:

Cache::put('username', 'Vincent', 3600);

Laravel can work with different cache stores depending on your configuration.

Examples include:

File
Database
Redis
Array

For example:

CACHE_STORE=redis

My understanding

I think of cache.php as:

Where and how Laravel stores cached data.

5. `concurrency.php`

The concurrency.php file is related to Laravel's concurrency features.

Concurrency is about allowing multiple tasks to execute without unnecessarily waiting for each one to finish before starting the next.

For example:

Without concurrency:

Task A → Task B → Task C

With concurrency:

Task A ─┐
Task B ─┼──→ Results
Task C ─┘

This can be useful when an application needs to perform several independent operations.

As I'm learning Laravel, this is one of the configuration files I'm treating as something to understand later rather than something I need to modify immediately.

My understanding

I think of concurrency.php as:

Configuration related to running multiple operations concurrently.

6. `cors.php`

CORS stands for Cross-Origin Resource Sharing.

This becomes especially important when you're building a separate frontend and backend.

For example:

Frontend
Next.js
http://localhost:3000

        ↓ API request

Backend
Laravel
http://localhost:8000

These are different origins.

The browser needs to know whether the frontend is allowed to communicate with the backend.

The CORS configuration deals with things such as:

Allowed origins
Allowed HTTP methods
Allowed headers
Credentials

For an API, this is particularly important.

My understanding

I think of cors.php as:

Configuration that controls which origins are allowed to communicate with my Laravel application.

7. `database.php`

This is one of the configuration files I'm paying the most attention to because I recently connected Laravel to PostgreSQL.

The database.php file controls Laravel's database connections.

For example, a PostgreSQL connection may look like:

'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE', 'laravel'),
    'username' => env('DB_USERNAME', 'root'),
    'password' => env('DB_PASSWORD', ''),
],

The actual values can come from .env:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=your_password

The relationship can be understood like this:

.env
 ↓
config/database.php
 ↓
Laravel database layer
 ↓
PostgreSQL

My understanding

I think of database.php as:

How Laravel connects to and communicates with databases.

8. `filesystems.php`

This file controls Laravel's file storage.

Imagine an application where users can upload:

Profile pictures
Documents
PDFs
Product images
Videos

Laravel needs to know where those files should be stored.

For example:

Storage::put('documents/example.pdf', $file);

The filesystem configuration determines which storage disk Laravel uses.

My understanding

I think of filesystems.php as:

Where and how Laravel stores files.

9. `hashing.php`

The hashing.php file controls Laravel's hashing configuration.

Hashing is particularly important when dealing with passwords.

You should never store passwords as plain text:

password123

Instead, the password is hashed before being stored:

password123
      ↓
    Hash
      ↓
   Database

Laravel supports hashing algorithms such as:

Bcrypt
Argon
Argon2id

My understanding

I think of hashing.php as:

How Laravel hashes sensitive data such as passwords.

10. `images.php`

The images.php configuration file is related to image handling and processing.

This can become useful when an application needs to work with uploaded images.

For example:

Resizing images
Processing images
Optimizing images
Converting images

This might be useful in applications such as e-commerce platforms where users upload product images.

My understanding

I think of images.php as:

Configuration related to image processing.

11. `logging.php`

The logging.php file controls Laravel's logging system.

Logs are extremely useful when debugging an application.

Laravel can write logs to files such as:

storage/logs/laravel.log

You can also create your own logs:

Log::info('User registered successfully');

Or:

Log::error('Payment failed');

Laravel supports different logging channels.

My understanding

I think of logging.php as:

How Laravel records application events, warnings, and errors.

When debugging Laravel applications, I'll probably spend quite a lot of time looking at:

storage/logs/laravel.log

12. `mail.php`

The mail.php file controls email configuration.

Laravel applications commonly need to send emails for things such as:

Password resets
Email verification
Booking confirmations
Payment receipts
Notifications

For example, .env might contain:

MAIL_MAILER=smtp
MAIL_HOST=smtp.example.com
MAIL_PORT=587
MAIL_USERNAME=your_username
MAIL_PASSWORD=your_password

Laravel uses the mail configuration to determine how emails should be sent.

My understanding

I think of mail.php as:

How Laravel sends emails.

13. `queue.php`

The queue.php file controls Laravel's queue system.

Queues are useful for tasks that don't need to happen before the user receives a response.

For example, sending an email could be handled in the background:

User registers
      ↓
Laravel creates account
      ↓
Email job added to queue
      ↓
Response returned
      ↓
Queue worker sends email

Instead of:

User registers
      ↓
Create account
      ↓
Send email
      ↓
Wait...
      ↓
Return response

Queues can improve application responsiveness.

My understanding

I think of queue.php as:

How Laravel handles background jobs.

14. `services.php`

The services.php file is commonly used for third-party services.

For example:

GitHub
Google
Stripe
PayPal
AWS
External APIs

You might have configuration like:

'github' => [
    'client_id' => env('GITHUB_CLIENT_ID'),
    'client_secret' => env('GITHUB_CLIENT_SECRET'),
    'redirect' => env('GITHUB_REDIRECT_URI'),
],

The actual credentials would normally be stored in .env:

GITHUB_CLIENT_ID=your_client_id
GITHUB_CLIENT_SECRET=your_client_secret
GITHUB_REDIRECT_URI=http://localhost:8000/auth/github/callback

My understanding

I think of services.php as:

Configuration for services outside the Laravel application.

15. `session.php`

The session.php file controls Laravel's session management.

Sessions allow an application to remember information between HTTP requests.

For example:

User logs in
     ↓
Session created
     ↓
User visits another page
     ↓
Laravel knows the user

Laravel can store sessions using different drivers.

For example:

SESSION_DRIVER=file

or:

SESSION_DRIVER=database

My understanding

I think of session.php as:

How Laravel stores and manages user sessions.

16. `view.php`

The view.php file contains configuration related to Laravel's views.

Laravel's traditional server-side frontend system uses Blade templates.

For example:

resources/
└── views/
    ├── welcome.blade.php
    └── dashboard.blade.php

The view configuration helps Laravel locate and work with these templates.

If you're building a Laravel API without Blade, you may not interact with this file very often.

My understanding

I think of view.php as:

Configuration for Laravel's view system.

Which Configuration Files Should I Learn First?

As someone learning Laravel from a backend development perspective, I'm not trying to memorize everything at once.

I'd prioritize them like this:

Learn first

app.php
auth.php
database.php
hashing.php
logging.php
services.php

Then:

cache.php
cors.php
queue.php
session.php

And later:

broadcasting.php
concurrency.php
filesystems.php
images.php
mail.php
view.php

This doesn't mean the second group is less important. It just means you don't need to understand every Laravel feature on day one.

`.env` vs `config`

This was one of the most important things for me to understand.

Laravel has a .env file:

.env

and a configuration directory:

config/

They work together, but they have different purposes.

For example, .env might contain:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=your_password

Then config/database.php reads those values:

'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE', 'laravel'),
    'username' => env('DB_USERNAME', 'root'),
    'password' => env('DB_PASSWORD', ''),
],

So I think of it like this:

.env
  ↓
Environment-specific values
  ↓
config/*.php
  ↓
Laravel configuration
  ↓
Laravel application

`env()` vs `config()`

You'll see these two functions frequently when working with Laravel.

`env()`

env() reads environment variables.

For example:

APP_NAME=MyApplication

You can access it with:

env('APP_NAME')

`config()`

config() reads Laravel's configuration.

For example:

config('app.name')

This can retrieve the application name configured in config/app.php.

A useful rule I'm learning is:

Use env() mainly inside configuration files, and use config() in application code.

For example, in application code, prefer:

config('app.timezone')

rather than repeatedly accessing:

env('APP_TIMEZONE')

Why `php artisan config:clear` Is Important

While setting up PostgreSQL, I ran into a situation where Laravel wasn't using the database configuration I expected.

One command I learned about was:

php artisan config:clear

This clears Laravel's cached configuration.

Laravel can cache configuration to improve performance, especially in production.

If you change your .env file and Laravel appears to be ignoring your changes, you can try:

php artisan config:clear

Then test your application again.

You can also rebuild the configuration cache with:

php artisan config:cache

A Simple Way to Remember the Files

Here's how I'm currently thinking about the configuration files:

File	What it controls
`app.php`	General application settings
`auth.php`	Authentication
`broadcasting.php`	Real-time events
`cache.php`	Caching
`concurrency.php`	Concurrent execution
`cors.php`	Cross-origin requests
`database.php`	Database connections
`filesystems.php`	File storage
`hashing.php`	Password/data hashing
`images.php`	Image processing
`logging.php`	Application logging
`mail.php`	Email
`queue.php`	Background jobs
`services.php`	Third-party services
`session.php`	Sessions
`view.php`	Blade views

Coming From Django?

Since I also work with Django, comparing Laravel with Django helps me understand the concepts.

The two frameworks aren't identical, but there are some useful similarities:

Laravel	Django
`.env`	Environment variables / `.env`
`config/app.php`	`settings.py`
`config/database.php`	`DATABASES`
`config/auth.php`	Authentication configuration
`config/filesystems.php`	Media/storage configuration
`config/mail.php`	Email settings
`config/cache.php`	`CACHES`
`config/logging.php`	`LOGGING`
`config/session.php`	Session configuration

Coming from Django, this comparison makes Laravel's structure a little easier for me to understand.

Final Thoughts

I'm learning that I don't need to understand every Laravel configuration file immediately.

The important thing is to understand why the files exist and when I might need them.

For backend development, the configuration files I'll probably interact with most often are:

database.php
auth.php
app.php
cors.php
logging.php
queue.php
cache.php
services.php

The more I build applications with Laravel, the more these configurations will start making sense through practical use.

I'm sharing this as part of my Laravel learning journey. If you're also learning Laravel, hopefully this gives you a simple starting point for understanding what's inside the config directory.

And if I've misunderstood anything, feel free to correct me in the comments. That's part of learning.

Connecting Laravel to PostgreSQL on Ubuntu: A Beginner's Guide

Vincent Tommi — Fri, 28 Aug 2026 12:55:12 +0000

If you're building your first Laravel application and trying to connect it to PostgreSQL, you might run into an error like this:

SQLSTATE[08006] [7] connection to server at "127.0.0.1", port 5432 failed:
FATAL: password authentication failed for user "postgres"

I ran into this while setting up a fresh Laravel application on Linux.

At first, I thought the problem was with Laravel, but the error actually tells us something useful: Laravel can reach PostgreSQL, but PostgreSQL is rejecting the database credentials.

In this article, I'll walk through how to connect Laravel to PostgreSQL on Ubuntu, create a dedicated database user, configure Laravel, and troubleshoot authentication errors.

Prerequisites

Before starting, make sure you have the following installed:

PHP
Composer
Laravel
PostgreSQL

You can check your PHP installation with:

php -v

Check Composer:

composer -V

And check PostgreSQL:

psql --version

You can also check whether PostgreSQL is running:

sudo systemctl status postgresql

If PostgreSQL isn't running, start it with:

sudo systemctl start postgresql

Create a Laravel Project

If you don't already have a Laravel project, you can create one using Composer:

composer create-project laravel/laravel example-app

Then move into the project:

cd example-app

Laravel stores environment-specific configuration in the .env file.

Configure Laravel for PostgreSQL

Open your .env file:

nano .env

For PostgreSQL, your database configuration should look like this:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=your_password

There are a few important things to notice here.

PostgreSQL uses port 5432

PostgreSQL normally runs on:

MySQL commonly uses:

So don't use 3306 if you're connecting Laravel to PostgreSQL.

Laravel uses `pgsql`

For PostgreSQL, Laravel expects:

DB_CONNECTION=pgsql

Not:

DB_CONNECTION=postgres

What Does the Authentication Error Mean?

When I first tested the connection, I used:

psql -h 127.0.0.1 -U postgres -d postgres -W

PostgreSQL returned:

FATAL: password authentication failed for user "postgres"

This can be confusing when you're new to PostgreSQL.

The important thing is that PostgreSQL is actually responding.

The problem isn't that PostgreSQL can't be found.

Instead, PostgreSQL is saying:

I found the server and the user, but the password provided for that user is incorrect.

So changing the host or port won't fix this particular error.

Create a Dedicated PostgreSQL User

Rather than using the PostgreSQL administrator account for Laravel, I decided to create a separate user specifically for the application.

This is a better approach because your application doesn't need to connect using a PostgreSQL superuser.

First, access PostgreSQL through the system postgres account:

sudo -u postgres psql

You should see something similar to:

postgres=#

You're now inside the PostgreSQL command-line interface.

Create the Laravel User

Create a new PostgreSQL user:

CREATE USER laravel_user WITH PASSWORD 'your_secure_password';

For example:

CREATE USER laravel_user WITH PASSWORD 'myStrongPassword123';

For a real application, use a strong password and don't commit it to Git.

Create the Laravel Database

Now create the database and make the new user its owner:

CREATE DATABASE laravel OWNER laravel_user;

You can check your databases with:

\l

You should see the laravel database in the list.

Grant Permissions

Connect to the Laravel database:

\c laravel

Then grant the user access to the public schema:

GRANT ALL ON SCHEMA public TO laravel_user;

You can also grant privileges on existing tables and sequences:

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO laravel_user;

GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO laravel_user;

For future tables and sequences, you can set default privileges:

ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT ALL ON TABLES TO laravel_user;

ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT ALL ON SEQUENCES TO laravel_user;

When you're finished, exit PostgreSQL:

\q

Test the PostgreSQL Connection

Before going back to Laravel, it's a good idea to test the database connection directly.

Run:

psql -h 127.0.0.1 -U laravel_user -d laravel -W

Enter the password you created earlier.

If the credentials are correct, you should get:

laravel=>

This is an important troubleshooting step.

If the connection works here, you know PostgreSQL is correctly configured and you can focus on Laravel if another problem occurs.

Update Laravel's `.env`

Now configure Laravel with the new PostgreSQL user:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=myStrongPassword123

Replace the password with the one you actually created.

Clear Laravel's Configuration Cache

Laravel may still have the old database configuration cached.

Run:

php artisan config:clear

You should see something similar to:

INFO  Configuration cache cleared successfully.

Run the Migrations

Now run:

php artisan migrate

If everything is configured correctly, Laravel should connect to PostgreSQL and create its migration tables.

You should see output similar to:

INFO  Preparing database.

Creating migration table ................................ DONE

INFO  Running migrations.

0001_01_01_000000_create_users_table .................... DONE
0001_01_01_000001_create_cache_table .................... DONE
0001_01_01_000002_create_jobs_table ..................... DONE

At this point, Laravel is successfully connected to PostgreSQL.

Understanding the Setup

The final setup looks like this:

Laravel Application
        |
        | PostgreSQL connection
        ↓
127.0.0.1:5432
        |
        ↓
PostgreSQL
        |
        ↓
laravel_user
        |
        ↓
laravel database

And your .env contains:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=your_password

Common Mistakes

1. Using the MySQL port

Don't use:

DB_PORT=3306

for PostgreSQL.

Use:

DB_PORT=5432

2. Using the wrong connection name

Don't use:

DB_CONNECTION=postgres

Use:

DB_CONNECTION=pgsql

3. Using `root` as the PostgreSQL username

If you're coming from MySQL, you might be used to:

DB_USERNAME=root

PostgreSQL commonly has an administrative user called:

postgres

However, your Laravel application doesn't need to use the administrator account.

A dedicated user such as:

laravel_user

is a better choice.

4. Forgetting to clear Laravel's configuration

If you change your .env file and Laravel continues using the old configuration, run:

php artisan config:clear

Then try:

php artisan migrate

5. Not testing PostgreSQL separately

If Laravel gives you a database connection error, test PostgreSQL directly first:

psql -h 127.0.0.1 -U laravel_user -d laravel -W

If this fails, the problem is probably with PostgreSQL, the username, password, database, or permissions.

If it succeeds, then you can focus on Laravel's configuration.

Troubleshooting Checklist

Before running:

php artisan migrate

make sure:

PostgreSQL is running
The laravel database exists
laravel_user exists
The password is correct
The user has access to the database
PostgreSQL is running on port 5432
DB_CONNECTION=pgsql
Laravel's configuration cache has been cleared

Then run:

php artisan config:clear
php artisan migrate

Final Thoughts

Connecting Laravel to PostgreSQL for the first time can be confusing because there are several different pieces involved: Laravel, PHP, PostgreSQL, users, passwords, databases, ports, permissions, and environment variables.

The biggest lesson I learned from this setup is that understanding the error is better than randomly changing configuration until something works.

For example, when you see:

FATAL: password authentication failed for user "postgres"

you already know that PostgreSQL is reachable. The problem is authentication.

From there, you can test PostgreSQL independently, create a dedicated application user, verify the credentials, and then connect Laravel.

Hopefully this guide helps another beginner who is setting up Laravel and PostgreSQL on Ubuntu for the first time.

When Ubuntu Keyboard Shortcuts Stop Working: A Systematic GNOME Troubleshooting Guide

Vincent Tommi — Fri, 14 Aug 2026 09:23:03 +0000

Have you ever experienced a strange Ubuntu problem where your keyboard works perfectly, but your keyboard shortcuts suddenly stop working?

That happened to me recently.

I could type normally. Every key worked as expected. But keyboard shortcuts such as Alt + Tab, Ctrl + C, Ctrl + V, and other combinations were not behaving as expected.

At first, this looked like a keyboard problem.

It wasn't.

The keyboard was working properly. The problem was with the way Ubuntu/GNOME was handling shortcuts.

This article explains how I approached the problem and the commands that can help diagnose similar issues.

1. First, determine whether the keyboard or shortcuts are the problem

The first mistake you can make when keyboard shortcuts stop working is assuming that the keyboard is broken.

Before changing anything, test normal typing.

Open a terminal and run:

echo "keyboard test"

If you can type normally, the keyboard hardware and basic input are probably working.

This gives us an important distinction:

Keyboard input works
        ↓
Normal typing works
        ↓
Keyboard shortcuts fail
        ↓
Investigate the desktop/input configuration

This is much better than immediately reinstalling drivers or changing system configurations.

2. Test different types of shortcuts

Not all keyboard shortcuts are handled by the same component.

For example:

Application shortcuts

These include:

Ctrl + C
Ctrl + V
Ctrl + Z
Ctrl + A

These are generally handled by the application.

Desktop/window-manager shortcuts

Examples include:

Alt + Tab
Super
Ctrl + Alt + T

These can be handled by GNOME, the window manager, or the desktop environment.

This distinction is important when troubleshooting.

If Ctrl + C works in one application but Alt + Tab doesn't work, the problem may be related specifically to GNOME's global shortcuts.

3. Check GNOME's shortcut configuration

Ubuntu's GNOME desktop stores many shortcut configurations through gsettings.

For example, you can inspect the shortcut responsible for switching windows:

gsettings get org.gnome.desktop.wm.keybindings switch-windows

You may see something similar to:

['<Alt>Tab']

This tells you that GNOME has Alt + Tab configured as a window-switching shortcut.

You can also check application switching:

gsettings get org.gnome.desktop.wm.keybindings switch-applications

If the expected shortcut is missing or has been changed, GNOME's shortcut configuration may be the source of the problem.

4. Check GNOME Shell shortcuts

Some shortcuts are handled directly by GNOME Shell.

For example:

gsettings get org.gnome.shell.keybindings show-applications

This can help determine whether shortcuts involving the Super key are configured correctly.

The key idea is that instead of guessing, we can inspect the configuration directly.

5. Check Ubuntu's graphical shortcut settings

You can also inspect shortcuts through the GUI.

Go to:

Settings → Keyboard → View and Customize Shortcuts

From there, look at the configured shortcuts for:

Windows
Navigation
Applications
System
Custom shortcuts

This is useful because it allows you to verify the configuration without using the terminal.

6. Check accessibility features

Another easy-to-miss cause is accessibility settings.

Ubuntu provides features such as:

Sticky Keys
Slow Keys
Bounce Keys

If these have been enabled accidentally, keyboard behavior can become confusing.

Go to:

Settings → Accessibility → Typing

and check whether these features are enabled.

If you don't intentionally use them, disable them and test the shortcuts again.

7. Check GNOME extensions

GNOME extensions can also modify or intercept keyboard behavior.

To see installed extensions:

gnome-extensions list

If you suspect an extension is causing the problem, temporarily disable it:

gnome-extensions disable EXTENSION_NAME

Then test the shortcuts again.

This is particularly useful if the problem started after installing or updating a GNOME extension.

8. Check whether Ubuntu is detecting the key combinations

If the configuration appears correct but shortcuts still don't work, the next step is to determine whether the desktop is actually receiving the key events.

One useful tool is wev.

Install it with:

sudo apt install wev

Then run:

wev

Press keys such as:

Ctrl
Alt
Shift
Super

and combinations such as:

Ctrl + C
Alt + Tab

This helps determine whether the underlying input events are reaching the desktop environment.

This is an important debugging principle:

Don't just ask whether a feature works. Determine which layer of the system is failing.

For keyboard shortcuts, the layers can look roughly like:

Keyboard
   ↓
Linux input system
   ↓
Desktop environment
   ↓
GNOME Shell / Window Manager
   ↓
Application
   ↓
Shortcut

Finding the failing layer makes troubleshooting much easier.

9. Don't immediately reset your configuration

One tempting solution is to reset GNOME configuration immediately.

For example:

dconf reset -f /org/gnome/desktop/wm/keybindings/

This can be useful in some situations, but I wouldn't make it the first step.

Why?

Because resetting configuration can remove custom settings that you intentionally created.

A better troubleshooting process is:

1. Confirm the keyboard works
2. Identify which shortcuts fail
3. Determine whether the problem is global or application-specific
4. Inspect GNOME shortcut configuration
5. Check accessibility settings
6. Check GNOME extensions
7. Inspect keyboard events
8. Reset configuration only if necessary

This approach minimizes unnecessary changes.

10. What I learned from the problem

The most important lesson wasn't actually the command that fixed the shortcuts.

It was the troubleshooting methodology.

When something stops working, don't immediately assume the most obvious component is broken.

In my case:

Keyboard works
      ↓
Typing works
      ↓
Shortcuts don't work
      ↓
Keyboard hardware is probably not the problem
      ↓
Investigate GNOME
      ↓
Inspect shortcut configuration
      ↓
Test the input events
      ↓
Identify the configuration/problem layer

This approach can be applied to much more than keyboard shortcuts.

The same principle applies when debugging:

Django applications
APIs
databases
Docker
networking
Linux services
authentication
frontend applications

Instead of asking:

"What can I reinstall?"

Ask:

"Which layer is actually failing?"

Conclusion

A keyboard that works normally while its shortcuts fail doesn't necessarily indicate a hardware problem.

On Ubuntu/GNOME, keyboard shortcuts involve several layers of configuration, including GNOME Shell, the window manager, applications, accessibility settings, and extensions.

The best approach is therefore to troubleshoot systematically rather than immediately resetting or reinstalling components.

The general debugging pattern is simple:

Observe
   ↓
Isolate
   ↓
Inspect
   ↓
Test
   ↓
Fix
   ↓
Verify

That mindset is useful far beyond Linux desktop troubleshooting.

Sometimes the best debugging tool isn't a complicated command.

It's knowing which layer to investigate first.

Git Merge vs Git Rebase: Understanding the Difference

Vincent Tommi — Thu, 16 Jul 2026 17:47:59 +0000

When collaborating on a Git project, one question comes up repeatedly:

Should you use git merge or git rebase?

The truth is that both commands achieve the same end goal—they integrate changes from one branch into another. The key difference lies in how they handle your project's commit history.

Let's break it down.

What is `git merge`?

git merge combines the histories of two branches while preserving the original branch structure.

Imagine you create a feature branch from main, work on a new feature, and meanwhile other developers continue making changes to main. When you're ready to integrate your work, running:

git checkout main
git merge feature-branch

creates a merge commit if both branches have diverged.

Your Git history will clearly show:

Where the feature branch was created.
The commits made on both branches.
The point where the branches were merged back together.

This makes it easy to understand the evolution of a project, especially in teams where multiple developers are working simultaneously.

Advantages of Merge

Preserves the complete project history.
Never rewrites existing commits.
Safe for shared branches.
Makes collaboration easier because everyone keeps the same commit history.

What is `git rebase`?

git rebase takes a different approach.

Instead of creating a merge commit, Git replays your feature branch commits on top of the latest version of the target branch.

For example:

git checkout feature-branch
git rebase main

Git temporarily removes your feature commits, updates your branch with the latest commits from main, and then reapplies your work as new commits.

The result is a clean, linear commit history that looks as if your work was built directly on top of the latest main.

This makes the project history much easier to read.

The Catch with Rebasing

While rebasing creates a cleaner history, it comes with an important tradeoff.

Because Git recreates your commits during the rebase process, each commit receives a new SHA (commit ID).

If you've already pushed those commits to a shared remote branch, rebasing changes history. You'll typically need to force-push your branch:

git push --force-with-lease

This can cause problems for teammates who already based their work on the original commits.

That's why one of the most common Git recommendations is:

Never rebase a branch that other people are actively using.

When Should You Use Merge?

git merge is usually the better choice when:

Working on shared branches.
Collaborating with multiple developers.
Preserving the full history is important.
You want to avoid rewriting commits.

Many teams configure pull requests to use merge commits because they're predictable and safe.

When Should You Use Rebase?

git rebase shines when:

You're working on your own feature branch.
You want to clean up your commit history before opening a pull request.
You prefer a linear Git history.
You haven't shared your branch with others.

A common workflow is to regularly rebase your feature branch onto the latest main, then merge it once it's ready.

Merge vs Rebase at a Glance

Git Merge	Git Rebase
Preserves branch history	Creates a linear history
Creates a merge commit	Does not create a merge commit
Safe for shared branches	Rewrites commit history
Keeps existing commit IDs	Generates new commit IDs
Great for collaboration	Great for cleaning up personal work

Which One Should You Choose?

There isn't a universally "better" command.

If you're collaborating with others and want to preserve history, use git merge.
If you're polishing your own feature branch before merging, use git rebase.

Many development teams actually use both:

Rebase while working locally to keep your branch clean.
Merge when integrating into shared branches to preserve collaboration history.

Understanding the strengths of each command will help you choose the right tool for the situation.

How to Reset a Django Admin Password Using the Django Shell

Vincent Tommi — Wed, 10 Dec 2025 04:42:03 +0000

Forgetting the password for your Django admin account can be frustrating, but resetting it is quick and straightforward using the Django shell. This method works even if you no longer have access to the admin interface and doesn't require any additional packages.

Step-by-Step Guide

Open the Django shell In your project directory (where manage.py is located), run the following command:

python manage.py shell

This will start an interactive Python shell with your Django project loaded.

Reset the password In the shell, execute the following code:

from django.contrib.auth.models import User

# Replace 'admin' with the actual username of the admin account
user = User.objects.get(username='admin')

# Set the new password (replace 'new_secure_password' with your desired password)
user.set_password('new_secure_password')

# Save the changes
user.save()

Important notes:

Use the correct username (it’s usually admin, but it could be something else if you created a custom superuser).
set_password() automatically hashes the password for you—never use user.password = 'plain_text' as that would store the password unhashed.

Exit the shell Once the password is updated, simply type:

exit()

or press Ctrl+D (on Unix-like systems) or Ctrl+Z then Enter (on Windows).

That’s it! You can now log in to the Django admin interface (/admin/) using the username and the new password you just set.
Bonus: Resetting Password for Any User (Not Just Admin)
The same method works for any user in your database. Just change the username to the correct one

user = User.objects.get(username='john_doe')
user.set_password('another_secure_password')
user.save()

Troubleshooting Tips

“User matching query does not exist” Double-check the username (case-sensitive). You can list all users with:

User.objects.all()

Using a custom User model If your project uses a custom user model (e.g., CustomUser), replace User with your model:


from myapp.models import CustomUser
user = CustomUser.objects.get(username='admin')

Conclusion

With just a few lines of code, you can regain access to your Django admin account in seconds. This technique is especially useful on production servers or when email-based password resets are not configured.

How to Work on a Team with Git & GitHub Without Breaking Everything

Vincent Tommi — Tue, 09 Dec 2025 18:44:57 +0000

The Definitive Guide Every Engineering Team Should Adopt

Stop fighting over Git.
Stop breaking main.
Stop losing work. This is the exact workflow used by high-performing teams at startups and scale-ups worldwide — simple enough for juniors, disciplined enough for staff engineers.

The Core Workflow (6 Commands to Rule Them All)

# 1. Safely stash your in-progress changes
git stash push -m "wip: halfway through payment UI"

# 2. Fetch and integrate the latest main
git pull origin main --rebase    # preferred over merge for clean history

# 3. Re-apply your work on top
git stash pop                    # resolves conflicts early

# 4. Stage changes
git add .

# 5. Write a meaningful commit message
git commit -m "feat: add real-time donation progress bar with percentage"

# 6. Push to remote
git push origin HEAD

Daily & Hourly Discipline (Do This Religiously)

git stash
git pull origin main --rebase
git stash pop

Do this:

First thing in the morning
Before starting any new task
After a teammate announces a hotfix
Before pushing any commit

This single habit eliminates 95% of merge conflicts

Pro-Level One-Liner (Add to Your Shell)

# ~/.zshrc or ~/.bash_profile
alias sync="git stash push -m 'autosave $(date +%H:%M)' \
    && git pull origin main --rebase \
    && git stash pop"

Now just run:

sync

Recommended Branching Strategy (Safe + Fast)

Task Type	Branch Name Example	Workflow
Hotfix / Urgent	`hotfix/double-payment`	Direct to main (with PR)
Feature (>1 hour)	`feat/donation-progress-bar`	Branch → PR → Review → Merge
Bugfix	`fix/invalid-goal-calculation`	Branch → PR
Refactor / Chore	`refactor/extract-payment-service`	Branch → PR

# Example: Start a proper feature branch
git pull origin main --rebase
git checkout -b feat/share-fundraiser-buttons
# ... work ...
git add .
git commit -m "feat: add social sharing for fundraisers"
git push -u origin feat/share-fundraiser-buttons
# → Open Pull Request on GitHub

Conventional Commits (Your Team Will Thank You)
Always use this format — enables auto-changelogs and clear history:

feat:     Add new feature
fix:      Bug fix
docs:     Documentation only changes
style:    Formatting, missing semicolons, etc.
refactor: Code change that neither fixes a bug nor adds a feature
perf:     Performance improvements
test:     Adding or correcting tests
chore:    Build process or auxiliary tool changes

Examples:

git commit -m "feat: add fundraiser short link sharing"
git commit -m "fix: prevent negative donation amounts"
git commit -m "refactor: extract donation validation logic"

Conflict Resolution (When stash pop Fails)

git stash pop
# → Conflict in payments/views.py

# Fix the <<< === >>> markers manually
# Then:
git add payments/views.py
git commit  # no -m needed, Git creates merge commit message

Golden Rules Every Team Member Must Follow

1 Never commit directly to main (except hotfixes with approval)
2 Always sync before starting work
3 Always write descriptive commit messages
4 Always push feature branches and open PRs
5 Never force push main (or any shared branch)
6 Rebase locally, merge on GitHub via PR (keeps history clean)

Quick Reference Cheat Sheet (Pin This)

# Stay in sync (run often)
sync                    # your alias
# or manually:
git stash && git pull --rebase origin main && git stash pop

# Ship completed work
git add .
git commit -m "type(scope): description"
git push

# Start new work safely
git pull --rebase origin main
git checkout -b feat/your-feature-name

# Emergency hotfix
git checkout main
git pull --rebase origin main
git checkout -b hotfix/critical-bug

Final Words
I’ve been on teams that lost entire days to merge conflicts.
I’ve been on teams that deployed 20 times per day with zero drama.
The difference was always this: discipline around syncing and branching.
Adopt this workflow today.
Enforce it in code reviews.
Put it in your onboarding docs.
Your future self — and every teammate who’s ever screamed at Git — will thank you.
Now go forth and collaborate like professionals.
Saved you from at least 47 rage-quits in 2025.
You’re welcome.

How to Build a Powerful & Beginner-Friendly Django Admin

Vincent Tommi — Tue, 25 Nov 2025 16:05:33 +0000

A Step-by-Step Tutorial Using a Real-World Fundraising Platform
Perfect for intermediate Django developers who want to go from “it works” to “this admin is actually amazing”.
We’ll use a real crowdfunding/startup fundraising app (with individuals, NGOs, and startups) to teach you every important Django admin feature — with copy-paste code and clear explanations.
By the end of this tutorial, you’ll know how to:

Show custom model properties in the list view
Add filters, search, and bulk edits
Use inlines to edit related models on the same page
Make the change-form beautiful with fieldsets and collapse sections
Add custom columns with links and formatted money
Write safe, performant querysets
Add helpful readonly fields

Let’s build it together!

# models.py (simplified)
class Fundraiser(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE, null=True)
    fundraising_category = models.ForeignKey(FundraisingCategory, ...)
    short_code = models.CharField(max_length=10, unique=True)
    is_approved = models.BooleanField(default=False)
    is_private = models.BooleanField(default=False)
    status = models.CharField(max_length=20, choices=STATUS_CHOICES, default='active')
    created_at = models.DateTimeField(auto_now_add=True)

    @property
    def raised_amount(self):
        return self.paystack_transactions.filter(status='success').aggregate(
            total=Sum('amount')
        )['total'] or 0

class FundraiserImage(models.Model):
    fundraiser = models.ForeignKey(Fundraiser, on_delete=models.CASCADE, related_name='images')
    image = models.ImageField(...)
    is_primary = models.BooleanField(default=False)

class IndividualDetail(models.Model):  # OneToOne with Fundraiser
    fundraiser = models.OneToOneField(Fundraiser, related_name='individual_detail', ...)
    fundraiser_title = models.CharField(...)
    fundraiser_goal = models.DecimalField(...)

# + OrganisationDetail and StartupDetail (also OneToOne)

Step 2: The Most Important Admin — FundraiserAdmin
This will be your main dashboard.

# admin.py
from django.contrib import admin
from django.urls import reverse
from django.utils.html import format_html
from .models import Fundraiser, FundraiserImage, IndividualDetail, OrganisationDetail, StartupDetail


class FundraiserImageInline(admin.TabularInline):   # Step A: Inline images
    model = FundraiserImage
    extra = 1
    fields = ('name', 'image', 'is_primary')
    readonly_fields = ('file_size',)


@admin.register(Fundraiser)
class FundraiserAdmin(admin.ModelAdmin):
    # 1. What columns to show in the list
    list_display = (
        'short_code',
        'user',
        'category_colored',           # custom column (we'll write it)
        'raised_vs_goal',               # beautiful progress column
        'is_approved',
        'is_private',
        'status',
        'created_at',
    )

    # 2. Right sidebar filters
    list_filter = (
        'is_approved',
        'is_private',
        'status',
        'fundraising_category',
        'created_at',
    )

    # 3. Search box
    search_fields = ('short_code', 'user__email', 'user__username')

    # 4. Click the checkbox → edit these fields directly in place
    list_editable = ('is_approved', 'is_private', 'status')

    # 5. These fields are shown but not editable
    readonly_fields = ('short_code', 'created_at', 'updated_at')

    # 6. Inline images right on the same page
    inlines = [FundraiserImageInline]

    # 7. Default sorting
    ordering = ('-created_at',)

    # 8. Performance: avoid N+1 queries
    def get_queryset(self, request):
        return super().get_queryset(request).select_related(
            'user', 'fundraising_category'
        ).prefetch_related('paystack_transactions')

    # 9. Custom column: show category with color
    def category_colored(self, obj):
        color = {
            'Medical': 'crimson',
            'Education': 'royalblue',
            'Startup': 'green',
        }.get(obj.fundraising_category.name, 'gray')
        return format_html(
            '<span style="color: white; background:{}; padding: 2px 8px; border-radius: 4px;">{}</span>',
            color, obj.fundraising_category or "—"
        )
    category_colored.short_description = "Category"

    # 10. Custom column: $12,450 / $50,000 (54%)
    def raised_vs_goal(self, obj):
        goal = None
        if hasattr(obj, 'individual_detail'):
            goal = obj.individual_detail.fundraiser_goal
        elif hasattr(obj, 'organisation_details'):
            goal = obj.organisation_details.fundraiser_goal
        elif hasattr(obj, 'startup_detail'):
            goal = obj.startup_detail.fundraiser_goal

        if not goal:
            return "—"

        raised = obj.raised_amount
        percentage = (raised / goal * 100 if goal > 0 else 0

        return format_html(
            '<b>${:,.0f}</b> → ${:,.0f} <small>({:.0f}%)</small>',
            raised, goal, percentage
        )
    raised_vs_goal.short_description = "Raised / Goal"

Result: Your admin list now looks professional and saves hours of clicking around.

Step 3: Make Individual/Organisation/Startup Pages Beautiful
Example: StartupDetailAdmin

@admin.register(StartupDetail)
class StartupDetailAdmin(admin.ModelAdmin):
    list_display = ('startup_name', 'fundraiser_link', 'industry', 'stage', 'fundraiser_goal')
    list_filter = ('industry', 'stage', 'team_size')
    search_fields = ('startup_name', 'fundraiser__short_code')

    # Group fields nicely on the edit page
    fieldsets = (
        ("Linked Fundraiser", {
            'fields': ('fundraiser',),
            'description': 'This startup belongs to the fundraiser below'
        }),
        ("Startup Info", {
            'fields': ('startup_name', 'business_description', 'location', 'website')
        }),
        ("Fundraising", {
            'fields': ('fundraiser_title', 'fundraiser_details', 'fundraiser_goal')
        }),
        ("Classification", {
            'fields': ('industry', 'stage', 'team_size')
        }),
        ("Social Media (optional)", {
            'fields': ('social_media',),
            'classes': ('collapse',)  # collapsed by default
        }),
    )

    readonly_fields = ('created_at', 'updated_at')

    # Nice clickable link back to the main fundraiser
    def fundraiser_link(self, obj):
        url = reverse('admin:yourapp_fundraiser_change', args=[obj.fundraiser.id])
        return format_html('<a href="{}">{} → View Fundraiser</a>', url, obj.fundraiser.short_code)
    fundraiser_link.short_description = "Fundraiser"

Do the same for IndividualDetailAdmin and OrganisationDetailAdmin — just change the fields.

Step 4: Bonus — Useful Tricks Every Django Developer Should Know

# 1. Custom bulk actions
def approve_selected(modeladmin, request, queryset):
    updated = queryset.update(is_approved=True)
    modeladmin.message_user(request, f"{updated} fundraisers approved!")
approve_selected.short_description = "Approve selected fundraisers"

FundraiserAdmin.actions = ['approve_selected']

# 2. Show image preview in list
def admin_image_preview(self, obj):
    if obj.image:
        return format_html('<img src="{}" width="80" height="50" style="object-fit: cover;"/>', obj.image.url)
    return "(No image)"
admin_image_preview.short_description = "Preview"

Final Result
You now have an admin that:

Non-technical staff love using
Shows real-time money raised
Lets you approve 50 campaigns in 10 seconds
Handles three different content types without confusion
Looks clean and professional

Copy the full final admin.py below:

# Full final admin.py (ready to copy-paste)
from django.contrib import admin
from django.db.models import Sum
from django.urls import reverse
from django.utils.html import format_html
from .models import (
    Fundraiser, FundraiserImage,
    IndividualDetail, OrganisationDetail, StartupDetail
)

class FundraiserImageInline(admin.TabularInline):
    model = FundraiserImage
    extra = 1
    fields = ('name', 'image', 'is_primary', 'file_size')
    readonly_fields = ('file_size',)

@admin.register(Fundraiser)
class FundraiserAdmin(admin.ModelAdmin):
    list_display = ('short_code', 'user', 'category_colored', 'raised_vs_goal',
                    'is_approved', 'is_private', 'status', 'created_at')
    list_filter = ('is_approved', 'is_private', 'status', 'fundraising_category')
    search_fields = ('short_code', 'user__email')
    list_editable = ('is_approved', 'is_private', 'status')
    readonly_fields = ('short_code', 'created_at', 'updated_at')
    inlines = [FundraiserImageInline]
    ordering = ('-created_at',)

    def get_queryset(self, request):
        return super().get_queryset(request).select_related(
            'user', 'fundraising_category'
        ).prefetch_related('paystack_transactions')

    def category_colored(self, obj):
        colors = {'Medical': 'crimson', 'Education': 'royalblue', 'Startup': 'green'}
        color = colors.get(obj.fundraising_category.name if obj.fundraising_category else '', 'gray')
        return format_html(
            '<span style="color:white; background:{}; padding:3px 8px; border-radius:4px;">{}</span>',
            color, obj.fundraising_category or "—"
        )
    category_colored.short_description = "Category"

    def raised_vs_goal(self, obj):
        # same as earlier — omitted for brevity
        pass
    raised_vs_goal.short_description = "Progress"

    def approve_selected(self, request, queryset):
        updated = queryset.update(is_approved=True)
        self.message_user(request, f"{updated} fundraisers approved.")
    approve_selected.short_description = "Approve selected"
    actions = ['approve_selected']

Long Polling vs WebSockets — How to Achieve Real-Time Communication day 55 of system design

Vincent Tommi — Mon, 13 Oct 2025 01:56:47 +0000

Learn the key differences between Long Polling and WebSockets, how they work, and when to use each for real-time applications — with Python examples

Whether you’re playing an online game or chatting with a friend — updates appear in real-time without ever hitting “refresh.”

Behind these seamless experiences lies a crucial engineering decision: how to push real-time updates from servers to clients.

The traditional HTTP model was built around request–response:

“Client asks, server answers.”

But in real-time systems, the server needs to talk first — and more often.

This is where Long Polling and WebSockets come in — two popular methods to achieve real-time communication on the web.

🧠 1. Why Traditional HTTP Isn’t Enough

HTTP follows a client-driven request–response model:

The client (browser/app) sends a request to the server.
The server processes the request and responds.
The connection closes.

This works fine for static or on-demand content, but for live data:

❌ The server can’t push updates to the client.
❌ HTTP is stateless, so there’s no persistent connection.
❌ You’d need constant polling to get new data.

To build truly real-time experiences — like live chat, multiplayer games, or financial tickers — we need a way for the server to instantly notify clients of updates.

⏳ 2. Long Polling

Long Polling is a clever hack that simulates real-time communication over standard HTTP.

Instead of sending requests every second (like regular polling), the client sends a request and waits — keeping the connection open until the server has something new to send.

⚙️ How It Works

Client sends a request and waits for new data.
The server holds the connection open until it has data or a timeout occurs.
If new data arrives → server responds immediately.
If timeout occurs → server sends a minimal response.
The client immediately reopens a new connection.

This creates a near-continuous loop that feels real-time.

✅ Pros

Simple to implement (standard HTTP).
Works everywhere — across proxies, firewalls, and browsers.

❌ Cons

Slight latency after each update (client must reconnect).
Server overhead (many open “hanging” connections).

💡 Use Cases

Simple chat apps or comment feeds.
Notification systems (e.g., “new email” alerts).
Legacy systems that can’t use WebSockets.

💻 Example (Python)


python
import requests
import time

def long_poll():
    while True:
        try:
            response = requests.get("http://localhost:5000/updates", timeout=60)
            if response.status_code == 200 and response.text.strip():
                print("New data:", response.json())
            else:
                print("No new data, reconnecting...")
        except requests.exceptions.Timeout:
            print("Timeout reached, reconnecting...")
        except Exception as e:
            print("Error:", e)
            time.sleep(5)
        finally:
            # Immediately re-establish connection
            continue

if __name__ == "__main__":
    long_poll()

WebSockets

WebSockets provide a persistent, full-duplex connection between the client and server — meaning both can send messages to each other at any time.

This removes the overhead of repeatedly opening and closing HTTP connections.

How It Works

Handshake:
The client sends an HTTP request with Upgrade: websocket.

Connection Upgrade:
The server switches from HTTP → WebSocket (ws:// or wss://).

Persistent Channel:
Both client and server can now exchange messages freely until the connection closes.

✅ Pros

Extremely low latency.

Less network overhead (single persistent connection).

Scales well for frequent or high-volume updates.

❌ Cons

Slightly more complex setup (client + server must support it).

Some firewalls/proxies may block WebSocket traffic.

Managing reconnections adds implementation complexity.

💡 Use Cases

Real-time chat and collaboration tools (Slack, Google Docs).

Multiplayer online games.

Live dashboards (sports, finance, IoT).

Example of the above use cases

import asyncio
import websockets
import json

async def connect():
    uri = "ws://localhost:6789"
    async with websockets.connect(uri) as websocket:
        await websocket.send(json.dumps({"message": "Hello Server!"}))
        print("Connected to server and sent greeting.")

        try:
            async for message in websocket:
                data = json.loads(message)
                print("Received:", data)
        except websockets.ConnectionClosed:
            print("Connection closed. Reconnecting...")
            await asyncio.sleep(2)
            await connect()

 4. Choosing the Right Approach

if __name__ == "__main__":
    asyncio.run(connect())

Factor	Long Polling	WebSockets
Implementation	Simple (HTTP-based)	Requires setup
Performance	Higher latency	Near-zero latency
Scalability	Limited for many clients	Scales efficiently
Compatibility	Works everywhere	May need proxy support
Use Case	Notifications, light updates	Real-time apps, games

🧩 5. Alternatives Worth Considering

Server-Sent Events (SSE)

One-way communication: server → client.

Lightweight and simple for push notifications or news feeds.

MQTT

Publish–subscribe protocol used in IoT.

Designed for lightweight, device-to-server messaging.

Socket.io

Abstraction layer over WebSockets (and Long Polling fallback).

Handles reconnections, fallbacks, and cross-browser quirks automatically.

Final Thoughts

While both Long Polling and WebSockets achieve “real-time” communication, the right choice depends on your project’s needs:

Choose Long Polling when simplicity and broad compatibility matter.

Choose WebSockets when performance, scalability, and bidirectional communication are key.

Either way, both are essential tools in building modern, dynamic, and interactive web experiences.

Concurrency vs Parallelism: Understanding the Difference with Examples day 54 of system design

Vincent Tommi — Fri, 19 Sep 2025 08:47:42 +0000

Concurrency and parallelism are two of the most misunderstood concepts in system design.

While they might sound similar, they refer to fundamentally different approaches to handling tasks.

Simply put:

Concurrency is about dealing with lots of things at once (task management).
Parallelism is about doing lots of things at once (task execution).

In this article, we’ll break down the differences, explore how they work, and walk through real-world applications with examples and code.

What is Concurrency?

Concurrency means an application is making progress on more than one task at the same time.

Even though a single CPU core can only execute one task at a time, it achieves concurrency by rapidly switching between tasks (context switching).

For example:

Playing music while writing code.
The CPU alternates between the two tasks so quickly that it feels like both are happening simultaneously.

But remember: this is not parallelism. This is concurrency.

Real-World Examples

Web Browsers: Rendering pages, fetching resources, responding to clicks.

Web Servers: Handling multiple requests at the same time.
Chat Apps: Sending/receiving messages, updating the UI.
Video Games: Rendering, physics, input handling, background music.

Code Example: Concurrency in Python (asyncio)

import asyncio

async def task(name):
    for i in range(1, 4):
        print(f"{name} - Step {i}")
        await asyncio.sleep(0.5)  # simulate I/O work

async def main():
    await asyncio.gather(
        task("Task A"),
        task("Task B"),
        task("Task C"),
    )

asyncio.run(main())

Output (interleaved execution):

Task A - Step 1
Task B - Step 1
Task C - Step 1
Task A - Step 2
Task B - Step 2
Task C - Step 2
...

What is Parallelism?

Parallelism means multiple tasks are executed at the exact same time.

This requires multiple CPU cores or processors. Each task (or subtask) gets its own execution unit.

Real-World Examples

Machine Learning Training: Distribute dataset batches across GPUs.
Video Rendering: Multiple frames processed simultaneously.
Web Crawlers: Fetch URLs in parallel.
Big Data: Distribute jobs across a cluster.
Scientific Simulations: Weather modeling, physics simulations.

Code Example: Parallelism in Python (multiprocessing)

from multiprocessing import Pool
import time

def work(n):
    print(f"Processing {n}")
    time.sleep(1)  # simulate CPU work
    return n * n

if __name__ == "__main__":
    numbers = [1, 2, 3, 4]

    with Pool(processes=4) as pool:  # use 4 CPU cores
        results = pool.map(work, numbers)

    print("Results:", results)

Output (executed in parallel):

Processing 1
Processing 2
Processing 3
Processing 4
Results: [1, 4, 9, 16]

Here, each task runs on a separate CPU core at the same time.

Concurrency vs Parallelism: Putting It All Together

Concurrent, Not Parallel: Single-core CPU rapidly switching tasks.
Parallel, Not Concurrent: One task split into subtasks, each core handles one.
Neither: Sequential execution, one task at a time.
Both: Multi-core CPU handling multiple concurrent tasks, each split into parallel subtasks.

Final Thoughts

Concurrency = task management (making progress on many things).

Parallelism = task execution (doing many things simultaneously).

Most modern systems use both together for efficiency.

Understanding these concepts helps you design scalable, efficient software — whether you're writing backend servers, training ML models, or building real-time apps.

Vertical vs Horizontal Scaling: Choosing the Right Strategy for Your Application day 53 of system design

Vincent Tommi — Thu, 18 Sep 2025 09:55:49 +0000

As your application grows, it requires more resources to handle the increasing demand. To meet this challenge, two common strategies emerge: vertical scaling (scaling up) and horizontal scaling (scaling out).

In this article, we’ll explore the pros and cons of both approaches and help you understand when to use one over the other.

Vertical Scaling (Scaling Up)

Vertical scaling involves upgrading the resources of a single machine within your system. This can mean enhancing the CPU, RAM, storage, or other hardware components.

Examples include:

Upgrading CPU: Replacing your server’s processor with a more powerful one.
Increasing RAM: Adding more memory to process larger datasets efficiently.
Enhancing Storage: Using faster SSDs or increasing total storage capacity.

✅ Pros

Simplicity: Easy to implement with minimal architectural changes.
Low latency: No inter-server communication needed.
Reduced software costs: Often cheaper initially compared to scaling out.
No major code changes: Works well without modifying your application significantly.

❌ Cons

Limited scalability: There’s only so much you can upgrade a single machine.
Single point of failure: If that server fails, the entire system can go down.
Downtime: Hardware upgrades often require taking the system offline.
High costs in the long run: High-end servers become expensive quickly.

Horizontal Scaling (Scaling Out)

Horizontal scaling involves adding more servers or nodes to the system and distributing the workload across them, often with a load balancer.

✅ Pros

Near-limitless scalability: Add as many nodes as needed.
Improved fault tolerance: Failure of one node doesn’t crash the whole system.
Cost-effective hardware: Uses multiple commodity servers instead of one expensive machine.

❌ Cons

Complexity: Requires careful handling of data consistency, load balancing, and networking.
Increased latency: Communication between nodes introduces overhead.
Higher initial setup costs: Infrastructure is more complex to maintain.
Application compatibility: Some apps need code adjustments to run on distributed systems.

When to Choose Vertical vs Horizontal Scaling

Choose Vertical Scaling when:

Your app has limited scalability needs.
You’re working with legacy applications that are hard to distribute.
Low latency is critical.
You’re on a cost-sensitive project with minimal infrastructure budget.

Choose Horizontal Scaling when:

You anticipate rapid growth in traffic.
High availability is required.
Your app can be easily distributed.
You’re using a microservices architecture.
Cost-effectiveness with commodity hardware is a priority.

Combining Vertical and Horizontal Scaling

In many cases, the best solution is a hybrid approach:

Start by scaling vertically until you reach the limits of a single machine.
Transition to horizontal scaling as demand grows further.

Examples:

Vertically scaled clusters: Each node is powerful, but the cluster scales horizontally.
Database sharding: Data is spread across multiple servers (horizontal), with each server scaled vertically for performance.

Final Thoughts

The choice between vertical and horizontal scaling depends on your application’s needs, growth expectations, budget, and uptime requirements. Often, the most effective strategy is to combine both approaches: start with vertical scaling for simplicity and cost savings, then plan for horizontal scaling to ensure long-term scalability and resilience.

DEV Community: Vincent Tommi

Laravel for Django Developers: A Practical Guide to Laravel Architecture

1. Django vs Laravel: The Mental Translation

2. The Laravel Request Lifecycle

3. Laravel Project Structure

4. Routes: Django's urls.py vs Laravel Routes

5. Route Parameters

6. Controllers: Django Views vs Laravel Controllers

7. Models and Eloquent

8. Creating Models

9. Mass Assignment

10. Migrations

11. Artisan: Laravel's manage.py

12. Relationships

13. One-to-Many Relationships

14. Many-to-Many Relationships

15. Eager Loading

16. Validation: DRF Serializers vs Laravel Form Requests

17. API Resources: Think DRF Serializer Output

18. Middleware

19. Authentication and Authorization

20. Policies and Gates

21. Environment Variables and Configuration

22. Blade Templates

23. Dependency Injection and the Service Container

24. Services and Business Logic

25. Events and Listeners

26. Jobs and Queues

27. Scheduling

28. Seeders and Factories

29. A Complete Laravel API Example

30. Translating a Django Project to Laravel

31. What You Should NOT Do as a Django Developer

32. The Laravel Architecture to Learn

Level 1 — Foundation

Level 2 — Database

Level 3 — API Development

Level 4 — Security

Level 5 — Laravel Architecture

Level 6 — Production

33. The Most Important Concepts to Focus On

1. Eloquent

2. Form Requests

3. API Resources

4. Middleware

5. Policies and Gates

6. Service Container

7. Dependency Injection

8. Jobs and Queues

9. Events and Listeners

10. Artisan

34. The Mental Model I Recommend

35. Final Thoughts

Fixing PDO::MYSQL_ATTR_SSL_CA Deprecation Errors in PHP 8.5 and Laravel

The Problem

The Old Constant

Incorrect

Correct

Fixing database.php

What If You Can't Edit the File With Nano?

Using VS Code

Using the Terminal

Verify That PHP Supports the New Constant

Clear Laravel's Configuration Cache

Another PHP 8.5 Warning

Don't Mix Ubuntu PPAs Just to Fix This

Useful Diagnostic Commands

Check PHP version

Check Laravel version

Check whether PDO MySQL is installed

Check the new PHP 8.5 constant

Find the SSL constant in Laravel's configuration

Final Fix

Conclusion

Understanding the Laravel `config` Folder: What I'm Learning as a Beginner

What is the config folder?

1. app.php

My understanding

2. auth.php

My understanding

4. Routes: Django's `urls.py` vs Laravel Routes

11. Artisan: Laravel's `manage.py`

Fixing `database.php`

What is the `config` folder?

1. `app.php`

2. `auth.php`

3. `broadcasting.php`

4. `cache.php`

5. `concurrency.php`

6. `cors.php`

7. `database.php`

8. `filesystems.php`

9. `hashing.php`

10. `images.php`

11. `logging.php`

12. `mail.php`

13. `queue.php`

14. `services.php`

15. `session.php`

16. `view.php`

`.env` vs `config`

`env()` vs `config()`

`env()`

`config()`

Why `php artisan config:clear` Is Important

Laravel uses `pgsql`

Update Laravel's `.env`

3. Using `root` as the PostgreSQL username