DEV Community: laravel

I shipped Filament Studio 1.3.0, and it is the first version that feels AI-ready

Serhii — Sun, 10 May 2026 16:20:20 +0000

I have been building Filament Studio as a dynamic data model manager for Filament v5 and Laravel 12.

The original value prop was runtime-defined collections and fields on top of an EAV model, so you can build flexible admin/data systems without creating a new migration for every content type.

That part worked.

But while working on the project, I kept coming back to a different question:

If this data layer is dynamic, how should an AI agent interact with it?

My answer in v1.3.0 was to add the MCP foundation instead of hacking together one-off AI endpoints.

So this release makes Filament Studio usable as an AI-facing layer, not just an admin-facing one.

What I added in `v1.3.0`

MCP server foundation under src/Mcp/
HTTP/SSE transport mounted at /ai/studio
stdio transport via php artisan mcp:start studio
Reuse of StudioApiKey for MCP auth
New management scope namespace for MCP operations
Capability discovery resources like:
- studio://info
- studio://field-types
- studio://panel-types
- studio://operators
12 schema-management MCP tools for collections and fields
Confirm-token flow for destructive operations
Canonical serializer + exception handling for tool responses
Tenant-aware behavior aligned with the rest of Studio

Why I think this matters

A lot of AI integration work feels shallow to me.

Either there is a chat UI bolted on top, or there is an agent wired straight into places it probably should not be touching.

For a system like Filament Studio, neither approach feels right.

If the schema is dynamic, the agent needs a real contract:

discover what exists
inspect schema safely
mutate collections and fields through structured tools
handle destructive actions with explicit confirmation tokens
work through auth scopes instead of bypassing application boundaries

That is the part I wanted to build first.

What changed for me conceptually

Before this release, Filament Studio was mainly a human-operated system.

After this release, it is starting to become an agent-addressable one.

That is a much more interesting direction than sprinkling AI on top of the UI.

I want the data model, schema rules, and operational boundaries of a Laravel app to be available to agents in a structured way.

v1.3.0 is my first serious pass at that.

What this release is not

This is not the final AI story for the project.

It is the foundation.

I started with schema management because if that layer is weak, everything above it becomes fragile.

So I would rather get the contract right first, then expand the workflows on top of it.

If you are building with Filament and thinking about AI agents beyond demo-level features, this is the direction I am building toward.

Follow the project if you want to see where the MCP roadmap goes next.

Feedback I would like
Filament Studio v1.3.0 is available now.

GitHub: https://github.com/flexpik/filament-studio
Packagist: https://packagist.org/packages/flexpik/filament-studio

Full-Stack Laravel, React and MySQL Ecommerce Admin Panel

Durgesh Sahani — Sun, 10 May 2026 06:09:16 +0000

In this tutorial series, we build a complete ecommerce admin panel using Laravel, React and MySQL. The goal is not only to copy code, but to understand how a real full-stack application works from request to response.

The flow is simple:

Browser sends request -> React handles UI -> Laravel API handles business logic -> MySQL stores data -> API sends JSON back -> React updates screen.

If you already know basic PHP, HTML, CSS and JavaScript, this project is a good next step because it upgrades those skills into a modern full-stack workflow.

Who This Tutorial Is For

This tutorial is for beginners who already understand basic PHP, HTML, CSS and JavaScript, and now want to learn how modern full-stack projects are structured.

If you are a college student, freelancer, PHP developer, or job seeker trying to move from normal PHP projects into Laravel and React, this project will help you understand how the backend, frontend and database communicate with each other.

We will not build only a small todo app. We will build an ecommerce admin panel because it gives us a real use case:

admin login
protected API routes
categories
products
image upload
MySQL database
React dashboard
API testing

What We Are Going To Learn

how a Laravel REST API and React single page application work together
how to set up Laravel API routes and connect MySQL
how to design ecommerce tables for categories and products
how to create migrations and Eloquent models
how to build category CRUD APIs in Laravel
how to build product CRUD APIs with image upload
how to add authentication using Laravel Sanctum
how to create a React admin layout with Vite
how to connect React login with Laravel API
how to manage categories and products from React
how to upload product images from React using FormData
how to polish the final dashboard with real API data

Watch The Full Series

Watch the complete series on YouTube:

What We Are Building

We are building an ecommerce admin panel with three main parts:

Laravel backend API
React frontend admin panel
MySQL database

The admin panel includes login, category management, product management with image upload, and a final dashboard showing useful ecommerce summary data.

Required Tools

Before starting, install the following tools:

PHP and Composer
Node.js and npm
MySQL
Laravel installer
Visual Studio Code
Postman

If you are using macOS, you can install many tools using Homebrew. If you are using Windows, you can use Laragon, XAMPP, WAMP, or install PHP, Composer, Node and MySQL separately.

Useful official websites:

PHP: https://www.php.net/
Composer: https://getcomposer.org/
Laravel: https://laravel.com/
Node.js: https://nodejs.org/
MySQL: https://www.mysql.com/
Postman: https://www.postman.com/

For this series, the backend and frontend are kept in one project folder:

ecommerce-admin-panel/
  backend/
  frontend/

What Is Laravel?

Laravel is a PHP framework used to build web applications and APIs. In this project, Laravel is responsible for routes, controllers, validation, authentication, database models, migrations, file upload, and JSON responses.

Instead of writing raw PHP files for every API endpoint, Laravel gives us a clean structure:

routes are defined in routes/api.php
request logic goes inside controllers
database records are represented by Eloquent models
table structure is created using migrations

What Is React?

React is a JavaScript library for building user interfaces. In this project, React handles the admin panel screens: login, dashboard, categories and products.

React does not directly talk to MySQL. Instead, React sends HTTP requests to the Laravel API. Laravel validates the request, works with MySQL, and sends JSON back to React.

What Is MySQL?

MySQL is the database used to store our admin data. In this project, MySQL stores users, categories, products, access tokens, and timestamps.

The important idea is this:

React does not store permanent data. Laravel does not store permanent data in controllers. MySQL is the final storage layer.

What Is REST API?

REST API is a way for two applications to communicate using HTTP requests.

In this project:

React sends GET, POST, PUT and DELETE requests
Laravel receives those requests
Laravel validates the data
Laravel stores or reads data from MySQL
Laravel returns JSON
React updates the UI using that JSON

Example:

GET /api/categories

This means React is asking Laravel: "Please send me all categories."

Laravel responds with JSON:

{
  "data": [
    {
      "id": 1,
      "name": "Laptops",
      "slug": "laptops"
    }
  ]
}

What Is Laravel Sanctum?

Laravel Sanctum is used for API authentication. In simple words, after the admin logs in, Laravel creates a token. React stores that token and sends it with every protected API request.

Without token:

Request blocked

With token:

Request allowed

This is how we protect category and product management from public access.

What Is Vite?

Vite is a frontend build tool. It helps us create and run a React app quickly.

In older React tutorials, you may see create-react-app. In this project, we use Vite because it is faster and is commonly used in modern React projects.

Step 1: Create Laravel Backend

First we create the Laravel backend app.

laravel new backend --no-interaction
cd backend
php artisan install:api --without-migration-prompt --no-interaction

The install:api command enables API support and installs Sanctum-related files so we can later protect routes with tokens.

Then we configure MySQL in the .env file:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=ecommerce_admin
DB_USERNAME=learnwebcoding
DB_PASSWORD=

After the database is ready, run migrations:

php artisan migrate

If you want to create the database from terminal, you can use MySQL commands:

CREATE DATABASE ecommerce_admin;

For local development, make sure the database name, username and password in .env match your MySQL setup.

Step 2: Understand API Routes

Laravel API routes live inside:

backend/routes/api.php

A simple health route can be used to confirm the API is working:

Route::get('/health', function () {
    return response()->json([
        'status' => 'ok',
    ]);
});

When we open /api/health, Laravel returns JSON. This confirms the frontend can later consume Laravel as an API.

Start the Laravel API server:

php artisan serve

Now test:

http://127.0.0.1:8000/api/health

If everything is correct, you should see a JSON response.

Step 3: Database Design

For this ecommerce admin panel, we need two main tables:

categories
products

The categories table stores product groups:

id
name
slug
description
status
created_at
updated_at

The products table stores the actual catalog items:

id
category_id
name
slug
description
price
stock
image
status
created_at
updated_at

The important relationship is:

One category can have many products, and each product belongs to one category.

Step 4: Create Models and Migrations

Laravel can generate a model and migration together:

php artisan make:model Category -m --no-interaction
php artisan make:model Product -m --no-interaction

In the category migration, we add the category fields:

$table->string('name');
$table->string('slug')->unique();
$table->text('description')->nullable();
$table->boolean('status')->default(true);

In the product migration, we add product fields:

$table->foreignId('category_id')->constrained()->cascadeOnDelete();
$table->string('name');
$table->string('slug')->unique();
$table->text('description')->nullable();
$table->decimal('price', 10, 2);
$table->integer('stock')->default(0);
$table->string('image')->nullable();
$table->boolean('status')->default(true);

Then run:

php artisan migrate

Here is the final code for create_categories_table.php:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     */
    public function up(): void
    {
        Schema::create('categories', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->string('slug')->unique();
            $table->text('description')->nullable();
            $table->boolean('status')->default(true);

            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     */
    public function down(): void
    {
        Schema::dropIfExists('categories');
    }
};

Here is the final code for create_products_table.php:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     */
    public function up(): void
    {
        Schema::create('products', function (Blueprint $table) {
            $table->id();
            $table->foreignId('category_id')->constrained()->cascadeOnDelete();
            $table->string('name');
            $table->string('slug')->unique();
            $table->text('description')->nullable();
            $table->decimal('price', 10, 2)->default(0);
            $table->unsignedInteger('stock')->default(0);
            $table->string('image')->nullable();
            $table->boolean('status')->default(true);

            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     */
    public function down(): void
    {
        Schema::dropIfExists('products');
    }
};

Step 5: Category Model

In app/Models/Category.php, we allow mass assignment for category fields:

protected $fillable = [
    'name',
    'slug',
    'description',
    'status',
];

Then we define the relationship:

public function products()
{
    return $this->hasMany(Product::class);
}

This tells Laravel that a category can have many products.

Here is the final code for app/Models/Category.php:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\HasMany;


class Category extends Model
{
    //

    protected $fillable = [
        'name',
        'slug',
        'description',
        'status',
    ];

    protected $casts = [
        'status' => 'boolean',
    ];

    public function products(): HasMany
    {
        return $this->hasMany(Product::class);
    }

}

Step 6: Product Model

In app/Models/Product.php, we add fillable fields:

protected $fillable = [
    'category_id',
    'name',
    'slug',
    'description',
    'price',
    'stock',
    'image',
    'status',
];

Then we define the category relationship:

public function category()
{
    return $this->belongsTo(Category::class);
}

This makes it easy to load each product with its category.

Here is the final code for app/Models/Product.php:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;


class Product extends Model
{
    //

    protected $fillable = [
        'category_id',
        'name',
        'slug',
        'description',
        'price',
        'stock',
        'image',
        'status',
    ];

    protected $casts = [
        'price' => 'decimal:2',
        'status' => 'boolean',
    ];

    public function category(): BelongsTo
    {
        return $this->belongsTo(Category::class);
    }

}

Step 7: Build Category REST API

The category API handles:

list categories
create category
show category
update category
delete category

Create the controller:

php artisan make:controller Api/CategoryController --api --no-interaction

In routes/api.php, register the route:

use App\Http\Controllers\Api\CategoryController;

Route::apiResource('categories', CategoryController::class);

The store method validates incoming data and creates a category:

$validated = $request->validate([
    'name' => ['required', 'string', 'max:255'],
    'slug' => ['required', 'string', 'max:255', 'unique:categories,slug'],
    'description' => ['nullable', 'string'],
    'status' => ['boolean'],
]);

$category = Category::create($validated);

return response()->json([
    'message' => 'Category created successfully.',
    'data' => $category,
], 201);

This same pattern is used for update and delete: validate request, run Eloquent query, return JSON response.

Here is the final code for app/Http/Controllers/Api/CategoryController.php:

<?php

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Models\Category;
use Illuminate\Http\Request;

class CategoryController extends Controller
{
    public function index()
    {
        $categories = Category::latest()->get();

        return response()->json([
            'data' => $categories,
        ]);
    }

    public function store(Request $request)
    {
        $validated = $request->validate([
            'name' => ['required', 'string', 'max:255'],
            'slug' => ['required', 'string', 'max:255', 'unique:categories,slug'],
            'description' => ['nullable', 'string'],
            'status' => ['required', 'boolean'],
        ]);

        $category = Category::create($validated);

        return response()->json([
            'message' => 'Category created successfully.',
            'data' => $category,
        ], 201);
    }

    public function show(Category $category)
    {
        return response()->json([
            'data' => $category,
        ]);
    }

    public function update(Request $request, Category $category)
    {
        $validated = $request->validate([
            'name' => ['required', 'string', 'max:255'],
            'slug' => ['required', 'string', 'max:255', 'unique:categories,slug,' . $category->id],
            'description' => ['nullable', 'string'],
            'status' => ['required', 'boolean'],
        ]);

        $category->update($validated);

        return response()->json([
            'message' => 'Category updated successfully.',
            'data' => $category,
        ]);
    }

    public function destroy(Category $category)
    {
        $category->delete();

        return response()->json([
            'message' => 'Category deleted successfully.',
        ]);
    }
}

Step 8: Test Category API With Postman

Before connecting React, test the API using Postman.

Create category:

POST http://127.0.0.1:8000/api/categories

JSON body:

{
  "name": "Laptops",
  "slug": "laptops",
  "description": "Laptop products",
  "status": true
}

List categories:

GET http://127.0.0.1:8000/api/categories

Update category:

PUT http://127.0.0.1:8000/api/categories/1

Delete category:

DELETE http://127.0.0.1:8000/api/categories/1

Postman testing helps confirm Laravel is working before React is added.

Step 9: Build Product REST API With Image Upload

Products are similar to categories, but products also support image upload.

Create the controller:

php artisan make:controller Api/ProductController --api --no-interaction

use App\Http\Controllers\Api\ProductController;

Route::apiResource('products', ProductController::class);

For product image upload, Laravel stores the image file and saves the path in MySQL:

if ($request->hasFile('image')) {
    $validated['image'] = $request->file('image')->store('products', 'public');
}

$product = Product::create($validated);

To make uploaded files accessible from the browser, create the storage link:

php artisan storage:link

Now a product can have name, slug, category, price, stock, status, and image.

When deleting a product, we should also delete the uploaded image from storage:

if ($product->image) {
    Storage::disk('public')->delete($product->image);
}

$product->delete();

This keeps the storage folder clean.

Here is the final code for app/Http/Controllers/Api/ProductController.php:

<?php

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Models\Product;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Storage;

class ProductController extends Controller
{
    public function index()
    {
        $products = Product::with('category')->latest()->get();

        return response()->json([
            'data' => $products,
        ]);
    }

    public function store(Request $request)
    {
        $validated = $request->validate([
            'category_id' => ['required', 'exists:categories,id'],
            'name' => ['required', 'string', 'max:255'],
            'slug' => ['required', 'string', 'max:255', 'unique:products,slug'],
            'description' => ['nullable', 'string'],
            'price' => ['required', 'numeric', 'min:0'],
            'stock' => ['required', 'integer', 'min:0'],
            'image' => ['nullable', 'image', 'max:2048'],
            'status' => ['required', 'boolean'],
        ]);

        if ($request->hasFile('image')) {
            $validated['image'] = $request->file('image')->storeAs(
                'products',
                $validated['slug'] . '.' . $request->file('image')->extension(),
                'public'
            );
        }

        $product = Product::create($validated);

        return response()->json([
            'message' => 'Product created successfully.',
            'data' => $product->load('category'),
        ], 201);
    }

    public function show(Product $product)
    {
        return response()->json([
            'data' => $product->load('category'),
        ]);
    }

    public function update(Request $request, Product $product)
    {
        $validated = $request->validate([
            'category_id' => ['required', 'exists:categories,id'],
            'name' => ['required', 'string', 'max:255'],
            'slug' => ['required', 'string', 'max:255', 'unique:products,slug,' . $product->id],
            'description' => ['nullable', 'string'],
            'price' => ['required', 'numeric', 'min:0'],
            'stock' => ['required', 'integer', 'min:0'],
            'image' => ['nullable', 'image', 'max:2048'],
            'status' => ['required', 'boolean'],
        ]);

        if ($request->hasFile('image')) {
            if ($product->image) {
                Storage::disk('public')->delete($product->image);
            }

            $validated['image'] = $request->file('image')->storeAs(
                'products',
                $validated['slug'] . '.' . $request->file('image')->extension(),
                'public'
            );
        }

        $product->update($validated);

        return response()->json([
            'message' => 'Product updated successfully.',
            'data' => $product->load('category'),
        ]);
    }

    public function destroy(Product $product)
    {
        if ($product->image) {
            Storage::disk('public')->delete($product->image);
        }

        $product->delete();

        return response()->json([
            'message' => 'Product deleted successfully.',
        ]);
    }
}

Step 10: Authentication With Laravel Sanctum

Authentication protects the admin APIs. We use Laravel Sanctum token authentication.

The login endpoint validates email and password, checks credentials, and creates a token:

$token = $user->createToken('admin-token')->plainTextToken;

return response()->json([
    'message' => 'Login successful.',
    'token' => $token,
    'user' => $user,
]);

Protected routes use Sanctum middleware:

Route::middleware('auth:sanctum')->group(function () {
    Route::apiResource('categories', CategoryController::class);
    Route::apiResource('products', ProductController::class);
});

React must send the token in the Authorization header:

Authorization: Bearer YOUR_TOKEN_HERE

Example auth routes:

Route::post('/login', [AuthController::class, 'login']);

Route::middleware('auth:sanctum')->group(function () {
    Route::get('/user', [AuthController::class, 'user']);
    Route::post('/logout', [AuthController::class, 'logout']);
    Route::apiResource('categories', CategoryController::class);
    Route::apiResource('products', ProductController::class);
});

The main idea is simple:

login route is public
category and product routes are protected
React must send token after login

Here is the final code for app/Http/Controllers/Api/AuthController.php:

<?php

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Models\User;
use Illuminate\Support\Facades\Hash;
use Illuminate\Validation\ValidationException;

use Illuminate\Http\Request;

class AuthController extends Controller
{
    //
    public function login(Request $request)
    {
        $validated = $request->validate([
            'email' => ['required', 'email'],
            'password' => ['required', 'string'],
        ]);

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

        if (! $user || ! Hash::check($validated['password'], $user->password)) {
            throw ValidationException::withMessages([
                'email' => ['The provided credentials are incorrect.'],
            ]);
        }

        $token = $user->createToken('admin-token')->plainTextToken;

        return response()->json([
            'message' => 'Login successful.',
            'token' => $token,
            'user' => $user,
        ]);
    }

    public function me(Request $request)
    {
        return response()->json([
            'data' => $request->user(),
        ]);
    }

    public function logout(Request $request)
    {
        $request->user()->currentAccessToken()->delete();

        return response()->json([
            'message' => 'Logged out successfully.',
        ]);
    }

}

Here is the final code for routes/api.php:

<?php


use App\Http\Controllers\Api\AuthController;
use App\Http\Controllers\Api\CategoryController;
use App\Http\Controllers\Api\ProductController;
use Illuminate\Support\Facades\Route;

Route::get('/health', function () {
    return response()->json([
        'status' => 'success',
        'message' => 'Laravel API is working.',
        'app' => config('app.name'),
        'timestamp' => now()->toISOString(),
    ]);
});

Route::post('/login', [AuthController::class, 'login']);

Route::middleware('auth:sanctum')->group(function () {
    Route::get('/me', [AuthController::class, 'me']);
    Route::post('/logout', [AuthController::class, 'logout']);

    Route::apiResource('categories', CategoryController::class);
    Route::apiResource('products', ProductController::class);
});

Step 11: Create React Frontend With Vite

Now we create the React frontend:

npm create vite@latest frontend -- --template react
cd frontend
npm install
npm run dev

We also install icons for the final UI polish:

npm install lucide-react

Vite gives us a fast React development setup. The React app runs on:

http://127.0.0.1:5173

The Laravel API runs on:

http://127.0.0.1:8000

Step 12: Create API Helper File in React

Inside React, create:

frontend/src/api.js

This file keeps API calls in one place:

const API_URL = 'http://127.0.0.1:8000/api';

async function apiRequest(path, options = {}) {
  const token = options.token;
  const isFormData = options.body instanceof FormData;

  const headers = {
    Accept: 'application/json',
    ...(isFormData ? {} : { 'Content-Type': 'application/json' }),
    ...options.headers,
  };

  if (token) {
    headers.Authorization = `Bearer ${token}`;
  }

  const response = await fetch(`${API_URL}${path}`, {
    ...options,
    headers,
  });

  const data = await response.json();

  if (!response.ok) {
    throw new Error(data.message || 'Request failed.');
  }

  return data;
}

This helper handles JSON requests, FormData requests, authentication token, errors, and final response parsing.

Now we can create small reusable functions:

export function getCategories(token) {
  return apiRequest('/categories', {
    token,
  });
}

export function getProducts(token) {
  return apiRequest('/products', {
    token,
  });
}

This keeps components cleaner because components do not need to repeat the full fetch logic again and again.

Here is the final code for frontend/src/api.js:

const API_URL = 'http://127.0.0.1:8000/api';

async function apiRequest(path, options = {}) {
  const token = options.token;
  const isFormData = options.body instanceof FormData;

  const headers = {
    Accept: 'application/json',
    ...(isFormData ? {} : { 'Content-Type': 'application/json' }),
    ...options.headers,
  };

  if (token) {
    headers.Authorization = `Bearer ${token}`;
  }

  const response = await fetch(`${API_URL}${path}`, {
    ...options,
    headers,
  });

  const data = await response.json();

  if (!response.ok) {
    throw new Error(data.message || 'Request failed.');
  }

  return data;
}

export function loginAdmin(credentials) {
  return apiRequest('/login', {
    method: 'POST',
    body: JSON.stringify(credentials),
  });
}

export function getCategories(token) {
  return apiRequest('/categories', {
    token,
  });
}

export function createCategory(category, token) {
  return apiRequest('/categories', {
    method: 'POST',
    token,
    body: JSON.stringify(category),
  });
}

export function updateCategory(id, category, token) {
  return apiRequest(`/categories/${id}`, {
    method: 'PUT',
    token,
    body: JSON.stringify(category),
  });
}

export function deleteCategory(id, token) {
  return apiRequest(`/categories/${id}`, {
    method: 'DELETE',
    token,
  });
}

export function getProducts(token) {
  return apiRequest('/products', {
    token,
  });
}

export function createProduct(product, token) {
  return apiRequest('/products', {
    method: 'POST',
    token,
    body: product,
  });
}

export function updateProduct(id, product, token) {
  product.append('_method', 'PUT');

  return apiRequest(`/products/${id}`, {
    method: 'POST',
    token,
    body: product,
  });
}

export function deleteProduct(id, token) {
  return apiRequest(`/products/${id}`, {
    method: 'DELETE',
    token,
  });
}

Step 13: React Login Page

The login page sends email and password to Laravel:

export function loginAdmin(credentials) {
  return apiRequest('/login', {
    method: 'POST',
    body: JSON.stringify(credentials),
  });
}

After login, React stores the token:

localStorage.setItem('admin_token', response.token);

Then the user is redirected to the dashboard.

A simple login form has:

email state
password state
loading state
error state
submit handler

The submit handler calls Laravel:

async function handleLogin(event) {
  event.preventDefault();

  try {
    const response = await loginAdmin({ email, password });
    localStorage.setItem('admin_token', response.token);
    onLogin(response.user);
  } catch (error) {
    setError(error.message);
  }
}

This is the first real connection between React and Laravel authentication.

Here is the final code for frontend/src/Login.jsx:

import { useState } from 'react';
import { loginAdmin } from './api';

function Login({ onLogin }) {
  const [email, setEmail] = useState('admin@example.com');
  const [password, setPassword] = useState('password');
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState('');

  async function handleLogin(event) {
    event.preventDefault();
    setLoading(true);
    setError('');

    try {
      const response = await loginAdmin({ email, password });
      localStorage.setItem('admin_token', response.token);
      onLogin(response.user);
    } catch (error) {
      setError(error.message);
    } finally {
      setLoading(false);
    }
  }

  return (
    <main className="auth-page">
      <section className="auth-card">
        <div className="brand-row login-brand">
          <div className="brand-logo">LW</div>
          <div>
            <p className="eyebrow">Ecommerce Admin</p>
            <h1>Login to dashboard</h1>
          </div>
        </div>

        <p className="muted">
          This form sends credentials to Laravel and stores the Sanctum token in React.
        </p>

        <form className="login-form" onSubmit={handleLogin}>
          <label htmlFor="email">Email address</label>
          <input
            autoFocus
            id="email"
            type="email"
            value={email}
            onChange={(event) => setEmail(event.target.value)}
          />

          <label htmlFor="password">Password</label>
          <input
            id="password"
            type="password"
            value={password}
            onChange={(event) => setPassword(event.target.value)}
          />

          {error && <p className="alert error">{error}</p>}

          <button type="submit" disabled={loading}>
            {loading ? 'Logging in...' : 'Login'}
          </button>
        </form>
      </section>
    </main>
  );
}

export default Login;

Step 14: React Admin Layout

The admin layout includes:

sidebar
dashboard link
categories link
products link
logout button
main content area

In App.jsx, React decides which screen to show:

{activeScreen === 'categories' ? (
  <CategoryManager token={localStorage.getItem('admin_token')} />
) : activeScreen === 'products' ? (
  <ProductManager token={localStorage.getItem('admin_token')} />
) : (
  <Dashboard
    token={localStorage.getItem('admin_token')}
    onOpenProducts={() => setActiveScreen('products')}
    onLogout={handleLogout}
  />
)}

This keeps the app simple while still giving us multiple admin screens.

The logout function removes the token:

function handleLogout() {
  localStorage.removeItem('admin_token');
  setActiveScreen('dashboard');
  setUser(null);
}

After logout, React shows the login page again.

Here is the final code for frontend/src/App.jsx:

import { useState } from 'react';
import './App.css';
import Login from './Login';
import CategoryManager from './CategoryManager';
import ProductManager from './ProductManager';
import Dashboard from './Dashboard';

function App() {
  const [user, setUser] = useState(null);
  const [activeScreen, setActiveScreen] = useState('dashboard');

  function handleLogout() {
    localStorage.removeItem('admin_token');
    setActiveScreen('dashboard');
    setUser(null);
  }

  if (!user) {
    return <Login onLogin={setUser} />;
  }

  return (
    <div className="admin-layout">
      <aside className="sidebar">
        <div className="brand">
          <div className="brand-logo">LW</div>
          <div>
            <h2>Learn Admin</h2>
            <p>Ecommerce Panel</p>
          </div>
        </div>

        <nav className="nav-list" aria-label="Admin navigation">
          <button
            className={activeScreen === 'dashboard' ? 'nav-link active' : 'nav-link'}
            type="button"
            onClick={() => setActiveScreen('dashboard')}
          >
            Dashboard
          </button>
          <button
            className={activeScreen === 'categories' ? 'nav-link active' : 'nav-link'}
            type="button"
            onClick={() => setActiveScreen('categories')}
          >
            Categories
          </button>
          <button
            className={activeScreen === 'products' ? 'nav-link active' : 'nav-link'}
            type="button"
            onClick={() => setActiveScreen('products')}
          >
            Products
          </button>
        </nav>
      </aside>

      <main className="main-content">
        {activeScreen === 'categories' ? (
          <CategoryManager token={localStorage.getItem('admin_token')} />
        ) : activeScreen === 'products' ? (
          <ProductManager token={localStorage.getItem('admin_token')} />
        ) : (
          <Dashboard
            token={localStorage.getItem('admin_token')}
            onOpenProducts={() => setActiveScreen('products')}
            onLogout={handleLogout}
          />
        )}
      </main>
    </div>
  );
}

export default App;

Step 15: Category Management in React

Category management includes:

list categories
create category
edit category
update category
delete category

React loads categories using:

export function getCategories(token) {
  return apiRequest('/categories', {
    token,
  });
}

Create category:

export function createCategory(category, token) {
  return apiRequest('/categories', {
    method: 'POST',
    token,
    body: JSON.stringify(category),
  });
}

The category form uses controlled inputs, which means React state is the source of truth:

<input
  id="name"
  value={form.name}
  onChange={(event) => setForm({ ...form, name: event.target.value })}
/>

When the form is submitted, React calls Laravel, reloads the list, and shows a success message.

The save function chooses create or update:

async function handleSaveCategory(event) {
  event.preventDefault();
  setSaving(true);
  setError('');
  setMessage('');

  try {
    if (editingId) {
      await updateCategory(editingId, form, token);
      setMessage('Category updated successfully.');
    } else {
      await createCategory(form, token);
      setMessage('Category created successfully.');
    }

    resetForm();
    await loadCategories();
  } catch (error) {
    setError(error.message);
  } finally {
    setSaving(false);
  }
}

This is the same CRUD idea from normal PHP projects, but now the UI and API are separated.

Here is the final code for frontend/src/CategoryManager.jsx:

import { useEffect, useRef, useState } from 'react';
import {
  createCategory,
  deleteCategory,
  getCategories,
  updateCategory,
} from './api';

const emptyForm = {
  name: '',
  slug: '',
  description: '',
  status: true,
};

function CategoryManager({ token }) {
  const [categories, setCategories] = useState([]);
  const [form, setForm] = useState(emptyForm);
  const [editingId, setEditingId] = useState(null);
  const [saving, setSaving] = useState(false);
  const [error, setError] = useState('');
  const [message, setMessage] = useState('');
  const nameInputRef = useRef(null);

  async function loadCategories() {
    const response = await getCategories(token);
    setCategories(response.data || []);
  }

  useEffect(() => {
    if (token) {
      loadCategories();
    }
  }, [token]);

  useEffect(() => {
    if (editingId) {
      nameInputRef.current?.focus();
    }
  }, [editingId]);

  function resetForm() {
    setForm(emptyForm);
    setEditingId(null);
  }

  function handleEdit(category) {
    setError('');
    setMessage('');
    setEditingId(category.id);
    setForm({
      name: category.name,
      slug: category.slug,
      description: category.description || '',
      status: Boolean(category.status),
    });
  }

  async function handleSaveCategory(event) {
    event.preventDefault();
    setSaving(true);
    setError('');
    setMessage('');

    try {
      if (editingId) {
        await updateCategory(editingId, form, token);
        setMessage('Category updated successfully.');
      } else {
        await createCategory(form, token);
        setMessage('Category created successfully.');

      }

      resetForm();
      await loadCategories();
    } catch (error) {
      setError(error.message);
    } finally {
      setSaving(false);
    }
  }

  async function handleDelete(id) {
    setError('');
    setMessage('');
    await deleteCategory(id, token);
    setMessage('Category deleted successfully.');
    await loadCategories();
  }

  return (
    <section className="category-page">
      <header className="page-header">
        <div>
          <p className="eyebrow">Catalog</p>
          <h1>Category Management</h1>
        </div>
      </header>

      <div className="content-grid">
        <form className="panel category-form" onSubmit={handleSaveCategory}>
          <h2>{editingId ? 'Edit category' : 'Create category'}</h2>

          <label htmlFor="name">Name</label>
          <input
            id="name"
            ref={nameInputRef}
            value={form.name}
            onChange={(event) => setForm({ ...form, name: event.target.value })}
            placeholder="Laptops"
          />

          <label htmlFor="slug">Slug</label>
          <input
            id="slug"
            value={form.slug}
            onChange={(event) => setForm({ ...form, slug: event.target.value })}
            placeholder="laptops"
          />

          <label htmlFor="description">Description</label>
          <textarea
            id="description"
            value={form.description}
            onChange={(event) => setForm({ ...form, description: event.target.value })}
            placeholder="Laptop products"
          />

          <label className="checkbox-row">
            <input
              type="checkbox"
              checked={form.status}
              onChange={(event) => setForm({ ...form, status: event.target.checked })}
            />
            Active category
          </label>

          {error && <p className="alert error">{error}</p>}
          {message && <p className="alert success">{message}</p>}

          <div className="button-row">
            <button type="submit" disabled={saving}>
              {saving ? 'Saving...' : editingId ? 'Update Category' : 'Create Category'}
            </button>
            {editingId && (
              <button type="button" className="secondary-button" onClick={resetForm}>
                Cancel
              </button>
            )}
          </div>
        </form>

        <section className="panel category-list">
          <div className="list-header">
            <h2>Categories</h2>
            <span>{categories.length} total</span>
          </div>

          {categories.map((category) => (
            <article className="category-row" key={category.id}>
              <div>
                <strong>{category.name}</strong>
                <span>{category.slug}</span>
              </div>
              <small>{category.status ? 'Active' : 'Inactive'}</small>
              <div className="row-actions">
                <button type="button" className="secondary-button" onClick={() => handleEdit(category)}>
                  Edit
                </button>
                <button type="button" className="danger-button" onClick={() => handleDelete(category.id)}>
                  Delete
                </button>
              </div>
            </article>
          ))}
        </section>
      </div>
    </section>
  );
}

export default CategoryManager;

Step 16: Product Management in React

Product management is similar to category management, but products use FormData because of image upload.

function buildProductFormData() {
  const productData = new FormData();

  productData.append('category_id', form.category_id);
  productData.append('name', form.name);
  productData.append('slug', form.slug);
  productData.append('description', form.description);
  productData.append('price', form.price);
  productData.append('stock', form.stock);
  productData.append('status', form.status ? '1' : '0');

  if (form.image) {
    productData.append('image', form.image);
  }

  return productData;
}

For update with file upload, React sends a POST request and appends _method as PUT:

export function updateProduct(id, product, token) {
  product.append('_method', 'PUT');

  return apiRequest(`/products/${id}`, {
    method: 'POST',
    token,
    body: product,
  });
}

This works nicely with Laravel file upload handling.

Product create, edit and delete follow the same pattern:

build form data
send request to Laravel
show success or error message
reload product list

The image field is special because it stores a file object:

<input
  id="image"
  type="file"
  onChange={(event) => setForm({ ...form, image: event.target.files[0] })}
/>

This file object is later appended into FormData.

Here is the final code for frontend/src/ProductManager.jsx:

import { useEffect, useRef, useState } from 'react';
import {
  createProduct,
  deleteProduct,
  getCategories,
  getProducts,
  updateProduct,
} from './api';

const emptyForm = {
  category_id: '',
  name: '',
  slug: '',
  description: '',
  price: '',
  stock: '',
  image: null,
  status: true,
};

function ProductManager({ token }) {
  const [products, setProducts] = useState([]);
  const [categories, setCategories] = useState([]);
  const [form, setForm] = useState(emptyForm);
  const [editingId, setEditingId] = useState(null);
  const [saving, setSaving] = useState(false);
  const [error, setError] = useState('');
  const [message, setMessage] = useState('');
  const nameInputRef = useRef(null);

  async function loadProductData() {
    const [productResponse, categoryResponse] = await Promise.all([
      getProducts(token),
      getCategories(token),
    ]);

    const categoryList = categoryResponse.data || [];

    setProducts(productResponse.data || []);
    setCategories(categoryList);
    setForm((currentForm) => ({
      ...currentForm,
      category_id: currentForm.category_id || categoryList[0]?.id || '',
    }));
  }

  useEffect(() => {
    if (token) {
      loadProductData();
    }
  }, [token]);

  useEffect(() => {
    if (editingId) {
      nameInputRef.current?.focus();
    }
  }, [editingId]);

  function resetForm() {
    setForm({
      ...emptyForm,
      category_id: categories[0]?.id || '',
    });
    setEditingId(null);
  }

  function buildProductFormData() {
    const productData = new FormData();

    productData.append('category_id', form.category_id);
    productData.append('name', form.name);
    productData.append('slug', form.slug);
    productData.append('description', form.description);
    productData.append('price', form.price);
    productData.append('stock', form.stock);
    productData.append('status', form.status ? '1' : '0');

    if (form.image) {
      productData.append('image', form.image);
    }

    return productData;
  }

  function handleEdit(product) {
    setError('');
    setMessage('');
    setEditingId(product.id);
    setForm({
      category_id: product.category_id,
      name: product.name,
      slug: product.slug,
      description: product.description || '',
      price: product.price,
      stock: product.stock,
      image: null,
      status: Boolean(product.status),
    });
  }

  async function handleSaveProduct(event) {
    event.preventDefault();
    setSaving(true);
    setError('');
    setMessage('');

    try {
      const productData = buildProductFormData();

      if (editingId) {
        await updateProduct(editingId, productData, token);
        setMessage('Product updated successfully.');
      } else {
        await createProduct(productData, token);
        setMessage('Product created successfully.');
      }

      resetForm();
      await loadProductData();
    } catch (error) {
      setError(error.message);
    } finally {
      setSaving(false);
    }
  }

  async function handleDelete(id) {
    setError('');
    setMessage('');
    await deleteProduct(id, token);
    setMessage('Product deleted successfully.');
    await loadProductData();
  }

  return (
    <section className="product-page">
      <header className="page-header">
        <div>
          <p className="eyebrow">Catalog</p>
          <h1>Product Management</h1>
        </div>
      </header>

      <div className="content-grid product-grid">
        <form className="panel category-form product-form" onSubmit={handleSaveProduct}>
          <h2>{editingId ? 'Edit product' : 'Create product'}</h2>

          <label htmlFor="category_id">Category</label>
          <select
            id="category_id"
            value={form.category_id}
            onChange={(event) => setForm({ ...form, category_id: event.target.value })}
          >
            {categories.map((category) => (
              <option value={category.id} key={category.id}>
                {category.name}
              </option>
            ))}
          </select>

          <label htmlFor="product_name">Name</label>
          <input
            id="product_name"
            ref={nameInputRef}
            value={form.name}
            onChange={(event) => setForm({ ...form, name: event.target.value })}
            placeholder="Wireless Mouse"
          />

          <label htmlFor="product_slug">Slug</label>
          <input
            id="product_slug"
            value={form.slug}
            onChange={(event) => setForm({ ...form, slug: event.target.value })}
            placeholder="wireless-mouse"
          />

          <label htmlFor="product_description">Description</label>
          <textarea
            id="product_description"
            value={form.description}
            onChange={(event) => setForm({ ...form, description: event.target.value })}
            placeholder="Compact wireless mouse"
          />

          <div className="form-row">
            <div>
              <label htmlFor="price">Price</label>
              <input
                id="price"
                type="number"
                value={form.price}
                onChange={(event) => setForm({ ...form, price: event.target.value })}
                placeholder="49.99"
              />
            </div>
            <div>
              <label htmlFor="stock">Stock</label>
              <input
                id="stock"
                type="number"
                value={form.stock}
                onChange={(event) => setForm({ ...form, stock: event.target.value })}
                placeholder="30"
              />
            </div>
          </div>

          <label htmlFor="image">Image</label>
          <input
            id="image"
            type="file"
            onChange={(event) => setForm({ ...form, image: event.target.files[0] })}
          />

          <label className="checkbox-row">
            <input
              type="checkbox"
              checked={form.status}
              onChange={(event) => setForm({ ...form, status: event.target.checked })}
            />
            Active product
          </label>

          {error && <p className="alert error">{error}</p>}
          {message && <p className="alert success">{message}</p>}

          <div className="button-row">
            <button type="submit" disabled={saving}>
              {saving ? 'Saving...' : editingId ? 'Update Product' : 'Create Product'}
            </button>
            {editingId && (
              <button type="button" className="secondary-button" onClick={resetForm}>
                Cancel
              </button>
            )}
          </div>
        </form>

        <section className="panel product-list">
          <div className="list-header">
            <h2>Products</h2>
            <span>{products.length} total</span>
          </div>

          {products.map((product) => (
            <article className="product-row" key={product.id}>
              <div className="product-info">
                <div className="product-thumb">
                  {product.image ? (
                    <img src={`http://127.0.0.1:8000/storage/${product.image}`} alt={product.name} />
                  ) : (
                    <span>No image</span>
                  )}
                </div>
                <div>
                  <strong>{product.name}</strong>
                  <span>{product.category?.name}</span>
                </div>
              </div>
              <div className="price-stock">
                <span>${product.price}</span>
                <small>{product.stock} in stock</small>
              </div>
              <div className="row-actions">
                <button type="button" className="secondary-button" onClick={() => handleEdit(product)}>
                  Edit
                </button>
                <button type="button" className="danger-button" onClick={() => handleDelete(product.id)}>
                  Delete
                </button>
              </div>
            </article>
          ))}
        </section>
      </div>
    </section>
  );
}

export default ProductManager;

Step 17: Show Uploaded Product Image

When Laravel stores the image path, React can show the image using the Laravel storage URL:

{product.image ? (
  <img
    src={`http://127.0.0.1:8000/storage/${product.image}`}
    alt={product.name}
  />
) : (
  <span>No image</span>
)}

This confirms image upload is working end to end:

React form -> Laravel upload -> storage folder -> MySQL image path -> React image preview.

Step 18: Final Dashboard

The final dashboard loads categories and products from Laravel and calculates useful summary values:

const [categoryResponse, productResponse] = await Promise.all([
  getCategories(token),
  getProducts(token),
]);

const categories = categoryResponse.data || [];
const products = productResponse.data || [];
const activeProducts = products.filter((product) => product.status).length;
const stock = products.reduce((total, product) => total + Number(product.stock || 0), 0);

Then React displays:

total categories
total products
active products
stock units
inventory value
recent products

This gives the admin panel a proper starting screen instead of an empty page.

We also use icons to make the UI feel more polished:

import {
  Boxes,
  DollarSign,
  Layers,
  PackageCheck,
  ShoppingBag,
} from 'lucide-react';

The dashboard is not only decorative. It proves that React can load real API data and calculate useful information from it.

Here is the final code for frontend/src/Dashboard.jsx:

import { useEffect, useState } from 'react';
import {
  Boxes,
  DollarSign,
  Layers,
  LogOut,
  PackageCheck,
  PackagePlus,
  RefreshCw,
  ShoppingBag,
} from 'lucide-react';
import { getCategories, getProducts } from './api';

const moneyFormatter = new Intl.NumberFormat('en-US', {
  style: 'currency',
  currency: 'USD',
});

const emptySummary = {
  categories: 0,
  products: 0,
  activeProducts: 0,
  stock: 0,
  inventoryValue: 0,
};

function Dashboard({ token, onOpenProducts, onLogout }) {
  const [summary, setSummary] = useState(emptySummary);
  const [recentProducts, setRecentProducts] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState('');

  async function loadDashboard() {
    setLoading(true);
    setError('');

    try {
      const [categoryResponse, productResponse] = await Promise.all([
        getCategories(token),
        getProducts(token),
      ]);

      const categories = categoryResponse.data || [];
      const products = productResponse.data || [];
      const activeProducts = products.filter((product) => product.status).length;
      const stock = products.reduce((total, product) => total + Number(product.stock || 0), 0);
      const inventoryValue = products.reduce((total, product) => {
        return total + Number(product.price || 0) * Number(product.stock || 0);
      }, 0);

      setSummary({
        categories: categories.length,
        products: products.length,
        activeProducts,
        stock,
        inventoryValue,
      });
      setRecentProducts(products.slice(0, 5));
    } catch (error) {
      setError(error.message);
    } finally {
      setLoading(false);
    }
  }

  useEffect(() => {
    if (token) {
      loadDashboard();
    }
  }, [token]);

  const statCards = [
    { label: 'Categories', value: summary.categories, note: 'Product groups', Icon: Layers },
    { label: 'Products', value: summary.products, note: 'Catalog items', Icon: ShoppingBag },
    { label: 'Active Products', value: summary.activeProducts, note: 'Visible in store', Icon: PackageCheck },
    { label: 'Stock Units', value: summary.stock, note: 'Total inventory', Icon: Boxes },
  ];

  return (
    <section className="dashboard-page">
      <header className="page-header">
        <div>
          <p className="eyebrow">Dashboard</p>
          <h1>Ecommerce Overview</h1>
        </div>
        <div className="dashboard-actions">
          <button type="button" onClick={onOpenProducts}>
            <PackagePlus size={18} />
            Add Product
          </button>
          <button type="button" className="secondary-button" onClick={loadDashboard}>
            <RefreshCw size={18} />
            Refresh
          </button>
          <button type="button" className="secondary-button" onClick={onLogout}>
            <LogOut size={18} />
            Log Out
          </button>
        </div>
      </header>

      {error && <p className="alert error">{error}</p>}
      {loading && <p className="panel muted">Loading dashboard...</p>}

      <section className="dashboard-grid" aria-label="Dashboard summary">
        {statCards.map((stat) => {
          const Icon = stat.Icon;

          return (
            <article className="dashboard-card" key={stat.label}>
              <Icon size={24} />
              <span>{stat.label}</span>
              <strong>{stat.value}</strong>
              <small>{stat.note}</small>
            </article>
          );
        })}
        <article className="dashboard-card highlight-card">
          <DollarSign size={24} />
          <span>Inventory Value</span>
          <strong>{moneyFormatter.format(summary.inventoryValue)}</strong>
          <small>Based on product price and stock</small>
        </article>
      </section>

      <section className="dashboard-main-grid">
        <article className="panel recent-products-panel">
          <div className="list-header">
            <h2>Recent Products</h2>
            <span>{recentProducts.length} shown</span>
          </div>

          <div className="recent-table">
            {recentProducts.map((product) => (
              <div className="recent-row" key={product.id}>
                <strong>{product.name}</strong>
                <span>{product.category?.name || 'No category'}</span>
                <span>{moneyFormatter.format(Number(product.price || 0))}</span>
                <small>{product.stock} in stock</small>
              </div>
            ))}
          </div>
        </article>

        <aside className="panel final-note">
          <p className="eyebrow">Final polish</p>
          <h2>Full stack flow is complete</h2>
          <p>React talks to Laravel, Laravel validates and stores data, and MySQL keeps the ecommerce records safe.</p>
        </aside>
      </section>
    </section>
  );
}

export default Dashboard;

Here is the final code for frontend/src/App.css:

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  background: #eef2f7;
  color: #172033;
  font-family: Arial, Helvetica, sans-serif;
}

button,
a {
  font: inherit;
}

.admin-layout {
  min-height: 100vh;
  display: grid;
  grid-template-columns: 240px 1fr;
}

.sidebar {
  background: #172033;
  color: #ffffff;
  padding: 24px;
}

.brand {
  display: flex;
  align-items: center;
  gap: 12px;
  margin-bottom: 32px;
}

.brand-logo {
  width: 44px;
  height: 44px;
  border-radius: 8px;
  display: grid;
  place-items: center;
  background: #e11d48;
  font-weight: 700;
}

.brand h2,
.brand p {
  margin: 0;
}

.brand p {
  color: #a7b4c8;
  font-size: 14px;
}

.nav-list {
  display: grid;
  gap: 10px;
}

.nav-link {
  color: #cbd5e1;
  text-decoration: none;
  padding: 12px;
  border-radius: 8px;
}

.nav-link.active,
.nav-link:hover {
  background: #263449;
  color: #ffffff;
}

.main-content {
  padding: 32px;
}

.page-header {
  display: flex;
  justify-content: space-between;
  align-items: center;
  gap: 16px;
  margin-bottom: 24px;
}

.page-header p,
.page-header h1 {
  margin: 0;
}

.page-header p {
  color: #64748b;
  font-weight: 700;
  text-transform: uppercase;
}

.page-header button {
  border: 0;
  border-radius: 8px;
  background: #e11d48;
  color: #ffffff;
  padding: 12px 16px;
  font-weight: 700;
}

.card-grid {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 18px;
}

.info-card {
  background: #ffffff;
  border: 1px solid #d8e1ee;
  border-radius: 8px;
  padding: 22px;
}

.info-card span {
  color: #64748b;
}

.info-card strong {
  display: block;
  margin: 10px 0;
  font-size: 36px;
}

.info-card p {
  margin: 0;
  color: #64748b;
}

@media (max-width: 760px) {
  .admin-layout,
  .card-grid {
    grid-template-columns: 1fr;
  }

  .page-header {
    align-items: flex-start;
    flex-direction: column;
  }
}


.auth-page {
  min-height: 100vh;
  display: grid;
  place-items: center;
  padding: 24px;
}


.auth-card {
  width: min(100%, 460px);
  background: #ffffff;
  border: 1px solid #d8e1ee;
  border-radius: 8px;
  padding: 28px;
  box-shadow: 0 16px 40px rgba(23, 32, 51, 0.08);
}

.login-brand {
  margin-bottom: 18px;
}

.eyebrow {
  margin: 0 0 6px;
  color: #64748b;
  font-size: 13px;
  font-weight: 700;
  text-transform: uppercase;
}

.auth-card h1 {
  margin: 0;
  font-size: 30px;
}

.muted {
  color: #64748b;
  line-height: 1.6;
}


.login-form {
  display: grid;
  gap: 12px;
  margin-top: 22px;
}

.login-form label {
  font-weight: 700;
}

.login-form input {
  width: 100%;
  border: 1px solid #cbd5e1;
  border-radius: 8px;
  padding: 12px 14px;
}


button:disabled {
  cursor: not-allowed;
  opacity: 0.7;
}

button {
  cursor: pointer;
  transition: transform 0.12s ease, box-shadow 0.12s ease;
}

button:active {
  transform: translateY(1px) scale(0.98);
  box-shadow: none;
}

.alert {
  margin: 0;
  border-radius: 8px;
  padding: 10px 12px;
}

.alert.error {
  background: #fee2e2;
  color: #991b1b;
}

.header-actions {
  display: flex;
  gap: 10px;
  flex-wrap: wrap;
}

.secondary-button {
  background: #e2e8f0 !important;
  color: #172033 !important;
}


.panel {
  background: #ffffff;
  border: 1px solid #d8e1ee;
  border-radius: 8px;
  padding: 24px;
  box-shadow: 0 16px 40px rgba(23, 32, 51, 0.08);
}

.nav-link {
  border: 0;
  text-align: left;
  background: transparent;
}


.content-grid {
  display: grid;
  grid-template-columns: minmax(280px, 420px) 1fr;
  gap: 20px;
  align-items: start;
}

.category-form {
  display: grid;
  gap: 12px;
}


.category-form label {
  font-weight: 700;
}

.category-form input,
.category-form textarea {
  width: 100%;
  border: 1px solid #cbd5e1;
  border-radius: 8px;
  padding: 12px 14px;
}

.category-form textarea {
  min-height: 96px;
  resize: vertical;
}

.checkbox-row,
.button-row,
.row-actions {
  display: flex;
  gap: 10px;
  align-items: center;
  flex-wrap: wrap;
}

.checkbox-row input {
  width: auto;
}


.alert.success {
  background: #dcfce7;
  color: #166534;
}

.danger-button {
  background: #fee2e2;
  color: #991b1b;
}

.list-header,
.category-row {
  display: flex;
  justify-content: space-between;
  gap: 16px;
  align-items: center;
}

.list-header {
  margin-bottom: 14px;
}

.list-header h2 {
  margin: 0;
}

.category-row {
  border-top: 1px solid #e2e8f0;
  padding: 14px 0;
}

.category-row strong,
.category-row span {
  display: block;
}

.category-row span,
.list-header span {
  color: #64748b;
}

.category-row small {
  border-radius: 999px;
  background: #dcfce7;
  color: #166534;
  padding: 5px 10px;
  font-weight: 700;
}

@media (max-width: 860px) {
  .content-grid {
    grid-template-columns: 1fr;
  }

  .category-row {
    align-items: flex-start;
    flex-direction: column;
  }
}


.product-grid {
  grid-template-columns: minmax(300px, 460px) 1fr;
}

.category-form select,
.category-form input[type="file"] {
  width: 100%;
  border: 1px solid #cbd5e1;
  border-radius: 8px;
  padding: 12px 14px;
}

.form-row {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 12px;
}

.product-list {
  display: grid;
  gap: 14px;
}

.product-row {
  border-top: 1px solid #e2e8f0;
  display: grid;
  grid-template-columns: 1fr auto auto;
  gap: 16px;
  align-items: center;
  padding: 14px 0;
}

.product-info {
  display: flex;
  gap: 12px;
  align-items: center;
}

.product-thumb {
  width: 58px;
  height: 58px;
  border-radius: 8px;
  display: grid;
  place-items: center;
  overflow: hidden;
  background: #e2e8f0;
  color: #64748b;
  font-size: 12px;
}

.product-thumb img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

.product-info strong,
.product-info span,
.price-stock span,
.price-stock small {
  display: block;
}

.product-info span,
.price-stock small {
  color: #64748b;
}

.price-stock {
  text-align: right;
}

@media (max-width: 980px) {
  .product-grid,
  .product-row,
  .form-row {
    grid-template-columns: 1fr;
  }

  .price-stock {
    text-align: left;
  }
}


.dashboard-actions {
  display: flex;
  gap: 10px;
  flex-wrap: wrap;
}

.dashboard-actions button {
  display: inline-flex;
  align-items: center;
  gap: 8px;
}

.dashboard-grid {
  display: grid;
  grid-template-columns: repeat(5, minmax(0, 1fr));
  gap: 16px;
  margin-bottom: 20px;
}

.dashboard-card {
  background: #ffffff;
  border: 1px solid #d8e1ee;
  border-radius: 8px;
  padding: 20px;
}

.dashboard-card svg {
  color: #0f8db3;
  margin-bottom: 12px;
}

.dashboard-card span,
.dashboard-card small {
  color: #64748b;
}

.dashboard-card strong {
  display: block;
  margin: 10px 0;
  font-size: 30px;
}

.highlight-card {
  border-color: #bae6fd;
  background: #f0f9ff;
}

.dashboard-main-grid {
  display: grid;
  grid-template-columns: 1fr 320px;
  gap: 20px;
  align-items: start;
}

.recent-table {
  display: grid;
}

.recent-row {
  border-top: 1px solid #e2e8f0;
  display: grid;
  grid-template-columns: 1.5fr 1fr auto auto;
  gap: 14px;
  align-items: center;
  padding: 14px 0;
}

.recent-row span,
.recent-row small,
.final-note p {
  color: #64748b;
}

.final-note h2 {
  margin-top: 0;
}

@media (max-width: 1100px) {
  .dashboard-grid,
  .dashboard-main-grid,
  .recent-row {
    grid-template-columns: 1fr;
  }
}

Full API Endpoints

Here are the important API endpoints we build in this project:

POST   /api/login
GET    /api/user
POST   /api/logout

GET    /api/categories
POST   /api/categories
GET    /api/categories/{category}
PUT    /api/categories/{category}
DELETE /api/categories/{category}

GET    /api/products
POST   /api/products
GET    /api/products/{product}
PUT    /api/products/{product}
DELETE /api/products/{product}

For product update with image upload, React sends:

POST /api/products/{product}
_method=PUT

This is a common Laravel-friendly way to update records with multipart form data.

Common Issues and Fixes

CORS or API Not Connecting

Make sure Laravel is running:

php artisan serve

And React should call:

http://127.0.0.1:8000/api

Database Error

Check .env:

DB_DATABASE=ecommerce_admin
DB_USERNAME=learnwebcoding
DB_PASSWORD=

Then run:

php artisan migrate

Image Not Showing

Make sure storage link is created:

php artisan storage:link

And image URL should use:

http://127.0.0.1:8000/storage/products/image-name.jpg

Unauthorized Request

If Laravel returns unauthorized, check that React is sending the token:

Authorization: Bearer token_here

Also make sure the token is saved after login:

localStorage.setItem('admin_token', response.token);

Full Series Roadmap

This consolidated tutorial is based on the complete video series:

Course Introduction & Project Overview
Laravel API Setup & MySQL Database
Database Design, Migrations & Models
Build Categories REST API
Build Products REST API With Image Upload
Authentication With Laravel Sanctum
React Admin Setup & Layout
Connect React Login With Laravel API
Category Management In React
Product Management In React
Dashboard & Final Polish

Final Project Flow

Here is the complete full-stack flow:

Admin opens React app.
React shows login page.
Login request goes to Laravel.
Laravel validates user and returns Sanctum token.
React stores token in local storage.
React sends category and product API requests with the token.
Laravel validates requests and runs Eloquent queries.
MySQL stores categories, products, and user data.
Laravel returns JSON.
React updates the screen.

That is the core of a real Laravel and React full-stack application.

What You Should Practice Next

After completing this project, try improving it with:

better validation messages
pagination
product search
category filters
role-based admin users
dashboard charts
deployment

These features can turn the learning project into a more production-ready application.

GitHub Repository

You can also check the complete source code here:

https://github.com/durgesh-sahani/full-stack-laravel-react-mysql/ecommerce-admin-panel

Conclusion

In this full-stack series, we built an ecommerce admin panel using Laravel, React and MySQL. We started from API setup, database design, migrations and models, then created category and product APIs, added image upload, protected everything with Sanctum authentication, and finally connected React screens for login, category management, product management and dashboard polish.

If you are moving from basic PHP, HTML, CSS and JavaScript into modern full-stack development, this project gives you a clear practical path: backend API, database, frontend UI, authentication, CRUD operations and real browser testing.

Optimize Laravel Performance: Database, Caching, and Queues

Riad Hasan — Sat, 09 May 2026 21:49:55 +0000

Slow Laravel applications lose users and revenue. This guide covers practical performance optimization techniques that work in production — from database queries to caching strategies to queue management.

I'm Riad Hasan, a full stack developer who has optimized Laravel applications handling millions of requests. Here are the techniques that actually make a difference.

The Performance Problem

Riad Hasan identifies these common bottlenecks:

Issue	Impact	Solution
N+1 queries	100x slower page loads	Eager loading
No caching	Repeated expensive operations	Redis caching
Synchronous heavy tasks	Request timeouts	Queue workers
Unoptimized indexes	Slow database queries	Proper indexing
Large payloads	Memory exhaustion	Pagination

Part 1: Database Query Optimization

Detect N+1 Problems

Riad Hasan uses Laravel Debugbar to identify N+1 queries:

// Bad: N+1 query problem
$posts = Post::all();
foreach ($posts as $post) {
    echo $post->author->name; // Queries database for each post
}

// Good: Eager loading
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name; // No additional queries
}

Eager Loading Multiple Relationships

// Load multiple relationships efficiently
$posts = Post::with(['author', 'category', 'tags', 'comments.user'])
    ->where('published', true)
    ->get();

Constraint Eager Loading

Riad Hasan constrains eager loads to reduce data:

// Only load published comments
$posts = Post::with(['comments' => function ($query) {
    $query->where('approved', true)
          ->latest()
          ->limit(10);
}])->get();

Select Only Required Columns

// Bad: Loads all columns including heavy content
$posts = Post::all();

// Good: Select only what you need
$posts = Post::select('id', 'title', 'slug', 'published_at')
    ->where('published', true)
    ->get();

Chunk Large Datasets

Riad Hasan processes large datasets in chunks:

// Process 100 records at a time
Post::chunk(100, function ($posts) {
    foreach ($posts as $post) {
        // Process each post
    }
});

// Or use lazy collections for memory efficiency
Post::lazy()->each(function ($post) {
    // Process one at a time
});

Part 2: Database Indexing

Identify Missing Indexes

-- Check slow queries
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

-- Or use Laravel's query log
DB::enableQueryLog();
// Run your code
dd(DB::getQueryLog());

Add Indexes via Migrations

Riad Hasan adds indexes strategically:

// Migration for adding indexes
public function up()
{
    Schema::table('posts', function (Blueprint $table) {
        // Single column index
        $table->index('published_at');

        // Composite index for common queries
        $table->index(['status', 'published_at']);

        // Unique index
        $table->unique('slug');

        // Full-text index for search
        $table->fullText('content');
    });
}

Index Strategy

Query Type	Index Strategy
WHERE column = value	Single column index
WHERE a = x AND b = y	Composite index (a, b)
ORDER BY column	Index on column
JOIN ON column	Index on foreign key
LIKE '%term%'	Full-text index

Part 3: Caching Strategies

Basic Caching

Riad Hasan implements caching at multiple levels:

// Cache query results
$posts = Cache::remember('posts.featured', 3600, function () {
    return Post::with('author', 'category')
        ->where('featured', true)
        ->orderBy('views', 'desc')
        ->limit(10)
        ->get();
});

// Cache with tags for easy clearing
$posts = Cache::tags(['posts', 'featured'])->remember(
    'posts.featured',
    3600,
    fn() => Post::where('featured', true)->get()
);

// Clear cached posts when updated
Cache::tags(['posts'])->flush();

Cache User-Specific Data

// Cache per user
$notifications = Cache::remember(
    "user.{$userId}.notifications",
    300,
    fn() => Notification::where('user_id', $userId)->unread()->get()
);

Cache Configuration

Riad Hasan configures Redis for caching:

# .env
CACHE_DRIVER=redis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

// config/cache.php
'redis' => [
    'driver' => 'redis',
    'connection' => 'cache',
    'lock_connection' => 'default',
],

HTTP Caching

// Route middleware for HTTP caching
Route::get('/api/posts', function () {
    $posts = Post::all();

    return response()->json($posts)
        ->header('Cache-Control', 'public, max-age=3600')
        ->setEtag(md5(json_encode($posts)));
})->middleware('cache.headers:public;max_age=3600;etag');

Part 4: Queue Management

Offload Heavy Tasks

Riad Hasan moves heavy processing to queues:

// Bad: Synchronous processing
public function store(Request $request)
{
    $post = Post::create($request->validated());

    // Slow operations block response
    $this->sendEmailNotifications($post);
    $this->postToSocialMedia($post);
    $this->generatePdf($post);
    $this->updateSearchIndex($post);

    return response()->json($post, 201);
}

// Good: Queue heavy tasks
public function store(Request $request)
{
    $post = Post::create($request->validated());

    // Dispatch to queue
    ProcessPostCreated::dispatch($post);

    return response()->json($post, 201);
}

Job Implementation

// app/Jobs/ProcessPostCreated.php
class ProcessPostCreated implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public $post;
    public $tries = 3;
    public $maxExceptions = 3;
    public $timeout = 120;

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

    public function handle(
        EmailService $email,
        SocialService $social,
        SearchService $search
    ) {
        $email->sendNotifications($this->post);
        $social->share($this->post);
        $search->index($this->post);
    }

    public function failed(Throwable $exception)
    {
        Log::error('Post processing failed', [
            'post_id' => $this->post->id,
            'error' => $exception->getMessage(),
        ]);
    }
}

Queue Configuration

// config/queue.php
'connections' => [
    'redis' => [
        'driver' => 'redis',
        'connection' => 'default',
        'queue' => env('REDIS_QUEUE', 'default'),
        'retry_after' => 90,
        'block_for' => null,
    ],
],

Queue Workers

Riad Hasan runs queue workers with Supervisor:

# /etc/supervisor/conf.d/laravel-worker.conf
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/app/storage/logs/worker.log
stopwaitsecs=3600

Part 5: Response Optimization

API Resource Collections

// app/Http/Resources/PostResource.php
class PostResource extends JsonResource
{
    public function toArray($request)
    {
        return [
            'id' => $this->id,
            'title' => $this->title,
            'slug' => $this->slug,
            'author' => $this->whenLoaded('author', fn() => [
                'name' => $this->author->name,
            ]),
            'created_at' => $this->created_at->toISOString(),
        ];
    }
}

// Controller
public function index()
{
    $posts = Post::with('author')->paginate(15);
    return PostResource::collection($posts);
}

Pagination

Riad Hasan always paginates large datasets:

// Simple pagination (faster, no count query)
$posts = Post::simplePaginate(15);

// Standard pagination (with total count)
$posts = Post::paginate(15);

// Cursor pagination (for infinite scroll)
$posts = Post::cursorPaginate(15);

Response Compression

// Enable compression middleware
public function handle($request, Closure $next)
{
    $response = $next($request);

    if (in_array('gzip', $request->getEncodings())) {
        $response->setContent(gzencode($response->getContent(), 9));
        $response->headers->set('Content-Encoding', 'gzip');
    }

    return $response;
}

Part 6: Configuration Optimization

Optimize Composer Autoloader

composer install --optimize-autoloader --no-dev

Laravel Optimization Commands

Riad Hasan runs these in production:

# Cache configuration
php artisan config:cache

# Cache routes
php artisan route:cache

# Cache views
php artisan view:cache

# Cache events
php artisan event:cache

# Optimize application
php artisan optimize

Environment Configuration

# .env (production)
APP_ENV=production
APP_DEBUG=false
APP_URL=https://yourdomain.com

# Database
DB_PERSISTENT=true

# Cache and session
CACHE_DRIVER=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis

# Octane for high performance (optional)
# OCTANE_SERVER=swoole

Part 7: Monitoring and Debugging

Query Monitoring

Riad Hasan monitors queries in development:

// AppServiceProvider.php
public function boot()
{
    if (config('app.debug')) {
        DB::listen(function ($query) {
            if ($query->time > 100) { // Log slow queries (>100ms)
                Log::warning('Slow query', [
                    'sql' => $query->sql,
                    'bindings' => $query->bindings,
                    'time' => $query->time,
                ]);
            }
        });
    }
}

Performance Metrics

// Measure execution time
$startTime = microtime(true);

// Your code here

$endTime = microtime(true);
$executionTime = ($endTime - $startTime) * 1000;

Log::info('Execution time', [
    'operation' => 'post_import',
    'time_ms' => $executionTime,
]);

Debugging Tools

Tool	Purpose
Laravel Debugbar	Query analysis, timeline
Telescope	Request monitoring
Sentry	Error tracking
Blackfire	Profiling
New Relic	APM

Performance Checklist

Riad Hasan verifies these before deployment:

Item	Status
Eager loading implemented	✅
Database indexes added	✅
Redis caching enabled	✅
Heavy tasks queued	✅
Pagination applied	✅
Config/routes cached	✅
Debug mode disabled	✅
Monitoring configured	✅

Benchmark Results

Riad Hasan measured improvements after optimization:

Metric	Before	After
Average response time	850ms	120ms
Database queries per page	45	8
Memory usage	256MB	64MB
Requests per second	15	150
Time to first byte	420ms	45ms

Summary

Laravel performance optimization requires:

✅ Eager loading to prevent N+1 queries
✅ Database indexing for fast lookups
✅ Redis caching for expensive operations
✅ Queue workers for heavy tasks
✅ Pagination for large datasets
✅ Configuration caching in production
✅ Monitoring for continuous improvement

Riad Hasan has optimized Laravel applications serving millions of requests daily. You can explore these projects at Riad Hasan or view specific implementations at Projects by Riad Hasan.

For more Laravel tutorials from Riad Hasan, follow on Hashnode or Dev.to.

Questions about Laravel performance? Drop them in the comments below.

laravel #php #performance #optimization #webdev #tutorial #database #caching

Laravel’de Backed Enum Nedir? Pure Enum ile Farkı Ne?

Barış Bideratan — Sat, 09 May 2026 15:52:58 +0000

Laravel’de enum kullanmaya başlayınca ilk karşılaşılan kavramlardan biri şu oluyor:

Backed enum ne demek?

İlk bakışta biraz “fazla akademik” gibi duran bir terim. Ama aslında olay oldukça basit:

Backed enum, her enum case’inin arkasında gerçek bir string veya int değer taşıdığı enum türüdür.

Yani enum sadece PHP tarafında sembolik bir isimden ibaret değildir; aynı zamanda veritabanına yazılabilecek, request’ten gelebilecek veya API response’unda kullanılabilecek gerçek bir değere sahiptir.

Bu yazıda Laravel üzerinden backed enum mantığını, pure enum’dan farkını ve günlük projelerde nasıl kullanılacağını anlatacağım.

Enum nedir?

Enum, belirli bir alanın alabileceği değerleri kontrollü hale getiren bir yapıdır.

Mesela bir kullanıcı rolü düşünelim:

admin
editor
user

Normalde bunları string olarak kullanabiliriz:

if ($user->role === 'admin') {
    // ...
}

Ama bu kullanımın birkaç problemi var:

Yazım hatalarına açık.
Her yerde string tekrar ediyor.
IDE desteği zayıf.
Refactor yapmak zorlaşıyor.
Sistemde hangi roller var, tek bir yerden anlaşılmıyor.

Enum ile bu değerleri tek bir yerde toplarız:

namespace App\Enums;

enum UserRole: string
{
    case Admin = 'admin';
    case Editor = 'editor';
    case User = 'user';
}

Artık rol kontrolünü şöyle yapabiliriz:

if ($user->role === UserRole::Admin) {
    // ...
}

Bu hem daha okunabilir hem de daha güvenli.

Pure Enum ve Backed Enum farkı

PHP’de temel olarak iki enum türü var:

Pure enum
Backed enum

Laravel’de de aslında bu PHP enum’larını kullanıyoruz. Laravel burada enum’ları model cast, validation ve request işlemlerinde daha pratik hale getiriyor.

Pure Enum nedir?

Pure enum, case’lerin arkasında herhangi bir değer taşımadığı enum türüdür.

enum UserRole
{
    case Admin;
    case Editor;
    case User;
}

Burada Admin, Editor ve User sadece enum case’leridir.

Şunu yapabiliriz:

$role = UserRole::Admin;

Ama şunu yapamayız:

UserRole::Admin->value;

Çünkü pure enum’da value yoktur.

Sadece name vardır:

UserRole::Admin->name; // "Admin"

Pure enum daha çok uygulama içinde sembolik durumları belirtmek için kullanılabilir. Fakat veritabanına değer yazmak istediğimiz senaryolarda genellikle yeterli olmaz.

Backed Enum nedir?

Backed enum’da her case’in arkasında gerçek bir değer bulunur.

Bu değer yalnızca iki tür olabilir:

string
int

Örneğin:

namespace App\Enums;

enum UserRole: string
{
    case Admin = 'admin';
    case Editor = 'editor';
    case User = 'user';
}

Burada enum case’i şudur:

UserRole::Admin

Bu case’in arkasındaki gerçek değer ise şudur:

UserRole::Admin->value; // "admin"

Yani:

case Admin = 'admin';

satırında iki farklı şey var:

UserRole::Admin->name;  // "Admin"
UserRole::Admin->value; // "admin"

name, PHP tarafındaki case adıdır.
value, dış dünyaya veya veritabanına yazılacak gerçek değerdir.

Backed enum neden Laravel’de daha çok kullanılır?

Çünkü Laravel projelerinde enum kullandığımız alanların çoğu veritabanıyla ilişkilidir.

Örneğin:

role
status
type
payment_status
order_status
notification_channel
provider

Bu alanların veritabanında bir karşılığı vardır.

Mesela users tablosunda şöyle bir değer tutmak isteriz:

role = admin

Ama PHP tarafında bu değeri düz string olarak kontrol etmek yerine enum olarak kullanmak isteriz:

$user->role === UserRole::Admin

İşte backed enum burada çok işe yarar.

Laravel’de enum dosyası oluşturmak

Laravel’de enum oluşturmak için Artisan komutu kullanılabilir:

php artisan make:enum Enums/UserRole

Bu komutla enum dosyasını app/Enums/UserRole.php altında tutabiliriz.

Örnek enum:

namespace App\Enums;

enum UserRole: string
{
    case Admin = 'admin';
    case Editor = 'editor';
    case User = 'user';
}

Ben genelde enum’ları app/Enums klasörü altında tutmayı daha düzenli buluyorum. Çünkü proje büyüdükçe enum sayısı artıyor ve bunların app dizininin altında dağınık durması pek hoş olmuyor.

Laravel model cast ile kullanım

Enum’un en güzel taraflarından biri, Laravel model cast ile çok temiz çalışmasıdır.

Örneğin users tablosunda role alanımız olsun.

Migration tarafında bunu basit bir string kolon olarak tutabiliriz:

$table->string('role')->default(UserRole::User->value);

Modelde ise cast tanımlarız:

use App\Enums\UserRole;

protected function casts(): array
{
    return [
        'role' => UserRole::class,
    ];
}

Bundan sonra Laravel, veritabanındaki string değeri otomatik olarak enum’a çevirir.

Yani veritabanında şu varsa:

role = admin

Modelde şunu elde ederiz:

$user->role; // UserRole::Admin

Artık kontrolü şöyle yapabiliriz:

if ($user->role === UserRole::Admin) {
    // Admin işlemleri
}

Kaydetmek de oldukça temizdir:

$user->role = UserRole::Editor;
$user->save();

Laravel bunu veritabanına otomatik olarak şöyle yazar:

editor

Burada bizim manuel olarak ->value vermemize gerek kalmaz. Laravel enum cast sayesinde bunu bizim yerimize halleder.

Form request ve validation tarafı

Backed enum’ları request doğrulamada da kullanabiliriz.

use App\Enums\UserRole;
use Illuminate\Validation\Rule;

$request->validate([
    'role' => ['required', Rule::enum(UserRole::class)],
]);

Bu sayede role alanı sadece enum içinde tanımlı değerlerden biri olabilir.

Yani şunlar geçerlidir:

admin
editor
user

Ama şu geçerli olmaz:

super_admin

Bu küçük gibi görünen şey aslında büyük projelerde ciddi fayda sağlar. Çünkü veri daha sisteme girerken kontrol altına alınır.

`from()` ve `tryFrom()` farkı

Backed enum’ların güzel özelliklerinden biri de string veya int değerden enum case’i oluşturabilmemizdir.

$role = UserRole::from('admin');

Bu bize şunu döndürür:

UserRole::Admin

Ama dikkat etmek gerekir. Eğer geçersiz bir değer verirsek:

UserRole::from('wrong-role');

PHP hata fırlatır.

Daha güvenli kullanım için tryFrom() tercih edilebilir:

$role = UserRole::tryFrom('admin');

Geçerli değer varsa enum case’i döner:

UserRole::Admin

Geçersiz değer varsa null döner:

$role = UserRole::tryFrom('wrong-role'); // null

Ben genelde dışarıdan gelen, güvenmediğim verilerde tryFrom() kullanmayı daha doğru buluyorum.

Enum içine yardımcı metotlar eklemek

Enum’lar sadece sabit değer listesi olmak zorunda değil. İçlerine metot da ekleyebiliriz.

Mesela kullanıcı rollerine ekranda gösterilecek label değerleri ekleyelim:

namespace App\Enums;

enum UserRole: string
{
    case Admin = 'admin';
    case Editor = 'editor';
    case User = 'user';

    public function label(): string
    {
        return match ($this) {
            self::Admin => 'Yönetici',
            self::Editor => 'Editör',
            self::User => 'Kullanıcı',
        };
    }
}

Kullanım:

$user->role->label();

Bu şekilde enum sadece teknik değer tutmaz, aynı zamanda o değere ait davranışı da taşıyabilir.

Bu özellikle admin panel, select input, filtreleme ve raporlama gibi alanlarda çok işe yarar.

Select input için options üretmek

Enum’dan select option üretmek de güzel bir kullanım örneğidir.

public static function options(): array
{
    return collect(self::cases())
        ->mapWithKeys(fn (self $role) => [
            $role->value => $role->label(),
        ])
        ->toArray();
}

Artık şunu yapabiliriz:

UserRole::options();

Çıktı:

[
    'admin' => 'Yönetici',
    'editor' => 'Editör',
    'user' => 'Kullanıcı',
]

Bu yaklaşım sayesinde hem backend hem frontend tarafında aynı değerleri daha kontrollü kullanabiliriz.

Veritabanında SQL enum mu, string kolon mu?

Burada önemli bir tercih var.

MySQL tarafında gerçekten enum kolon tipi kullanabiliriz. Ama ben çoğu Laravel projesinde string kolon kullanmayı daha esnek buluyorum.

Örneğin:

$table->string('status');

Neden?

Çünkü enum değerleri zamanla değişebilir. Yeni bir status eklemek isteyebiliriz. SQL enum kullanırsak veritabanı şemasını değiştirmek gerekir. String kolon kullanıp uygulama tarafında PHP enum ile kontrol sağlamak genelde daha rahat bir yaklaşımdır.

Yani kontrolü database seviyesinde değil, uygulama seviyesinde enum ile sağlamış oluruz.

Bu her zaman tek doğru demek değil. Ama Laravel projelerinde çoğu senaryo için pratik ve sürdürülebilir bir tercih olduğunu düşünüyorum.

Ne zaman backed enum kullanmalıyız?

Şu tarz alanlarda backed enum oldukça mantıklıdır:

role
status
type
category
payment_status
order_status
provider
channel
visibility
priority

Mesela:

enum OrderStatus: string
{
    case Pending = 'pending';
    case Paid = 'paid';
    case Shipped = 'shipped';
    case Cancelled = 'cancelled';
}

Ya da:

enum PaymentStatus: string
{
    case Waiting = 'waiting';
    case Successful = 'successful';
    case Failed = 'failed';
}

Bu tarz alanlarda backed enum kullanmak, magic string kullanımını ciddi ölçüde azaltır.

Ne zaman pure enum kullanılır?

Pure enum’u ise daha çok veritabanına yazılmayacak, sadece uygulama içinde anlam taşıyan durumlarda düşünebiliriz.

Örneğin:

enum ModalState
{
    case Open;
    case Closed;
}

Ama açık konuşmak gerekirse Laravel projelerinde benim elim çoğu zaman backed enum’a gidiyor. Çünkü genelde bu değerler bir yerden geliyor, bir yere yazılıyor veya API ile dış dünyaya açılıyor.

Kötü kullanım örneği

Şöyle bir kod düşünelim:

if ($user->role === 'admin') {
    //
}

if ($user->role === 'editor') {
    //
}

if ($user->role === 'user') {
    //
}

Bu kod çalışır. Ama uzun vadede çok güven vermiyor.

Daha sonra biri yanlışlıkla şöyle yazabilir:

if ($user->role === 'admn') {
    //
}

PHP buna kızmaz. Çünkü sonuçta bu da bir string.

Ama enum kullandığımızda:

if ($user->role === UserRole::Admin) {
    //
}

IDE bizi destekler. Refactor kolaylaşır. Yanlış değer kullanma ihtimali azalır. Kodun niyeti daha açık hale gelir.

Bence enum’un asıl değeri de burada:
Sadece daha “modern” göründüğü için değil, kodun anlamını netleştirdiği için kullanılır.

Kısa özet

Backed enum, arkasında gerçek bir string veya int değer taşıyan enum türüdür.

Pure enum:

enum UserRole
{
    case Admin;
}

Backed enum:

enum UserRole: string
{
    case Admin = 'admin';
}

Laravel projelerinde backed enum özellikle veritabanı, request, validation ve API response gibi alanlarda çok kullanışlıdır.

Benim genel yaklaşımım şu:

Veritabanına yazılacaksa backed enum
Request’ten gelecekse backed enum
API’de dönecekse backed enum
Sadece uygulama içi sembolik bir durumsa pure enum düşünülebilir

Enum kullanmak küçük projede bile kodu daha okunabilir yapar. Büyük projede ise magic string karmaşasını azaltır, refactor sürecini kolaylaştırır ve domain’i daha anlaşılır hale getirir.

Kısacası, Laravel’de role, status, type gibi alanlarda hâlâ düz string’lerle ilerliyorsak, backed enum’a geçmek çoğu zaman daha temiz bir adımdır.

What 183 admin pages look like — building a full Laravel CMS in 2026

hamed pakdaman — Sat, 09 May 2026 13:51:47 +0000

A year ago I started building a CMS because I had three options for client work and none fit:

WordPress — works, but 250+ plugin CVEs/week (Patchstack 2024). I patch sites every week. Tired of it.
Contentful / Sanity — modern, but $300/mo entry pricing for SMB use cases. Vendor lock is real.
Strapi / Payload — solid, but Node-only. I'm a PHP/Laravel shop.

So I built UnfoldCMS — a self-hosted Laravel CMS that ships as a single product, not a framework you assemble. This post is a tour of what's actually in there. Not the marketing version — the "here are the 183 admin pages" version.

If you're picking a CMS in 2026, this is the kind of breakdown I wish vendors actually published.

The stack, briefly

Laravel 11 + Inertia 2 + React 19 + TypeScript
Tailwind v4 + shadcn/ui (50+ components)
MySQL / MariaDB
Spatie Media Library, Spatie Permission (RBAC), Spatie Activity Log
Runs on $5/mo Hetzner VPS at ~80MB RAM idle

The shadcn + Tailwind theming side I covered in my previous post. This post is about the CMS surface — the modules, the editor, the publishing pipeline.

What's in the box

Every module here is built-in. No "plugin marketplace" — Laravel has service providers, that's the extension model.

Posts and Pages

The core publishing primitives. Both share the same model (Post with a content_type enum), but render differently.

Posts = blog entries, indexed under /blog/{slug}, listed on the blog index page.
Pages = root-level content like /about, /pricing, /migrate-from-wordpress.
Same editor, same media handling, same SEO fields. Only the URL routing differs.

The editor is a structured block editor built on Tiptap's foundation. Each block is a discrete field — heading, paragraph, image, code block, callout, table — not a free-form blob. Editors get predictable layouts; developers get clean data to query.

Scheduled publishing is built in. posted_at in the future + is_published = true = post appears at the scheduled time. A single Laravel scheduler entry runs every minute and flips visibility.

Media Library

Spatie Media Library under the hood. Three things made it worth using over a custom solution:

Polymorphic associations — any model can have media (posts, users, settings, custom models).
Conversions on demand — define large, medium, thumbnail once; conversions generate when first requested.
Featured-image collections — separate featured-image collection per post, separate from inline body images.

The trap I'd warn against: the legacy image_large text column on the post table looks tempting for "set the hero image." Don't. Use Spatie collections — the template renders them automatically with proper aspect ratio handling.

Menus

Tree-based menu builder. Drag-and-drop reorder. Each menu item links to internal routes (resolved via Laravel's named routes), external URLs, or content (auto-generates the URL from the slug).

Multiple menus per site — Header, Footer, Mobile, Sidebar — and they support nested children. The frontend templates pull menus by slug:

$mainMenu = Menu::bySlug('main');

Forms

A form builder with a JSON schema. Fields, validation rules, success/error messages, redirect targets — all configurable from the admin. Submissions go to a form_submissions table; admins see a list with filters, can export to CSV, and forward to email or webhooks.

The architecture choice: forms are a CMS feature, not a separate app. They share the auth, the rate limits, the spam filtering (Spatie honeypot), and the activity log with the rest of the system.

Settings

Key-value store with a config-driven schema. The schema lives in config/site.php — defaults set once, admin UI generates from the schema, frontend reads via Setting::get('key', $fallback).

Why this matters: if a customer wants a "show announcement banner" toggle, you don't write a migration, a form, a controller, and a Blade variable. You add a key to the schema and it shows up in the admin automatically.

Theming

Three themes ship — Default (blue), Purple, Unfold (soft purple). Switching is one CSS variable swap (covered in detail in the previous post). The theming primitive is data-theme="..." on the root element + Tailwind v4's @theme directive.

What's in scope for theming: colors, radius, font stack. Not in scope: layout, spacing, component shape. That's intentional — themes are visual, not structural.

Templates

Above themes is templates — full frontend designs that ship with the CMS. The active one on this site is "Aurora," which has its own seed data, blade templates, and section components. Templates are swappable at install time; runtime swap is harder because each ships its own homepage section data.

SEO

Built on the ralphjsmit/laravel-seo package, extended with site-wide defaults and per-post overrides.

What gets generated automatically:

<title> and meta description (with explicit override fields)
Open Graph + Twitter card tags
JSON-LD schema: Article, BreadcrumbList, Organization
Canonical URLs with proper trailing-slash handling
hreflang tags for multi-language sites

The CMS fallback for SEO title is the post title — but it title-cases it, which corrupts proper nouns ("WordPress" → "Wordpress"). Lesson learned the hard way: always set seo_title and meta_desc explicitly, never rely on the fallback. There's now a hard rule in our content-publishing skill.

RBAC

Spatie Permission. Three default roles ship — Super Admin, Editor, Author — and you can add more from the admin. Permissions are granular (per-model + per-action), not just role-based.

The middleware story is straight Laravel:

Route::middleware(['auth', 'role:editor|admin'])->group(function () {
    Route::resource('posts', PostController::class);
});

No vendor magic. If you've used Spatie Permission, you know exactly what's happening.

Multi-language

spatie/laravel-translatable. Each translatable field (title, body, seo_title, meta_desc) stores a JSON map of {locale: value}. The admin shows a locale switcher; the frontend resolves based on URL prefix (/fr/about) or domain.

What's not in there yet: automatic translation (machine translation pipeline). Editors translate manually for now.

The publishing pipeline (the part that took the longest)

Building a "save post" button is a weekend. Building a publishing pipeline that handles drafts, scheduled publishes, sitemap regeneration, cache invalidation, and SEO updates without race conditions is a year.

What's behind a publish action:

Validation — required fields, slug uniqueness, meta-desc length
Markdown → HTML conversion (server-side; the body is stored as HTML so the template just renders it raw)
SEO record sync — seo_title, meta_desc, og_image written to a related table
Spatie media attachment — featured image moves from temp upload to permanent collection
Sitemap regeneration — php artisan sitemap:generate runs synchronously (no queue worker required for shared hosting)
Cache invalidation — view:clear, route:clear, edge cache purge if configured
Activity log — Spatie ActivityLog records who published what

All of this runs synchronously in the request because the CMS targets shared hosting where queue workers aren't a given. If you're on a real VPS, you can flip QUEUE_CONNECTION=database and it queues automatically. The synchronous fallback is what makes "deploy to a $5 VPS" actually work.

Deployment story

Single artisan command: php artisan deploy. It does:

Verifies clean working tree on the deploy branch
Pushes to git
Pulls on the server
Runs composer install --no-dev (skipped if composer.lock unchanged)
Runs php artisan migrate --force
Builds frontend assets locally with pnpm run build, syncs to server via rsync (skipped if no JS/CSS changed)
Clears config/view/route caches
Verifies HTTP 200

The lessons embedded in this command:

Frontend builds locally, not on the server. Faster, and avoids needing Node on the server.
Composer skip when lockfile unchanged saves ~30s per deploy.
Rsync over SCP for assets — incremental, only uploads changed files.
HTTP 200 verification at the end catches deploys that broke the site silently.

I've shipped enough Laravel apps that I now consider the deploy command part of the product, not a project.

What's not in the box (yet)

Honest list:

Public headless API

Internal REST works. Public endpoints + signed webhooks ship late 2026. Until then, if you want to use UnfoldCMS as a content backend for a Next.js site, you write a thin Laravel route that returns JSON:

Route::get('/api/blog/{slug}', function (string $slug) {
    return Post::published()->whereSlug($slug)->firstOrFail();
});

Three lines, but I get it — that's not the same as a polished public API. Late 2026.

Plugin marketplace

Not building one. Extension model is Laravel service providers + middleware. If you know Laravel, you know how to extend it. If you don't, the learning curve is "Laravel itself," which is a real cost but a transferable one.

Visual page builder

The block editor handles structured content well. It's not a Webflow-style drag-and-drop layout designer, and probably won't be — different category. If you need that, Webflow or Storyblok is the right tool.

Multi-site / multi-tenant

Single site per install today. Agencies running 20 client sites run 20 installs (cheap on Hetzner — $5 × 20 = $100/mo for hosting; the license is per-site too).

The numbers

Concrete, not aspirational:

Lines of code: ~80K (PHP) + ~45K (TS/TSX) — a real product, not a toy
Pages in admin: 183
shadcn components: 50+
Themes shipped: 3
Memory footprint: ~80MB idle on Hetzner CX22
Cold start: ~250ms first request, ~40ms after warm
Build time: ~12 seconds (Vite + Inertia bundle)
Tests: ~600 PHPUnit tests, ~80% coverage on the critical paths

Pricing decision

One-time license per site. $99 Solo, $199 Pro, $499 Agency.

The reasoning: subscriptions hold customers' data hostage. A one-time license means a customer can install it, never pay again, and still own the install — code, database, content. If I disappear tomorrow, the install keeps working.

The downside: ARR is harder to project. The upside: customers actually trust me. After two years, I'd pick this model again.

Why I built it (the short version)

WordPress works for some sites. Contentful works for enterprise teams. None of them work for the in-between — small agencies and SMBs running 5–20 sites who want owned data, sane DX, and no monthly bill that scales with their growth.

UnfoldCMS is what I built for that gap. It's not the right answer for everyone — the comparison pages are explicit about who it's for and who it isn't.

Try it

Live demo (admin login on the page): https://unfoldcms.com/demo
Source: https://github.com/hpakdaman/unfoldcms
Docs: https://unfoldcms.com/docs
Comparison vs WordPress / Contentful / Sanity / Payload: https://unfoldcms.com/compare

Honest critique welcome in the comments — that's how the product gets better.

— Hamed

Building a themeable CMS admin with shadcn/ui + Tailwind v4 — lessons from 50+ components

hamed pakdaman — Sat, 09 May 2026 13:29:05 +0000

I shipped a Laravel CMS where the entire admin is built on shadcn/ui — 50+ components, 183 pages, three themes, runtime switching with no build step. Here are the five things that mattered most.

Why shadcn over Material UI / Ant Design

The deciding factor: shadcn components are my code. When I need to change a Button variant or extend DataTable, I edit the file. No npm overrides, no className wars, no vendor PR queue.

Tradeoff: when shadcn upstream ships a new pattern, I port it manually. Budget ~1 day/quarter for upgrades.

Lesson 1: Layout primitives save 100 pages of CSS

Three components used everywhere — PageContainer, Card, Stack. The PageContainer alone replaced ~40 page-level layout decisions. Three good ones beats 10 flexible ones.

Lesson 2: Tailwind v4 + CSS variables = themes without a build

@theme {
  --color-primary: oklch(0.55 0.27 262);
}
[data-theme="purple"] {
  --color-primary: oklch(0.55 0.27 304);
}

Switching themes:

document.documentElement.dataset.theme = 'purple';

No bundle changes. No re-render. CSS variables flip and every shadcn component updates because they reference the variable, not a hardcoded color. I expected theming to be the hard part — it took an afternoon.

Lesson 3: One Sidebar component, different data

shadcn's Sidebar is flexible enough to handle admin nav and docs nav with the same component. Data varies per-page; the component is shared. This is what makes a 183-page admin feel like one app.

Lesson 4: DataTable is the most underrated shadcn component

Every list view — Posts, Pages, Media, Users, Forms — uses the same DataTable wrapper. Server-side pagination, sorting, row selection, bulk actions, search. The columns array is the only per-page logic.

Lesson 5: TypeScript strictness is non-negotiable

shadcn ships excellent types. Don't loosen them. Every page-level component declares its props type explicitly, even when "obvious."

What didn't work

Tiptap as the rich-text editor. Great for free text, wrong for structured fields. Rebuilt on Tiptap's foundation with a custom block model — 3 weeks I'd have skipped with better evaluation.
Copying all 50 shadcn components up front. Only 30 actually got used. Copy on demand.
Tailwind v3 → v4 mid-build. ~4 hours of breaking changes. Start on v4 today.

What I'd use shadcn for again

Anything that needs custom design
Long-lived products where the maintenance cost is justified
Type-safe fullstack apps

What I wouldn't use it for: throwaway prototypes (use Mantine), marketing sites (Tailwind alone is faster).

Source: https://github.com/hpakdaman/unfoldcms
Live demo: https://unfoldcms.com/demo

I'm Hamed — built UnfoldCMS because none of WordPress, Contentful, or Strapi/Payload fit my Laravel shop. Honest critique welcome.

Durjay Views A Simple Laravel View Counter Package

Durjay Ghosh — Sat, 09 May 2026 12:30:51 +0000

Introducing Durjay Views — A Simple Laravel View Counter Package

Tracking views in a Laravel application should be simple, flexible, and developer-friendly. That’s why I built Durjay Views — a lightweight Laravel package for counting views on blogs, products, services, or any model with minimal setup.

GitHub Repository:
https://github.com/durjaygp/durjay-views

✨ Features

Simple Laravel view tracking
Track views using a helper function
Trait-based model integration
Supports Blogs, Products, Services, and custom entities
Stores everything in a single database table
Tailwind CSS statistics dashboard
Unique visitor tracking
7-day views chart
Recent activity table
Easy customization

📦 Installation

Install the package via Composer:

composer require durjaygp/durjay-views

Publish migrations and views:

bash php artisan vendor:publish --provider="Durjaygp\DurjayViews\DurjayViewsServiceProvider"

Run migrations:

bash php artisan migrate

🚀 Usage

Option 1: Using the Helper Function

You can track views instantly using a simple helper:

`php
trackDurjayViews('product', $product->id);

trackDurjayViews('blog', $blog->id);
`

Option 2: Using the Viewable Trait

If you prefer a cleaner model-based approach, use the included trait:

`php
namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Durjaygp\DurjayViews\Traits\Viewable;

class Product extends Model
{
use Viewable;
}
`

Now record views directly:

php $product->recordDurjayView();

Get total views:

php echo $product->view_count;

📊 Beautiful Statistics Dashboard

Visit:

bash /durjay-views/stats

The dashboard includes:

Today vs Yesterday statistics
Total unique visitors
Today's unique visitors
7-day interactive views chart
Recent activity tracking
Guest/User detection

You can also publish and customize the dashboard views:

bash php artisan vendor:publish --provider="Durjaygp\DurjayViews\DurjayViewsServiceProvider" --tag="views"

💡 Why I Built This

Most view counter solutions I found were either:

Too complicated
Required multiple tables
Lacked dashboards
Were difficult to integrate

So I decided to create something:

Beginner-friendly
Lightweight
Modern-looking
Easy to extend

🛠 Perfect For

Blog platforms
eCommerce stores
Portfolio websites
SaaS applications
CMS systems
Admin dashboards

⭐ GitHub Repository

👉 https://github.com/durjaygp/durjay-views

Feedback, issues, and contributions are always welcome.

Best MySQL Workbench Alternatives for Developers in 2026 (Honest Picks)

DevToolsPicks — Sat, 09 May 2026 11:49:25 +0000

Originally published at devtoolpicks.com

MySQL Workbench is the default answer to "how do I look at my database." It ships free with MySQL, runs on Windows, Mac, and Linux, and does the job. Most developers install it once and forget to question it.

The problem is that spending real time in MySQL Workbench in 2026 is a specific kind of frustration. It is slow to launch. It crashes on newer versions of macOS. The interface looks exactly like it did in 2014. It runs on Java, which means memory usage that feels wildly out of proportion to what it is actually doing.

None of that is controversial. The r/PHP thread that prompted this comparison had 79 comments and near-universal agreement: Workbench works, but nobody actually likes it.

The alternatives are genuinely better. One is completely free. One costs $79 once and you keep it. One comes free with your JetBrains subscription if you already have one. Here is how they compare.

Quick Verdict

Tool	Best For	Free Tier	Paid
DBeaver	Free, cross-platform, every database	Yes (Community, full-featured)	$110/year (Lite)
TablePlus	Clean UI, Mac-first, one-time cost	Limited (2 tabs, 2 windows)	From $79 one-time
Beekeeper Studio	Modern UI, open source	Yes (Community, GPLv3)	~$7/month (Ultimate)
DataGrip	SQL power users, JetBrains shops	No (30-day trial)	$99/year individual

DBeaver

DBeaver Community is the most complete free MySQL Workbench replacement available. It is open source under the Apache License, free for commercial use, and supports every major database you are likely to encounter: MySQL, MariaDB, PostgreSQL, SQLite, SQL Server, Oracle, and more.

The feature set goes well past what most developers use in MySQL Workbench. You get a full SQL editor with syntax highlighting and autocomplete, a visual data editor for browsing and editing rows, ER diagram generation, SSH tunneling, and a query history that actually works. None of this is paywalled.

The catch is the interface. DBeaver is built on the Eclipse platform, and it shows. The UI is functional but dense. Menus are deep, settings are numerous, and the default layout takes some time to configure into something comfortable. It is not a tool that feels good to open. It is a tool that does what you need once you learn where everything is.

Performance can also be a concern on large datasets. DBeaver is Java-based like MySQL Workbench, which means similar memory overhead. If Workbench felt slow on your machine, DBeaver may not feel dramatically different. TablePlus and Beekeeper Studio are both native applications and noticeably faster to launch and interact with.

If you want NoSQL support (MongoDB, Redis, Cassandra) or cloud database integrations (Amazon Redshift, Google BigQuery, Snowflake), you need the Lite plan at around $110/year or the Enterprise plan at $250/year. For MySQL and PostgreSQL work, Community is all you need.

What it is good at: Maximum database support without spending anything, strong SQL editor features, ER diagrams, teams comfortable with a learning curve, developers already used to Eclipse-based tools.

Who should NOT use DBeaver: Developers who value a clean and fast UI above feature breadth. If you want something that opens instantly and feels native, DBeaver will frustrate you for the same reasons MySQL Workbench does.

TablePlus

TablePlus is what most Mac-using developers switch to when they finally get tired of MySQL Workbench. It is a native application, which means it launches in under a second, scrolls smoothly, and feels like it was built for the operating system rather than ported to it.

The interface is genuinely pleasant. Connections are organized clearly, the query editor has good autocomplete and syntax highlighting, and the data browser shows results in a clean grid with inline editing. SSH tunneling works without setup pain. Multiple tabs and windows let you run parallel queries without juggling connections.

What it actually costs:

Free trial: limited to 2 opened tabs and 2 opened windows simultaneously
Basic License (1 device): $79 for Mac, $89-99 for Windows and Linux
Standard License (2 devices): $129
Annual maintenance for major version updates: $39-49/year

The one-time purchase model is worth understanding. You buy the license, you keep that version of the app indefinitely, even if you stop paying for updates. After one year, you can continue using it without any feature limitations. You only pay again if you want major version upgrades. For a solo developer on a tight budget, that is a fair deal.

Database support covers MySQL, MariaDB, PostgreSQL, SQLite, SQL Server, Redis, MongoDB (beta), CockroachDB, and others. That is everything a typical SaaS developer needs. If you are managing databases for multiple projects, which is likely if you are reading a DevToolPicks post about database clients, the ability to organize connections cleanly is a real quality-of-life improvement over Workbench.

The Linux version is technically in alpha. It works for most tasks but is missing some features available on Mac and Windows. If your primary machine is Linux, DBeaver or Beekeeper Studio are more reliable choices.

What it is good at: Mac-first Laravel and PHP developers, anyone who wants native performance, clean UI over maximum features, one-time pricing instead of subscriptions.

Who should NOT use TablePlus: Linux users who need a fully supported experience. Also not the right call if you need NoSQL database support, since TablePlus's MongoDB support is still in beta and limited compared to dedicated MongoDB clients.

Beekeeper Studio

Beekeeper Studio occupies an interesting position: it is the best-looking free option. The Community Edition is open source under GPLv3, actively maintained, and covers MySQL, PostgreSQL, SQLite, SQL Server, MariaDB, and more.

The interface is clean and modern in a way that DBeaver's is not. Tabs are easy to manage, saved queries are organized sensibly, and the connection setup is straightforward. If you want something that feels closer to TablePlus in terms of usability but costs nothing, Beekeeper Community is the realistic option.

The Community Edition is explicitly designed for individuals, students, non-profits, and small businesses with fewer than ten employees and annual revenue under $1 million. If your organization is larger, they ask that you buy an Ultimate Edition license. That is an honesty policy rather than a technical enforcement.

What the Ultimate Edition adds:

Cloud workspaces for sharing connections and queries across machines
Advanced import and export options
AI Shell, which connects to Claude, ChatGPT, and Gemini to write SQL from natural language
Additional data filters and visualization options

Ultimate costs around $7 per month. The interesting part of the pricing model: when you pay for a year, you get a lifetime license for any version released within your subscription window. So if you pay for one year and then stop, you can continue using the version that was current when your subscription ended, indefinitely. It is a fair middle ground between one-time payment and perpetual subscription.

There is one important limitation in the Community Edition: it lacks bulk import options and some filtering capabilities that power users will hit quickly. The paid tier is genuinely useful rather than artificially gated, which is a rarer claim than it sounds.

What it is good at: Developers who want a modern free client, open source advocates, anyone willing to pay a small amount for the lifetime license model, teams that want to share queries across machines.

Who should NOT use Beekeeper Studio: If you need a mature ER diagram tool, Beekeeper does not have one. DBeaver is the better choice for schema visualization. Also not ideal if you are managing more exotic databases, as Beekeeper's support is narrower than DBeaver's.

DataGrip

DataGrip is JetBrains' database IDE. If you use IntelliJ, PhpStorm, or any other JetBrains product regularly, DataGrip will feel familiar. The interface follows the same conventions: project sidebar on the left, tabbed editor, run configurations, and the JetBrains inspection system that catches SQL errors before you execute them.

The SQL editor is genuinely the most capable of the four tools here. Autocomplete is context-aware and pulls from your actual schema. The query planner integrations let you see execution plans inline. Refactoring tools work across multiple files. If SQL is your primary daily language and you spend hours in a database client, DataGrip's editing experience is meaningfully better than the others.

What it actually costs:

Individual commercial: $99/year (year 1), $79/year (year 2), $59/year (year 3+)
Organizations: $229/year
JetBrains All Products Pack for Individuals: $289/year (includes every JetBrains IDE)
Non-commercial (students, open source): free

The continuity discount is real. If you stay subscribed, the price drops significantly. And if you already pay for the All Products Pack because you use PhpStorm or IntelliJ, DataGrip comes included at no extra cost. That changes the math considerably.

It supports MySQL, PostgreSQL, SQLite, SQL Server, Oracle, MongoDB, Cassandra, and many others. Both relational and some NoSQL databases are covered, which puts it above TablePlus for breadth.

The downsides are weight and price. DataGrip is a full IDE, not a lightweight client. It is slower to launch than TablePlus or Beekeeper Studio, uses more memory, and has a steeper learning curve. For someone who just wants to browse tables and run the occasional query, it is more tool than the job needs.

What it is good at: Developers who write complex SQL regularly, JetBrains All Products Pack subscribers who get it free, teams doing serious database work where autocomplete and refactoring tools pay off.

Who should NOT use DataGrip: Anyone who just needs a simple MySQL browser. The price and complexity are not justified if your use case is running SELECT queries and checking table contents. DBeaver or Beekeeper Studio cover that at $0.

How to Choose

You use a Mac and want the best daily experience: TablePlus. One-time payment, native performance, clean UI.

You want a completely free option with broad database support: DBeaver Community. Accept the learning curve and the Java-based performance in exchange for zero cost and maximum compatibility.

You want free but with a modern interface: Beekeeper Studio Community. Better looking than DBeaver, narrower database support, honest about its commercial licensing terms.

You already pay for JetBrains: DataGrip is included in the All Products Pack. Install it and use it at no extra cost.

You work with MySQL and MariaDB on a tight budget: Beekeeper Studio Community handles both well and costs nothing.

You need ER diagrams and schema visualization: DBeaver. It is the only one here with a proper ER diagram tool built in.

You are a solo Laravel or PHP developer: TablePlus if you are on Mac. DBeaver or Beekeeper Studio if you are on Windows or Linux and do not want to pay. All three connect to MySQL, MariaDB, and PostgreSQL, which cover the typical Laravel stack.

Managing the database behind your SaaS is only half the picture. If you are also evaluating where to host it, the Supabase alternatives comparison covers Turso, Neon, Railway, and self-hosted Postgres side by side.

Final Recommendation

MySQL Workbench is not broken. It just has not kept pace with what developers expect from their tools in 2026.

If you are on a Mac and want the cleanest upgrade path, pay $79 for TablePlus Basic. It is the most pleasant database client you will use and the one-time pricing means you stop thinking about it after the purchase.

If you want free, DBeaver Community is the realistic choice for maximum compatibility. Accept the Eclipse-based UI in exchange for the broadest database support at zero cost.

If you want free with a better-looking interface, Beekeeper Studio Community is a genuine option. The $7/month Ultimate Edition with its lifetime license model is also worth considering if you use it daily.

If you are already paying for JetBrains tools, open DataGrip and try it. It is already in your subscription.

The honest summary: for most solo developers and indie hackers working with MySQL or PostgreSQL, TablePlus or Beekeeper Studio Community is the right call. DBeaver if you need broader compatibility or want nothing to do with a license key. DataGrip only if you are a SQL power user or already in the JetBrains ecosystem.

Laravel Now Has Native Passkeys: A Complete Guide to laravel/passkeys

Hafiz — Sat, 09 May 2026 07:24:25 +0000

Originally published at hafiz.dev

For a long time, adding passkeys to a Laravel app meant reaching for a third-party package, assembling WebAuthn ceremonies by hand, or piecing together a tutorial that assumes you already know what a "relying party ID" is. That's done.

In late April 2026, Laravel shipped laravel/passkeys, a first-party package authored by Taylor Otwell that gives you a complete passkey story out of the box. Server package, npm client, Fortify integration. Three pieces that click together so passwordless auth is boring to wire up, which is exactly what you want from a security feature.

I covered the Spatie passkeys approach back in January, and that's still valid if you're Livewire-heavy or already have that package running. But the native package is the right call for new projects and anything using Fortify. Here's the full setup.

What Ships in laravel/passkeys

The passkey stack has three components that each handle a distinct concern.

laravel/passkeys is the server-side Composer package. It handles WebAuthn ceremonies, manages a passkeys database table, registers routes for login, confirmation, and credential management, and fires events you can hook into. If you need custom authorization logic or your own route definitions, escape hatches are built in.

@laravel/passkeys is the npm client. It handles browser-side ceremony coordination (registration and verification) and ships first-class helpers for React, Vue, and Svelte with SSR-safe hooks so client-only APIs don't fight your framework. The public API is two methods: Passkeys.register() and Passkeys.verify(). That's it.

Fortify integration wires everything together via Features::passkeys() in your app config and a passkeys section in config/fortify.php. Fortify apps get the same endpoints and the PasskeyUser and PasskeyAuthenticatable contracts without reimplementing any glue.

The package is v0.1.0 but that's not a red flag. It's already the default in Laravel's official starter kits and used by Fortify in production. The version number signals that the public API may still evolve, not that the package is unstable.

Installation

Start by pulling in the Composer package:

composer require laravel/passkeys

Publish and run the migrations to create the passkeys table:

php artisan vendor:publish --tag=passkeys-migrations
php artisan migrate

Next, add a secret to your .env for deriving stable opaque user handles. This keeps passkey associations private even if your user IDs are sequential integers:

PASSKEYS_USER_HANDLE_SECRET=your-random-secret-here

Generate a value with:

php artisan key:generate --show

Use that output as your secret. The package falls back to APP_KEY if you leave this blank, but keeping them separate is better practice. If you ever rotate your app key, users won't lose their passkeys. You can find a full reference of available artisan commands in the Laravel Artisan Commands reference.

Configuring Your User Model

Add the PasskeyUser contract and PasskeyAuthenticatable trait to your User model:

<?php

namespace App\Models;

use Illuminate\Foundation\Auth\User as Authenticatable;
use Laravel\Passkeys\Contracts\PasskeyUser;
use Laravel\Passkeys\PasskeyAuthenticatable;

class User extends Authenticatable implements PasskeyUser
{
    use PasskeyAuthenticatable;

    // Rest of your model...
}

The trait assumes your users table has name and email columns. Authenticators show these values in their UI during registration and account selection. displayName falls back from name to email to the auth identifier. Same for username.

If you need different display values, override the methods directly on the model:

public function getPasskeyDisplayName(): string
{
    return $this->full_name ?? $this->email;
}

public function getPasskeyUsername(): string
{
    return $this->email;
}

That's the only change your model needs. No extra migrations, no pivot tables. The passkeys table handles credential storage and links to your user via a standard relationship that PasskeyAuthenticatable sets up for you.

Fortify Integration

If you're using Laravel Fortify, enabling passkeys takes one line in your features array:

use Laravel\Fortify\Features;

'features' => [
    Features::registration(),
    Features::resetPasswords(),
    Features::emailVerification(),
    Features::passkeys(), // Add this
],

Fortify automatically registers the passkey routes and wires up the contracts. Nothing else changes on the server side. Your existing authorization setup with policies and gates stays untouched: passkeys only replace the authentication step, not what happens after it.

The Config File

Publish the config if you need to customize anything:

php artisan vendor:publish --tag="passkeys-config"

The defaults in config/passkeys.php are sensible:

return [
    'relying_party_id' => parse_url(config('app.url'), PHP_URL_HOST),
    'allowed_origins' => [config('app.url')],
    'user_handle_secret' => env('PASSKEYS_USER_HANDLE_SECRET', config('app.key')),
    'timeout' => 60000,
    'guard' => 'web',
    'middleware' => ['web'],
    'management_middleware' => ['password.confirm'],
    'throttle' => 'throttle:6,1',
    'redirect' => '/',
];

A few worth understanding before you change anything.

relying_party_id is your domain, derived from APP_URL. Passkeys are cryptographically bound to this value. If the domain the browser accesses doesn't match, the ceremony fails. Make sure APP_URL reflects the actual domain you're serving, especially in local development.

management_middleware defaults to password.confirm, which means users must re-confirm their password before adding or revoking passkeys. Don't disable this. It's the right friction for a security-critical action. The same principle applies here as with sensitive token operations in Passport vs Sanctum.

throttle limits passkey attempts to 6 per minute. Sensible for production. Adjust it if you have unusual traffic patterns, but don't remove it entirely.

Routes the Package Registers

You don't define any routes yourself. The server package registers these automatically:

POST   /passkeys/register/options   (generate registration challenge)
POST   /passkeys/register           (store the new credential)
POST   /passkeys/verify/options     (generate authentication challenge)
POST   /passkeys/verify             (authenticate with passkey)
DELETE /passkeys/{passkey}          (revoke a specific passkey)

If you need custom route definitions (different middleware, prefixes, or custom controllers), you can disable auto-registration in the config and define them yourself. The underlying action classes are all public and importable, so you're not losing functionality by taking manual control.

How the WebAuthn Flow Works

It helps to see the ceremony before writing the frontend code:

View the interactive diagram on hafiz.dev

Registration follows the same pattern: browser requests options, authenticator creates a key pair, public key gets stored on your server. Nothing sensitive ever leaves the device. The private key never travels over the network, which is the core security advantage over passwords. No credentials to steal from a database breach.

Frontend Integration (Vue)

Install the npm client:

npm install @laravel/passkeys
npm run build

Here's a Vue 3 component that handles both registration (authenticated users adding a passkey) and login (on the login page):

<script setup>
import { ref } from 'vue'
import { Passkeys } from '@laravel/passkeys'

const registering = ref(false)
const verifying = ref(false)
const error = ref(null)

async function registerPasskey() {
    registering.value = true
    error.value = null

    try {
        await Passkeys.register({ name: 'My Device' })
        // Passkey saved, refresh the list or show a success toast
    } catch (e) {
        error.value = e.message
    } finally {
        registering.value = false
    }
}

async function loginWithPasskey() {
    verifying.value = true
    error.value = null

    try {
        await Passkeys.verify()
        // Redirects automatically on success
    } catch (e) {
        error.value = e.message
    } finally {
        verifying.value = false
    }
}
</script>

<template>
    <div class="space-y-4">
        <!-- Show on profile/settings for authenticated users -->
        <button @click="registerPasskey" :disabled="registering" class="btn">
            {{ registering ? 'Registering...' : 'Add a Passkey' }}
        </button>

        <!-- Show on your login page -->
        <button @click="loginWithPasskey" :disabled="verifying" class="btn">
            {{ verifying ? 'Verifying...' : 'Sign in with Passkey' }}
        </button>

        <p v-if="error" class="text-red-500 text-sm">{{ error }}</p>
    </div>
</template>

Passkeys.register() handles the full browser ceremony: it fetches the challenge from /passkeys/register/options, prompts the authenticator, and POSTs the resulting credential back to the server. Passkeys.verify() does the same for login and then redirects to the path defined in config/passkeys.php → redirect on success.

For React, the import and API are identical. The Svelte helpers follow the same pattern. The package abstracts all the @simplewebauthn/browser ceremony complexity behind a clean two-method interface, which is what you want when you're not trying to become a WebAuthn expert.

Managing Registered Passkeys

Users should be able to see and revoke their passkeys. This matters more than people expect. Users register on their laptop, their phone, and their work machine, then wonder why three entries show up. Give them the tools to clean it up.

A basic controller looks like this:

// PasskeyController.php
use Illuminate\Http\Request;
use Laravel\Passkeys\Models\Passkey;

class PasskeyController extends Controller
{
    public function index(Request $request)
    {
        $passkeys = $request->user()->passkeys()->latest()->get();

        return view('passkeys.index', compact('passkeys'));
    }

    public function destroy(Request $request, Passkey $passkey)
    {
        $this->authorize('delete', $passkey);

        $passkey->delete();

        return back()->with('status', 'Passkey removed.');
    }
}

The passkeys() relationship is defined by the PasskeyAuthenticatable trait. Each Passkey record has a name, created_at, and last_used_at column. Surface all three in the UI so users can tell which device is which and spot ones they don't recognise.

Wire the delete action to the DELETE /passkeys/{passkey} route the package already registered. The management_middleware (password confirm by default) protects both the management view and the delete action, so users need to re-authenticate before making changes.

Comparing to spatie/laravel-passkeys

Both packages use web-auth/webauthn-lib under the hood and get you to the same outcome. The difference is approach.

laravel/passkeys (native) is first-party and stack-agnostic on the frontend. Right choice for new Laravel 11, 12, or 13 projects and anything using Fortify. If you're starting fresh, use this.

spatie/laravel-passkeys ships Livewire components out of the box. If your app is already Livewire-heavy and you have Spatie's package working, there's no reason to migrate. The earlier passkeys guide covers that setup in full.

Don't run both at the same time. They register overlapping routes and you'll get conflicts.

Things to Get Right Before You Ship

A few things that will save you a debugging session:

HTTPS is required. WebAuthn only works on secure origins. For local development, use valet secure (Valet or Herd) or configure SSL in Sail. If APP_URL uses http://, the browser refuses to run the ceremony entirely. No error message. Just silence.

Keep password auth as a fallback. Not every user is on a passkey-capable device. Passkeys should be additive. Don't remove your existing login form. Make it an option alongside the passkey button, not a replacement for it.

Account recovery needs thought. If a user loses access to all their registered devices, how do they get back in? The package doesn't solve this. Email-based recovery or admin-initiated password resets are the standard approaches. Build this flow before you go live.

Multiple passkeys per user are supported by default. Users register on multiple devices, and that's expected. Your management UI (a list with a revoke button per passkey) handles this. Show name, created_at, and last_used_at so users can make sense of what's there.

The management_middleware default is password.confirm. Users re-confirm their password before adding or revoking passkeys. Don't strip it out. It's the same security pattern you'd apply to any sensitive account action.

Local Development

One thing that trips people up: APP_URL in .env must match the domain you're actually accessing in the browser. A mismatch makes the relying party check fail, and the error can be cryptic.

APP_URL=https://myapp.test

If you're on Valet:

valet secure myapp

That's all you need. The package reads APP_URL for its relying party config automatically.

FAQ

Does this work on Laravel 11 and 12, or only 13?

The package requires illuminate/contracts: ^11.0|^12.0|^13.0, so all three versions are supported. You don't need to upgrade to Laravel 13 to use it.

Do I need Fortify to use this?

No. Fortify integration is optional. The server package works standalone: you define your own routes and handle redirects. Features::passkeys() just automates the setup if Fortify is already in your stack.

What if I'm already using spatie/laravel-passkeys?

Stay on Spatie unless you have a specific reason to switch, especially if the Livewire setup is working. If you do migrate, uninstall the Spatie package and remove its service provider first. Don't run both simultaneously.

Is v0.1.0 stable enough for production?

The package is already the default in Laravel's official starter kits and backed by Fortify. The v0.1.0 label means the public API may evolve, not that it's experimental. For new projects, use it without hesitation.

Can I use this without a JavaScript framework?

Yes. The framework-specific helpers (Vue, React, Svelte) are convenience wrappers around the same core API. If you're using Blade without a frontend framework, you can call Passkeys.register() and Passkeys.verify() from a plain <script> block after importing @laravel/passkeys.

Get It Wired Up

Native passkeys is a small, focused addition to any Laravel project. The config is sensible by default, Fortify integration is a single line, and the frontend API is two method calls. If you're starting a new Laravel project today and want passwordless auth, this is the path.

If you're adding passkeys to an existing production app or migrating a complex auth setup, get in touch and we can work through the integration together.

Laravel Localization: Multi-Language Website

Rafli Zocky — Fri, 08 May 2026 14:00:00 +0000

Auto-Translated (Content-Based)

Install Google Translate API PHP Package

composer require stichoza/google-translate-php

Language Switcher (View)

<div class="flex items-center space-x-2">
    <a href="/lang/id"
        class="text-gray-200 hover:text-white {{ session('locale') === 'id' ? 'border-b-2 border-yellow-500' : '' }}">ID</a>
    <span class="text-gray-200">|</span>
    <a href="/lang/en"
        class="text-gray-200 hover:text-white {{ session('locale') === 'en' || !session('locale') ? 'border-b-2 border-yellow-500' : '' }}">EN</a>
</div>

Route for Language Switching

Route::get('/lang/{lang}', function ($lang) {
    session(['locale' => $lang]);
    return back();
});

Migration — add columns to store translations:

Schema::table('abouts', function (Blueprint $table) {
    $table->string('title');
    $table->text('description');
    $table->json('title_translations')->after('title')->nullable();
    $table->json('description_translations')->after('description')->nullable();
});

Model

protected $fillable = ['title', 'description', 'title_translations', 'description_translations', 'image'];

protected $casts = [
    'title_translations' => 'array',
    'description_translations' => 'array',
];

public function getTranslatedTitle()
{
    $locale = session('locale', 'id');
    return $this->title_translations[$locale] ?? $this->title;
}

public function getTranslatedDescription()
{
    $locale = session('locale', 'id');
    return $this->description_translations[$locale] ?? $this->description;
}

Trait for Auto Translation (app/Traits/Translatable.php)

namespace App\Traits;

use Stichoza\GoogleTranslate\GoogleTranslate;

trait Translatable {
    public function autoTranslate($text) {
        $translator = new GoogleTranslate();
        return [
            'en' => $translator->setTarget('en')->translate($text),
            'id' => $translator->setTarget('id')->translate($text),
        ];
    }
}

Controller (Store & Update)

use App\Traits\Translatable;

class AboutController extends Controller
{
    use Translatable;

    public function store(Request $request)
    {
        $validatedData['title_translations'] = $this->autoTranslate($validatedData['title']);
        $validatedData['description_translations'] = $this->autoTranslate($validatedData['description']);
        About::create($validatedData);
    }

    public function update(Request $request, string $id)
    {
        if ($request->has('title')) {
            $validatedData['title_translations'] = $this->autoTranslate($request->title);
        }
        if ($request->has('description')) {
            $validatedData['description_translations'] = $this->autoTranslate($request->description);
        }
        $about->update($validatedData);
    }
}

View

{{ $about->getTranslatedTitle() }}
{{ $about->getTranslatedDescription() }}

Static Translations (Manual Inline)

📌 Normally you'd use resources/lang/{locale} files, but here's a quick inline method.

Route

Route::get('/lang/{lang}', function ($lang) {
    if (!in_array($lang, ['en', 'id'])) {
        $lang = 'id';
    }
    session(['locale' => $lang]);
    app()->setLocale($lang);
    return back();
});

View

@php
$newsTranslations = [
    'section_title' => [
        'id' => 'Berita Pertambangan Nasional',
        'en' => 'National Mining News',
    ],
];
$locale = session('locale', 'id');
@endphp

<h2 class="text-3xl md:text-4xl font-bold text-gray-800 mb-3">
    {{ $newsTranslations['section_title'][$locale] }}
</h2>

That's all. You've now got basic multilingual support for both dynamic (admin input) and static (inline text) content in Laravel.

Need help building your app?
I'm available for freelance web & Android development — raflizocky.netlify.app

☕ Support my writing: paypal.me/raflizocky · saweria.co/raflizocky

How We Implemented Content Security Policy (CSP) in Our Laravel App

Shakil Alam — Fri, 08 May 2026 13:08:47 +0000

Our pentest report had one line that stopped us cold:

"Application does not implement Content-Security-Policy headers. XSS payloads executed without restriction."

We had Sanctum, CSRF tokens, input validation — all the standard Laravel security checklist items. But we had no CSP. And without it, a single successful XSS attack could exfiltrate session cookies, inject malicious scripts, or silently redirect users to attacker-controlled pages — all from our own domain.

This is the story of how we added CSP to a production Laravel application without breaking anything, how we built a violation reporting pipeline, and the things we wish we'd known before starting.

What's in this guide

This post is written to be useful regardless of where you're starting from:

Never heard of CSP? Start from the top. The first two sections give you the mental model before any code appears.
Know what CSP is but haven't implemented it? Jump to The Implementation.
Already running CSP and want to tighten it or add reporting? Jump to CSP Violation Reporting or the Pre-Enforcement Checklist.

What Content Security Policy Actually Does

When a browser loads a page, it executes whatever scripts, styles, fonts, and images are on it — regardless of where they came from. That's what makes XSS dangerous: if an attacker manages to inject a <script> tag into your HTML, the browser runs it without question.

CSP is an HTTP response header that changes this. It tells the browser: "Only trust resources from these specific sources. Anything else — block it."

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-abc123'; object-src 'none'

With that header in place, even if an attacker injects a <script> tag, the browser refuses to execute it. The tag has no valid nonce — a cryptographically random token generated fresh for each request. Scripts carrying the matching nonce run. Everything else is blocked.

New to this? MDN has the definitive CSP reference if you want to go deeper on any specific directive.

What Is a Nonce?

You'll see the word "nonce" throughout this post, so let's settle it quickly before writing any code.

A nonce (short for number used once) is a random string generated fresh on every single page load. The server puts it in the CSP header, and also stamps it onto every <script> or <style> block it trusts:

// In the HTTP header the server sends:
Content-Security-Policy: script-src 'nonce-k8Hv2mXpQ3'

// On the script tag in your HTML:
<script nonce="k8Hv2mXpQ3">...</script>

The browser sees both, checks they match, and runs the script. If an attacker injects a <script> tag, it has no nonce — or the wrong one — so it gets blocked. Since the nonce changes on every request, an attacker who somehow saw yesterday's nonce can't reuse it today.

Why not just use a static secret key? Because a static value could be cached, leaked in logs, or extracted from your source code. A nonce only needs to survive one request. After that, it's worthless.

What a nonce is not:

It is not a replacement for input sanitisation. A nonce stops injected scripts from running. It doesn't stop them from being stored in your database.
It is not encryption. Anyone who can see the page source can see the nonce — that's fine, because it expires the moment the request ends.
It is not a CSRF token. They look similar in concept but solve completely different problems.

That's it. When you see nonce="{{ $cspNonce }}" in templates below, it simply means: "the server trusts this specific block."

The Naive Approach (and Why It Fails)

Most teams discover CSP when a security audit flags it, then reach for the quickest fix: a static header in nginx.conf or apache.conf.

This works for about five minutes. Then the inline JavaScript breaks. Alpine.js stops. Livewire stops. Any <script> block that doesn't come from a separate file gets blocked. The knee-jerk reaction is:

script-src 'self' 'unsafe-inline'

Done. Everything works again. And CSP is now completely useless — 'unsafe-inline' means any inline script can run, including one an attacker injected.

The correct approach is a nonce-based CSP generated per request inside Laravel, where every trusted inline script carries a token only the server knows. That's what we built.

The Mindset Shift: Write CSP-Friendly Code

Before writing a single line of middleware, you need to change how you write templates. CSP doesn't just enforce a header — it enforces discipline about where your code lives.

Move JavaScript out of your HTML. Event handler attributes are the main offender:

<!-- ❌ This is blocked by any sensible CSP -->
<button onclick="submitForm()">Submit</button>
<script>function submitForm() { ... }</script>

<!-- ✅ This is CSP-friendly — JS lives in an external file -->
<button id="submit-btn">Submit</button>
<script src="/js/form.js"></script>

Move styles out of your HTML too. The style="" attribute on elements cannot carry a nonce — there's no mechanism to whitelist individual instances. Your only options with a strict policy are "allow all of them" or "block all of them." Build the habit of using CSS classes from the start.

For inline code you genuinely can't move — a config value JavaScript needs, critical above-the-fold CSS — the nonce is your escape hatch:

<script nonce="{{ $cspNonce }}">
    window.APP_ENV = "{{ config('app.env') }}";
</script>

A nonce is generated fresh on every request. An attacker can't predict it. A script they inject has no nonce, so it gets blocked even if everything else fails.

Pro Tip: Never hardcode a nonce, never reuse one. Generate it with random_bytes() — not uniqid(), not md5(time()).

Just want the output without the reading? I built a free Laravel CSP Generator — toggle your CDNs and integrations, and it generates the full policy string, the PHP middleware method, and an adaptive pre-enforcement checklist live. Come back here for the why behind each decision.

The Implementation

We put all security headers in one SecureHeadersMiddleware rather than spreading logic across nginx.conf, .htaccess, and multiple middleware files.

Step 1: Generate the Nonce and Share It

php artisan make:middleware SecureHeadersMiddleware

<?php

declare(strict_types=1);

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Vite;
use Illuminate\Support\Facades\View;
use Symfony\Component\HttpFoundation\Response;

class SecureHeadersMiddleware
{
    // Disable in local/testing to avoid log noise from developer browsers
    // full of extensions. Automatically driven by the current environment.
    private bool $allowReporting;

    public function __construct()
    {
        $this->allowReporting = !app()->environment(['local', 'testing']);
    }

    public function handle(Request $request, Closure $next): Response
    {
        $nonce = base64_encode(random_bytes(16));

        // Share with all Blade templates automatically — no manual passing needed
        View::share('cspNonce', $nonce);

        // Tell Vite to inject this nonce on its bootstrapping inline script.
        // Skip this and @vite() silently breaks under a strict CSP.
        Vite::useCspNonce($nonce);

        /** @var Response $response */
        $response = $next($request);

        $this->addContentSecurityPolicy($response, $nonce, $request);
        $this->addClickjackingProtection($response);
        $this->addStrictTransportSecurity($response, $request);
        $this->addMiscSecurityHeaders($response);
        $this->removeUnwantedHeaders($response);

        if ($this->allowReporting && $this->supportsReportTo($request)) {
            $this->addCspReportingEndpoint($response);
        }

        return $response;
    }
}

Two ordering rules matter here. The nonce must be generated before $next($request) because the view renders during that call. The headers are set after because they need the response object. Swap either and things break silently.

Step 2: Define the CSP Policy

protected function addContentSecurityPolicy(Response $response, string $nonce, Request $request): void
{
    $isLocal = app()->environment('local');

    $policy = [
        "default-src 'self'",
        "script-src 'self' 'nonce-{$nonce}' https://cdn.jsdelivr.net https://cdnjs.cloudflare.com https://embed.tawk.to",
        "style-src 'self' 'nonce-{$nonce}' https://fonts.googleapis.com https://cdnjs.cloudflare.com",
        "style-src-elem 'self' 'nonce-{$nonce}' https://fonts.googleapis.com https://cdnjs.cloudflare.com",
        "style-src-attr 'none'",
        "font-src 'self' data: https://fonts.gstatic.com https://cdnjs.cloudflare.com",
        "img-src 'self' data: https://cdn.jsdelivr.net https://cdnjs.cloudflare.com https://your-cdn.example.com",
        "frame-src 'self' https://your-video-host.example.com",

        // Vite's HMR uses a WebSocket on localhost — only needed in local dev.
        // Never ship localhost entries to production.
        "connect-src 'self'" . ($isLocal ? " ws://localhost:5173 wss://localhost:5173" : ""),

        "object-src 'none'",
        "base-uri 'self'",
        "frame-ancestors 'none'",
    ];

    // upgrade-insecure-requests on a local HTTP server triggers confusing
    // mixed-content errors that have nothing to do with your code.
    if (!$isLocal) {
        $policy[] = 'upgrade-insecure-requests';
    }

    if ($this->allowReporting) {
        $policy[] = 'report-uri /api/csp-violation-report';
    }

    $response->headers->set('Content-Security-Policy', implode('; ', $policy));
}

Directive reference — what each one actually does:

Directive	What it controls	Our value
`default-src`	Fallback for any type not explicitly listed	`'self'`
`script-src`	JavaScript execution	`'self'` + nonce + CDN allowlist
`style-src`	CSS `@import` rules within stylesheets; base fallback	`'self'` + nonce + CDN allowlist
`style-src-elem`	`<link rel="stylesheet">` and `<style>` blocks	`'self'` + nonce + CDN allowlist
`style-src-attr`	Inline `style=""` attributes	`'none'` (blocked entirely)
`font-src`	Font files	`'self'` + data URIs + Google Fonts
`img-src`	Images	`'self'` + data URIs + CDN
`frame-src`	`<iframe>` sources	`'self'` + trusted video host
`connect-src`	`fetch()`, XHR, WebSockets, SSE	`'self'` + localhost WS in dev
`object-src`	Browser plugins (Flash, Java)	`'none'`
`base-uri`	The `<base>` tag's `href`	`'self'`
`frame-ancestors`	Who can embed this page in an iframe	`'none'`

default-src 'self' means anything not covered by a specific directive falls back to same-origin only.

script-src is where most of the work happens. The nonce is per-request, cryptographically random, and unpredictable. In CSP Level 3, the presence of a nonce automatically overrides 'unsafe-inline' for supporting browsers — so even if you add it as a temporary fallback, modern browsers ignore it in favour of nonce validation.

connect-src controls everything your JavaScript can talk to: fetch(), XMLHttpRequest, WebSockets, and Server-Sent Events. Vite's Hot Module Replacement uses a WebSocket on localhost:5173 to push changes to your browser during development. Without it in connect-src, HMR fails silently and you're doing hard refreshes all day. In production, that entry must not appear — hence the environment check.

object-src 'none' blocks Flash and all other browser plugins. There's no reason to allow these in 2026.

base-uri 'self' prevents an attacker from injecting <base href="https://evil.com">, which would silently redirect all relative URLs — links, form actions, script paths — to their server.

frame-ancestors 'none' is clickjacking protection at the CSP level: your pages cannot be embedded in iframes on other domains. Stronger than X-Frame-Options for modern browsers; we keep X-Frame-Options too for legacy ones.

upgrade-insecure-requests tells the browser to automatically upgrade HTTP sub-resource requests to HTTPS. We skip it in local development because it causes confusing mixed-content errors on a plain HTTP dev server.

Deep Dive: `style-src`, `style-src-elem`, and `style-src-attr`

Most developers assume these three are aliases for the same thing and only set style-src. They're not — and that misunderstanding is what causes hours of debugging when styles randomly break.

The one-line summary: style-src is the fallback. style-src-elem controls <style> blocks and <link> tags. style-src-attr controls style="" attributes on elements. Set all three explicitly, or the browser decides how to inherit, which is rarely what you want.

Here's the breakdown:

style-src is the base rule that covers everything CSS-related when the more specific directives aren't set. Even when you do set the others, style-src still governs one thing they don't: CSS @import rules inside your own stylesheets. @import url('https://fonts.googleapis.com/...') is controlled by style-src, not style-src-elem.

style-src-elem controls two things: <link rel="stylesheet"> tags and <style> blocks. The important detail is that <style> blocks can carry a nonce, so you can precisely whitelist only the inline styles you wrote:

{{-- Trusted — nonce matches the header --}}
<style nonce="{{ $cspNonce }}">
    .hero { background: url('/img/hero.jpg') center/cover; }
</style>

{{-- Blocked — no nonce --}}
<style>.injected { color: red; }</style>

External stylesheets via <link href="..."> don't need a nonce — they're controlled by the domain allowlist. Nonces only apply to inline content.

style-src-attr controls only the inline style="" attribute on HTML elements — and this is the problem child. style="" attributes cannot carry a nonce. There is no way to whitelist specific ones. Your only two options are 'unsafe-inline' (trusts all of them, including anything injected) or 'none' (blocks all of them). We use 'none'.

style-src       → CSS @import in files + base fallback  → 'self' + nonce + CDN
style-src-elem  → <link> tags + <style> blocks          → nonce-gated
style-src-attr  → style="" attributes                   → 'none', blocked entirely

Before you enable this: audit your JavaScript-driven UI libraries. Drag-and-drop, tooltips, and modals commonly set style="top: 48px; left: 200px" dynamically — every one of them will break under style-src-attr 'none'. Run in report-only mode first and your logs will tell you exactly which libraries are the offenders before anything breaks in production.

Step 3: Use the Nonce in Blade

{{-- Vite assets — no nonce attribute needed on the tag itself.
     Vite::useCspNonce() in the middleware handles the inline bootstrapper. --}}
@vite(['resources/css/app.css', 'resources/js/app.js'])

{{-- Inline script blocks you write manually --}}
<script nonce="{{ $cspNonce }}">
    const config = @json($appConfig);
</script>

{{-- Inline style blocks --}}
<style nonce="{{ $cspNonce }}">
    .hero { background: url('/img/hero.jpg') center/cover; }
</style>

{{-- Livewire v2 --}}
@livewireScripts(['nonce' => $cspNonce])

{{-- Livewire v3 --}}
@livewireScriptConfig(['nonce' => $cspNonce])

One thing to be clear on: <script src="..."> and <link rel="stylesheet" href="..."> tags pointing to external files do not need a nonce attribute. The browser permits them if their domain is on the allowlist. Nonces exist purely for inline content that has no domain to verify against.

Step 4: Add the Rest of the Security Header Stack

CSP is one layer. The same middleware handles the remaining browser security headers — each in a focused method:

protected function addClickjackingProtection(Response $response): void
{
    // Legacy browsers fall back to this; modern ones use frame-ancestors from CSP
    $response->headers->set('X-Frame-Options', 'DENY');
}

protected function addStrictTransportSecurity(Response $response, Request $request): void
{
    // Check X-Forwarded-Proto too — without this, HSTS is never sent when
    // you're behind a load balancer that terminates SSL before Laravel sees the request
    $isHttps = $request->isSecure()
        || strcasecmp((string) $request->header('X-Forwarded-Proto', ''), 'https') === 0;

    if (!$isHttps) {
        return;
    }

    $response->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');
}

protected function addMiscSecurityHeaders(Response $response): void
{
    // Prevents browsers from MIME-sniffing a response away from the declared content-type
    $response->headers->set('X-Content-Type-Options', 'nosniff');

    // Controls what's sent in the Referer header on navigation
    $response->headers->set('Referrer-Policy', 'strict-origin-when-cross-origin');

    // Deprecated and ignored by modern browsers, but harmless to include
    $response->headers->set('X-XSS-Protection', '1; mode=block');

    // Restrict access to sensitive browser APIs
    $response->headers->set('Permissions-Policy', 'geolocation=(), microphone=(self), camera=(self), payment=(), fullscreen=*');
}

protected function removeUnwantedHeaders(Response $response): void
{
    // Both calls are needed: Symfony's header management and PHP's header() function
    // operate at different levels. Without both, X-Powered-By: PHP/8.x can still leak.
    foreach (['X-Powered-By', 'Server'] as $header) {
        $response->headers->remove($header);
        @header_remove($header);
    }
}

Step 5: Register the Middleware

// Laravel 11 — bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->web(append: [
        \App\Http\Middleware\SecureHeadersMiddleware::class,
    ]);
})

// Laravel 10 — app/Http/Kernel.php
protected $middlewareGroups = [
    'web' => [
        // ...
        \App\Http\Middleware\SecureHeadersMiddleware::class,
    ],
];

Attaching it to the web group means your JSON API routes — which don't render Blade views — don't receive an unnecessary CSP header. For high-throughput APIs that's a meaningful separation.

CSP Violation Reporting — Your Early Warning System 🚨

Running CSP without a reporting endpoint is like setting a burglar alarm with no monitoring. You need to know when the policy blocks something — to catch misconfigurations before users do, and to detect real injection attempts.

What a Violation Report Looks Like

When a browser blocks something, it POSTs a JSON payload to your report endpoint. Here's what that looks like:

{
  "csp-report": {
    "document-uri": "https://yourapp.com/dashboard",
    "referrer": "",
    "violated-directive": "script-src-elem",
    "effective-directive": "script-src-elem",
    "original-policy": "default-src 'self'; script-src 'self' 'nonce-abc123'",
    "blocked-uri": "https://evil.com/injected.js",
    "status-code": 200
  }
}

The blocked-uri tells you what was blocked. The violated-directive tells you which rule caught it. Together they tell you immediately whether this is a legitimate resource you forgot to allowlist or something that should never have been there.

Hosted alternative: If you'd rather not build your own reporting pipeline, report-uri.com by Scott Helme is a dedicated CSP report collection and analysis service. It handles noise filtering, dashboards, and alerting for you.

The Route

// routes/api.php
Route::post('/csp-violation-report', [CspReportController::class, 'store'])
    ->middleware('throttle:5');

throttle:5 limits to 5 reports per minute per IP. Without rate limiting, an attacker can flood your logging infrastructure by triggering violations in a loop — exhausting disk space or burying real threats in noise.

The Controller

<?php

declare(strict_types=1);

namespace App\Http\Controllers\Api;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\RateLimiter;

class CspReportController
{
    public function store(Request $request)
    {
        $body = json_decode($request->getContent(), true);
        $report = $body['csp-report'] ?? $body ?? [];

        if (empty($report) || !is_array($report)) {
            return response()->noContent();
        }

        $json = json_encode($report);
        $ip = $request->ip();
        $blockedUri = data_get($report, 'blocked-uri', '');
        $violatedDirective = data_get($report, 'violated-directive', '');

        // Browser extensions are the biggest source of CSP noise.
        // Ad blockers, password managers, and DevTools extensions all fire reports.
        // They're not actionable — filter them immediately.
        if (
            str_contains($json, 'chrome-extension://') ||
            str_contains($json, 'moz-extension://') ||
            str_contains($json, 'safari-extension://')
        ) {
            return response()->noContent();
        }

        // Low-risk: usually your own code or a library doing something non-standard.
        // Review weekly, not immediately.
        $lowRiskUris = ['about:blank', 'blob:', 'data:', 'inline', 'eval'];

        if (in_array($blockedUri, $lowRiskUris)) {
            Log::channel('csp_low')->info('Low-risk CSP violation', compact('ip', 'report'));
            return response()->noContent();
        }

        // High-risk: an external domain, an unknown script, potentially injected content.
        // Log with full context. Alert if sustained.
        Log::channel('csp_high')->warning('High-risk CSP violation', compact('ip', 'report'));

        $this->checkForThresholdAlert($ip, $blockedUri, $violatedDirective);

        return response()->noContent();
    }

    protected function checkForThresholdAlert(string $ip, string $uri, string $directive): void
    {
        // Same IP, same directive, 10+ times in 60 seconds = probe, not noise.
        $key = "csp_alert:$ip:{$directive}:$uri";

        if (RateLimiter::tooManyAttempts($key, 10)) {
            Log::alert('CSP threshold exceeded — possible active attack', [
                'ip'        => $ip,
                'uri'       => $uri,
                'directive' => $directive,
            ]);
            return;
        }

        RateLimiter::hit($key, 60);
    }
}

Log Channels

// config/logging.php
'csp_low' => [
    'driver' => 'single',
    'path'   => storage_path('logs/csp-low-risk.log'),
    'level'  => 'info',
],

'csp_high' => [
    'driver' => 'single',
    'path'   => storage_path('logs/csp-high-risk.log'),
    'level'  => 'warning',
],

Separate files let you set different retention policies — low-risk logs rotate weekly, high-risk logs stay for 90 days. In production, wire Log::alert() into Slack or PagerDuty so a spike in high-risk violations at 2 AM wakes someone up.

The Modern Report-To Header

For Chrome 70+, Edge 79+, and Firefox 60+, the Reporting API (Report-To header) is more efficient than report-uri — reports are batched, and the endpoint is cached so the browser sends reports even from pages that didn't include the header.

protected function supportsReportTo(Request $request): bool
{
    $ua = $request->header('User-Agent', '');

    return (bool) preg_match(
        '/(Chrome\/([7-9][0-9]|[1-9][0-9]{2,}))|(Firefox\/(6[0-9]|[7-9][0-9]|[1-9][0-9]{2,}))|(Edg\/([7-9][0-9]|[1-9][0-9]{2,}))|(Version\/(1[3-9]|[2-9][0-9])) Safari\//',
        $ua
    );
}

protected function addCspReportingEndpoint(Response $response): void
{
    $reportTo = [
        'group'              => 'csp-endpoint',
        'max_age'            => 10886400, // 126 days — browser caches this endpoint
        'endpoints'          => [
            ['url' => url('/api/csp-violation-report')],
        ],
        'include_subdomains' => true,
    ];

    $response->headers->set('Report-To', json_encode($reportTo, JSON_UNESCAPED_SLASHES));
}

We keep report-uri in the CSP policy as a fallback for browsers that don't support the Reporting API. Both can coexist.

Pre-Enforcement Checklist

Run through this before switching from report-only to enforcement mode:

[ ] Vite::useCspNonce($nonce) is called before $next($request) in the middleware
[ ] @vite(), @livewireScripts(), and @livewireScriptConfig() all pass the nonce
[ ] Every hand-written inline <script> block has nonce="{{ $cspNonce }}"
[ ] Every hand-written inline <style> block has nonce="{{ $cspNonce }}"
[ ] onclick="", onsubmit="", and other event handler attributes are removed from templates
[ ] style="" attributes are replaced with CSS classes (or the library using them is documented)
[ ] All CDN domains you load from are in the appropriate allowlist
[ ] connect-src includes your API endpoints, WebSocket hosts, and analytics targets
[ ] connect-src does not include localhost in your production policy
[ ] The violation report endpoint is live, throttled, and log channels are configured
[ ] Report-only mode has run in production for at least one week with no new high-risk violations

Deploy Safely: Start in Report-Only Mode

If you're adding CSP to an existing app, don't jump straight to enforcement. Swap the header name first:

// Change this:
$response->headers->set('Content-Security-Policy', implode('; ', $policy));

// To this, temporarily:
$response->headers->set('Content-Security-Policy-Report-Only', implode('; ', $policy));

The browser reports violations but blocks nothing. Run it in production for one to two weeks and watch csp-high-risk.log. Every entry is either a resource to allowlist or evidence of something that should never have been there. Once the log goes quiet, flip back to Content-Security-Policy.

This step is what separates a smooth rollout from an angry support queue.

Verify your headers: Use securityheaders.com to grade your response headers. Use Google's CSP Evaluator to check your policy for common weaknesses. Both are free.

What We'd Do Differently

Drop X-XSS-Protection. It's deprecated and ignored by modern browsers. Older IE versions had a bug where it could be exploited. We kept it because it doesn't actively hurt anything, but new implementations shouldn't bother.

Separate concerns if your team is large. Bundling all headers in one middleware works well for us, but a dedicated CspMiddleware is easier to unit test and simpler to replace later. Spatie's laravel-csp package gives you a structured, per-policy-class approach with first-class test support if you want to skip the custom build entirely.

Use hashes for truly static inline content. If you have a small piece of inline CSS that can't move to a stylesheet — a background colour from a database value, for example — CSP supports SHA-256 hashes as an alternative to nonces. You precompute the hash of the exact string and whitelist it. Surgical precision with no runtime overhead.

Explicitly exclude the api group from the middleware. Our implementation attaches the middleware to the web group, which already keeps it off pure API routes. If your app registers any routes globally — or if you ever move to a flat route file — API responses will silently start receiving a CSP header they don't need. Being explicit with a group exclusion is safer than relying on registration order:

// Laravel 11 — bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->web(append: [
        \App\Http\Middleware\SecureHeadersMiddleware::class,
    ]);
    // api group intentionally excluded — JSON responses don't need CSP
})

The Result

After two weeks in report-only mode and one afternoon of allowlist tuning, we flipped to enforcement. Our security headers score went from D to A+ on securityheaders.com.

Since then, csp-high-risk.log has caught two incidents where a third-party CDN attempted to inject tracking scripts we never authorised. The middleware caught what code review wouldn't have.

If you want to configure your own policy without writing it from scratch, the Laravel CSP Generator lets you do it visually — toggle your CDNs, integrations, and environment settings, and it outputs the full policy string and PHP middleware method ready to paste. The pre-enforcement checklist is built in and adapts to whatever you've configured.

CSP isn't a silver bullet — it's one layer in a defence-in-depth approach alongside CSRF protection, input validation, prepared statements, and HTTPS. But unlike most defences, it actively stops an entire class of attacks at the browser level, rather than hoping your application-layer defences caught everything upstream.

Start in report-only mode today. Watch your logs for a week. Then enforce. 🚀

Get the Quick Reference PDF

If you want a single document to keep open while you're building — the full directive reference, the pre-enforcement checklist, common mistakes, and quick-start snippets — I put it all in a 4-page PDF.

Drop your email below and it'll land in your inbox immediately. No series, no spam — just the PDF.

→ Get the Laravel CSP Quick Reference PDF

4 pages · All 13 directives · Pre-enforcement checklist · 5 common mistakes · Free

Frequently Asked Questions

Does CSP break existing Laravel apps?

It can — specifically if you have inline scripts or styles without nonces. Use Content-Security-Policy-Report-Only first to surface everything that would be blocked, fix your templates, then switch to enforcement. This is the only safe migration path for an app that's already in production.

Do I need CSP if I already have CSRF protection?

Yes. They protect against different attacks. CSRF prevents forged requests originating from other domains. CSP prevents injected scripts from running on your domain. One does not substitute for the other.

Do I need CSP if my app has no user-generated content?

Yes. XSS doesn't require users to submit anything. A vulnerable dependency, a compromised CDN script, or a DOM-based XSS through a URL parameter are all real attack vectors that have nothing to do with user uploads.

My Vite HMR stopped working after I added CSP. What's wrong?

Two things to check. First, confirm Vite::useCspNonce($nonce) is called before $next($request). Second, confirm connect-src includes ws://localhost:5173 (or your Vite port) in your local environment. HMR uses a WebSocket and fails silently if that WebSocket connection is blocked.

What's the difference between report-uri and Report-To?

report-uri is the original mechanism and is widely supported. Report-To is the newer Reporting API — reports are batched, the endpoint URL is cached by the browser for months, and it covers more than just CSP. Use both: report-uri as the universal fallback, Report-To for modern browsers. Alternatively, skip rolling your own and use report-uri.com.

How do I debug CSP violations locally?

Open DevTools → Console. Every CSP violation logs the exact blocked resource and the violated directive. That's your fastest debugging tool. If you're in report-only mode, the same violations also appear without anything actually breaking.

How do I handle CSP with Livewire?

Livewire injects inline JavaScript that needs the nonce. For v2: @livewireScripts(['nonce' => $cspNonce]). For v3: @livewireScriptConfig(['nonce' => $cspNonce]). Both are shown in Step 3 above.

What about Google Analytics or Tag Manager?

Add https://www.googletagmanager.com to script-src and https://www.google-analytics.com to both script-src and connect-src. GTM's custom HTML tags require 'unsafe-inline', which weakens your policy — server-side GTM or direct GA4 integration are cleaner alternatives worth the migration cost.

Can I use Spatie's laravel-csp package instead of a custom middleware?

Absolutely. Spatie's package provides a structured, per-policy-class approach with built-in nonce support and first-class test utilities. Our custom middleware made sense for us because we wanted every security header in one place without a package dependency. Either approach is valid — choose based on your team's preference for control versus convention.

Have you implemented CSP on a production Laravel app? Whether you had a smooth rollout, hit a rough edge with a third-party library, or are still sitting in report-only mode wondering what to do next — drop a comment. I'd love to hear where you got stuck, or what blocked resources surprised you most when you first flipped it on.

Prisma vs Eloquent, how to think about the two

Mohamed Idris — Fri, 08 May 2026 12:36:22 +0000

If you are coming from Laravel and trying out Prisma for the first time, the two ORMs feel surprisingly different even though they do the same job. This post walks through how each one thinks about your data, why the differences matter, and how to pick a mental model that fits the tool you are using.

The headline difference: where the truth lives

This is the single biggest thing to internalize.

Laravel Eloquent stores the truth in migration files.

You write migrations one at a time. Each migration is a step. The current shape of your database is the result of running all of them in order. The model class itself does not list your columns. It lists relations, accessors, mutators, and what is fillable, but if you want to know what columns the users table has, you read the latest migration that touched it.

Prisma stores the truth in schema.prisma.

You declare the whole shape of your database in one file. Models, fields, types, relations, indexes, all of it. When you run prisma migrate dev, Prisma compares the schema to the database and generates a migration that closes the gap. The migration files exist, but they are an output, not the source.

Laravel is history based. Prisma is state based.

Laravel mental model:
  migrations are the source -> running them produces the database

Prisma mental model:
  schema is the source -> Prisma generates migrations from it

Once that clicks, most of the other differences make sense.

The perfectionist take

If you are someone who likes a single clean view of your data, Prisma feels great. You open schema.prisma and you see everything: every model, every column, every relation, in one file. There is no hunting through dated migration files to figure out what the current shape is. There is no risk of the model class drifting from the migration. The schema file is the answer.

In Laravel, you can run into situations like this:

You add a status column in a new migration.
You forget to add status to the $fillable array on the model.
Now User::create(['status' => 'active']) silently does not save the field.

That kind of drift cannot happen in Prisma. The schema file is the only place you describe a column, and the generated client knows about every field automatically. There is nothing to remember to update on a separate model class.

The flip side: merge conflicts

Here is the trade off that bites teams using Prisma. Because everything lives in one file, that one file is a hot spot. If two developers add models on the same day, both branches edit schema.prisma, and you get a merge conflict.

Laravel rarely has this problem. Each migration is its own dated file. Two developers can add migrations in parallel and Git just stacks them. The order of files might shuffle a bit, but you usually do not have to manually resolve text conflicts in the same file.

So:

Topic	Laravel Eloquent	Prisma
Where the truth lives	Migration files	`schema.prisma`
Risk of model drifting	Real (model class vs migrations)	None (one source)
Merge conflicts in schema work	Rare	Common in busy teams
Reading current state	Read the latest migration	Read the schema file
Style	Imperative, history of changes	Declarative, snapshot of the world

Neither is wrong. They are different bets about where pain should land.

How migrations feel different

In Laravel, a migration is something you write by hand:

Schema::create('posts', function (Blueprint $table) {
    $table->id();
    $table->string('title');
    $table->text('body');
    $table->timestamps();
});

You wrote that file. You own it. When you change the schema, you write another migration that adds or alters columns.

In Prisma, you write the new shape into the schema file:

model Post {
  id    Int    @id @default(autoincrement())
  title String
  body  String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

Then you run prisma migrate dev --name add_posts, and Prisma writes the SQL migration for you. You almost never edit migration files by hand. They are an output.

This is freeing once you trust it, and a little uncomfortable when you do not. If you want full control over the SQL, Laravel feels safer. If you want to never write ALTER TABLE again, Prisma feels like a gift.

How models feel different

In Laravel, the model class is where logic lives:

class Post extends Model
{
    protected $fillable = ['title', 'body'];

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

It knows about relations, accessors, scopes, events, casts. The columns are implied from the migration plus the database itself.

In Prisma, the model is just a shape declaration. There is no class to extend, no custom methods, no scopes:

model Post {
  id       Int    @id @default(autoincrement())
  title    String
  body     String
  authorId Int
  author   User   @relation(fields: [authorId], references: [id])
}

Behavior lives in your application code, separate from the data definition. This is intentional. Prisma wants the schema to describe data and only data. Logic goes in services, controllers, repositories, wherever your architecture puts it.

If you love fat models with rich behavior, Laravel will feel more natural. If you prefer skinny data and behavior in plain functions, Prisma will feel cleaner.

How to pick a mental model

When working in Laravel, think:

"Each change to the database is a migration. The model class describes how to interact with the rows, not what the rows look like."

When working in Prisma, think:

"There is one schema file. I edit it to describe what the database should look like. Prisma figures out how to get there."

Trying to use the wrong mental model is where most frustration comes from. Writing Prisma like Laravel makes you fight the tool. Writing Laravel like Prisma misses the point of migrations as an audit trail.

Tiny rules of thumb

In Laravel, never edit a migration after it is shipped. Write a new one.
In Prisma, never edit a generated migration file. Change the schema instead and let Prisma rewrite it.
In Laravel, keep the model and migration in sync mentally. Always check $fillable and casts when you add columns.
In Prisma, when you start a new feature on a busy team, pull the latest main before editing the schema, just like you would for a package.json.

Final thought

Laravel's Eloquent and Prisma are not really competing in style, they are competing in philosophy. Laravel says "I will track every change you make." Prisma says "Tell me what you want, I will make it happen." Both are good answers. The right one depends on whether you would rather hold the history yourself or trust the tool to derive it.

If you came from Laravel and are giving Prisma an honest try, the perfectionist in you will probably enjoy having the schema in one place. Just be ready to coordinate a little more carefully when teammates are also touching that file.

DEV Community: laravel

I shipped Filament Studio 1.3.0, and it is the first version that feels AI-ready

What I added in v1.3.0

Why I think this matters

What changed for me conceptually

What this release is not

Full-Stack Laravel, React and MySQL Ecommerce Admin Panel

Who This Tutorial Is For

What We Are Going To Learn

Watch The Full Series

What We Are Building

Required Tools

What Is Laravel?

What Is React?

What Is MySQL?

What Is REST API?

What Is Laravel Sanctum?

What Is Vite?

Step 1: Create Laravel Backend

Step 2: Understand API Routes

Step 3: Database Design

Step 4: Create Models and Migrations

Step 5: Category Model

Step 6: Product Model

Step 7: Build Category REST API

Step 8: Test Category API With Postman

Step 9: Build Product REST API With Image Upload

Step 10: Authentication With Laravel Sanctum

Step 11: Create React Frontend With Vite

Step 12: Create API Helper File in React

Step 13: React Login Page

Step 14: React Admin Layout

Step 15: Category Management in React

Step 16: Product Management in React

Step 17: Show Uploaded Product Image

Step 18: Final Dashboard

Full API Endpoints

Common Issues and Fixes

CORS or API Not Connecting

Database Error

Image Not Showing

Unauthorized Request

Full Series Roadmap

Final Project Flow

What You Should Practice Next

GitHub Repository

Conclusion

Optimize Laravel Performance: Database, Caching, and Queues

The Performance Problem

Part 1: Database Query Optimization

Detect N+1 Problems

Eager Loading Multiple Relationships

Constraint Eager Loading

Select Only Required Columns

Chunk Large Datasets

Part 2: Database Indexing

Identify Missing Indexes

Add Indexes via Migrations

Index Strategy

Part 3: Caching Strategies

Basic Caching

Cache User-Specific Data

Cache Configuration

HTTP Caching

Part 4: Queue Management

Offload Heavy Tasks

Job Implementation

Queue Configuration

Queue Workers

Part 5: Response Optimization

API Resource Collections

Pagination

Response Compression

Part 6: Configuration Optimization

Optimize Composer Autoloader

Laravel Optimization Commands

Environment Configuration

Part 7: Monitoring and Debugging

Query Monitoring

Performance Metrics

What I added in `v1.3.0`

`from()` ve `tryFrom()` farkı