Bạn hoàn toàn có thể dùng AdminLTE trong Laravel 13 với cơ chế @vite , vì hiện nay AdminLTE đã có gói chính thức cho Laravel hỗ trợ Vite-first pipeline.

Điều này giúp bạn vừa tận dụng thư viện cũ, vừa đảm bảo bảo mật, minify và tree-shaking.

🔑 Cách tích hợp AdminLTE với Laravel 13 qua Vite

1. Cài đặt gói chính thức

• Chạy lệnh Composer:

  composer require colorlibhq/adminlte-laravel

• Sau đó chạy artisan installer:

  php artisan adminlte:install

👉 Lệnh này sẽ:

• Xuất file cấu hình config/adminlte.php.

• Tạo stub cho Vite tại resources/js/adminlte.js và resources/css/adminlte.css.

• Cài đặt các dependency frontend (AdminLTE, Bootstrap 5.3, Popper, Icons, ApexCharts, v.v.).

2. Cấu hình Vite

Trong vite.config.js, thêm entry cho AdminLTE:

import { defineConfig } from 'vite'
import laravel from 'laravel-vite-plugin'

export default defineConfig({
  plugins: [
    laravel({
      input: [
        'resources/css/adminlte.css',
        'resources/js/adminlte.js',
      ],
      refresh: true,
    }),
  ],
})

👉 Nhờ vậy, khi chạy npm run build, toàn bộ asset sẽ được minify, hash và tree-shake để tăng bảo mật.

3. Tạo trang đầu tiên

Ví dụ resources/views/dashboard.blade.php:

@extends('adminlte::page')

@section('title', 'Dashboard')

@section('content_header')
    <h3 class="mb-0">Dashboard</h3>
@stop

@section('content')
    <x-adminlte-info-box title="Orders" text="150" icon="bi bi-bag" theme="primary" />
@stop

👉 Các component <x-adminlte-*> được cung cấp sẵn, không cần copy HTML thủ công.

⚠️ Lưu ý bảo mật & hiệu năng

• Luôn dùng Vite build cho production (npm run build) để đảm bảo asset được minify và hash.
• Không nên copy thủ công CSS/JS vào public/ như cách cũ, vì dễ lỗi bảo mật và khó maintain.
• Chỉ bật plugin cần thiết trong config/adminlte.php để giảm dung lượng bundle.
• Kiểm tra bằng lệnh php artisan adminlte:status để biết tài nguyên nào đã được cài đặt.

👉 Nếu bạn muốn giữ nguyên AdminLTE 3 nhưng vẫn dùng @vite, bạn phải tự import thủ công từ npm (admin-lte@^3) và cấu hình entry trong vite.config.js. Tuy nhiên, giải pháp tốt nhất là chuyển sang AdminLTE 4 vì đã có package chính thức cho Laravel 13.

4. Gọi trong Blade

@vite(['resources/css/app.css', 'resources/js/app.js'])

📌 Lưu ý

• Nếu bạn dùng AdminLTE 4, nó đã tích hợp sẵn Bootstrap 5.3, nên không cần cài riêng.
• Nếu bạn muốn tuỳ biến theme, hãy dùng app.scss thay vì app.css để override biến của Bootstrap.
• Khi build production (npm run build), Vite sẽ tự động minify, hash và tree-shake → bảo mật và tối ưu dung lượng.

⚙️ Cài đặt Font Awesome

1. Cài qua npm

npm install @fortawesome/fontawesome-free

2. Import vào entry file

Trong resources/js/app.js:

import '@fortawesome/fontawesome-free/js/all.js';

Trong resources/css/app.css (hoặc app.scss):

@import "@fortawesome/fontawesome-free/css/all.min.css";

3. Cấu hình Vite

Trong vite.config.js, đảm bảo đã khai báo:

import { defineConfig } from 'vite'
import laravel from 'laravel-vite-plugin'

export default defineConfig({
  plugins: [
    laravel({
      input: [
        'resources/css/app.css',
        'resources/js/app.js',
      ],
      refresh: true,
    }),
  ],
})

4. Gọi trong Blade

@vite(['resources/css/app.css', 'resources/js/app.js'])

Sau đó bạn có thể dùng icon:

<i class="fas fa-user"></i>
<i class="fab fa-laravel"></i>

📌 Lưu ý

• Nếu bạn đã cài AdminLTE 4, nó cũng có thể tích hợp sẵn Font Awesome 6, nên không cần cài riêng.
• Nếu muốn dùng chỉ một subset icon để giảm dung lượng, bạn có thể import theo module thay vì toàn bộ all.js.
• Khi build production (npm run build), Vite sẽ tự động minify và hash để tăng bảo mật.

REST API là cầu nối để Laravel giao tiếp với Website, JavaScript, Mobile App hoặc các hệ thống khác thông qua HTTP và dữ liệu JSON.

Ở phần trước, chúng ta đã hoàn thành Logging & Debug.

Từ bài này, chúng ta bước sang:

🌐 PHẦN 9 — REST API

Gồm:

• Bài 41 — REST API

• Bài 42 — API Resource

• Bài 43 — Sanctum

• Bài 44 — API Authentication

Mục tiêu của phần này là biến Laravel từ một Website thông thường thành một Backend API có thể cung cấp dữ liệu cho nhiều loại ứng dụng khác nhau.

1. REST API là gì?

Khi xây dựng một Website Laravel truyền thống:

Browser
   ↓
Laravel
   ↓
Blade
   ↓
HTML

Laravel xử lý request rồi trả về HTML để trình duyệt hiển thị.

Ví dụ:

GET /blog

Laravel trả về:

<html>
    ...
</html>

Nhưng với API, cách hoạt động sẽ khác:

Website
Mobile App
JavaScript
React
Vue
Next.js
   ↓
REST API
   ↓
Laravel
   ↓
Database

Laravel không nhất thiết trả về HTML.

Thay vào đó, Laravel trả về:

{
    "id": 1,
    "title": "Laravel 13 là gì?"
}

Đây chính là nền tảng của API.

2. API là gì?

API là viết tắt của:

Application Programming Interface

Có thể hiểu đơn giản:

API là một "cổng giao tiếp" cho phép các chương trình trao đổi dữ liệu với nhau.

Ví dụ Blog CMS của chúng ta có bài viết:

ID: 1
Title: Laravel 13 là gì?
Category: Laravel

Website có thể lấy dữ liệu bằng:

GET /api/posts

Laravel trả về:

[
    {
        "id": 1,
        "title": "Laravel 13 là gì?"
    },
    {
        "id": 2,
        "title": "Routing trong Laravel 13"
    }
]

Một ứng dụng mobile có thể gọi chính API đó.

Một ứng dụng React cũng có thể gọi.

Một ứng dụng Vue cũng có thể gọi.

Như vậy:

                 ┌── Website
                 │
                 ├── Mobile App
                 │
Laravel API ─────┼── React
                 │
                 ├── Vue
                 │
                 └── Third-party App

Backend chỉ cần cung cấp API.

3. REST là gì?

REST là viết tắt của:

Representational State Transfer

REST không phải là một thư viện.

REST là một phong cách thiết kế API dựa trên HTTP.

Ví dụ chúng ta có đối tượng:

Post

API có thể thiết kế:

GET     /api/posts
GET     /api/posts/1
POST    /api/posts
PUT     /api/posts/1
DELETE  /api/posts/1

Nhìn vào URL và HTTP method, chúng ta có thể hiểu API đang làm gì.

4. CRUD và REST API

REST API rất phù hợp với CRUD.

Có thể hình dung:

              POSTS API

GET     /api/posts
        ↓
        Danh sách bài viết


GET     /api/posts/1
        ↓
        Chi tiết bài viết


POST    /api/posts
        ↓
        Tạo bài viết


PUT     /api/posts/1
        ↓
        Cập nhật bài viết


DELETE  /api/posts/1
        ↓
        Xóa bài viết

Đây là cấu trúc rất phổ biến khi thiết kế REST API.

5. HTTP Methods

REST API sử dụng các HTTP method chính.

GET

Dùng để lấy dữ liệu.

GET /api/posts

Ví dụ:

Lấy danh sách bài viết

POST

Dùng để tạo dữ liệu mới.

POST /api/posts

Ví dụ gửi:

{
    "title": "Laravel 13 REST API",
    "category_id": 1
}

PUT

Thường dùng để cập nhật toàn bộ resource.

PUT /api/posts/1

PATCH

Thường dùng để cập nhật một phần resource.

PATCH /api/posts/1

Ví dụ chỉ thay đổi:

{
    "title": "Laravel 13 API"
}

DELETE

Dùng để xóa resource.

DELETE /api/posts/1

6. API trả về JSON

Một trong những điểm quan trọng nhất khi xây dựng API là dữ liệu thường được trao đổi dưới dạng JSON.

Ví dụ:

{
    "id": 1,
    "title": "Laravel 13",
    "status": "published"
}

Laravel có thể trả về JSON rất đơn giản.

Ví dụ:

return response()->json([
    'message' => 'Hello API'
]);

Kết quả:

{
    "message": "Hello API"
}

Laravel cũng có thể tự chuyển array thành JSON response trong nhiều trường hợp.

7. Laravel 13 và API routes

Một điểm rất quan trọng đối với người học Laravel hiện nay:

Laravel không nhất thiết tạo sẵn routes/api.php trong một project mới.

API routing là phần có thể cài đặt thêm.

Trong Laravel, chúng ta có thể sử dụng:

php artisan install:api

Lệnh này dùng để cài đặt API routing và chuẩn bị cấu trúc cần thiết cho API.&

Laravel cũng sử dụng lệnh này trong quá trình thiết lập Sanctum ở các phiên bản hiện đại.

Sau khi chạy:

php artisan install:api

project sẽ có thêm:

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

8. web.php và api.php

Có thể hiểu đơn giản:

routes/web.php

Dành cho Website:

Browser
   ↓
web.php
   ↓
Controller
   ↓
Blade
   ↓
HTML

routes/api.php

Dành cho API:

Client
   ↓
api.php
   ↓
Controller
   ↓
JSON

API routes hướng tới các request stateless, khác với nhóm route web vốn có session, cookie và CSRF protection.

9. Tạo API route đầu tiên

Sau khi chạy:

php artisan install:api

mở:

routes/api.php

Thêm:

<?php

use Illuminate\Support\Facades\Route;

Route::get('/hello', function () {
    return response()->json([
        'message' => 'Hello Laravel 13 API'
    ]);
});

Chạy Laravel:

php artisan serve

Sau đó truy cập:

http://127.0.0.1:8000/api/hello

Kết quả:

{
    "message": "Hello Laravel 13 API"
}

Chúng ta vừa tạo API đầu tiên.

10. Vì sao có /api?

Khi route được khai báo trong API routing:

Route::get('/hello', ...);

URL API thường sẽ là:

/api/hello

Thay vì:

/hello

Do đó:

routes/api.php

có thể chứa:

Route::get('/posts', ...);

và client gọi:

GET /api/posts

11. API lấy danh sách Posts

Bây giờ chúng ta áp dụng vào Blog CMS.

Model:

app/Models/Post.php

Trong:

routes/api.php

có thể viết:

use App\Models\Post;
use Illuminate\Support\Facades\Route;

Route::get('/posts', function () {
    return Post::all();
});

Truy cập:

GET /api/posts

Laravel có thể chuyển Eloquent model hoặc collection thành JSON response.

Ví dụ kết quả:

[
    {
        "id": 1,
        "user_id": 1,
        "category_id": 2,
        "title": "Laravel 13 là gì?",
        "slug": "laravel-13-la-gi",
        "status": "published"
    },
    {
        "id": 2,
        "user_id": 1,
        "category_id": 3,
        "title": "Laravel Routing",
        "slug": "laravel-routing",
        "status": "published"
    }
]

12. Nhưng không nên nhét quá nhiều logic vào route

Đoạn này:

Route::get('/posts', function () {
    return Post::all();
});

chạy được.

Nhưng khi project lớn lên, chúng ta không nên đưa toàn bộ logic vào route.

Thay vào đó:

Route
   ↓
Controller
   ↓
Model
   ↓
Database

Đây cũng chính là cách chúng ta đã học ở những bài Controller và CRUD trước đó.

13. Tạo API Controller

Chạy:

php artisan make:controller Api/PostController

Laravel tạo:

app/
└── Http/
    └── Controllers/
        └── Api/
            └── PostController.php

Mở file:

app/Http/Controllers/Api/PostController.php

Viết:

<?php

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Models\Post;

class PostController extends Controller
{
    public function index()
    {
        return Post::all();
    }
}

14. Kết nối Route với Controller

Mở:

routes/api.php

Viết:

<?php

use App\Http\Controllers\Api\PostController;
use Illuminate\Support\Facades\Route;

Route::get('/posts', [PostController::class, 'index']);

Bây giờ:

GET /api/posts

sẽ chạy:

PostController@index

Luồng hoạt động:

GET /api/posts
       ↓
routes/api.php
       ↓
PostController@index
       ↓
Post::all()
       ↓
Database
       ↓
JSON

15. API lấy một Post

Thêm vào Controller:

public function show(Post $post)
{
    return $post;
}

Route:

Route::get('/posts/{post}', [PostController::class, 'show']);

Bây giờ:

GET /api/posts/1

Laravel sẽ tìm:

Post ID = 1

và trả về JSON.

Ví dụ:

{
    "id": 1,
    "title": "Laravel 13 là gì?",
    "slug": "laravel-13-la-gi",
    "status": "published"
}

Đây chính là Route Model Binding mà chúng ta đã học ở phần Routing.

16. API chỉ lấy bài Published

Trong Blog CMS, chúng ta không muốn API công khai trả về tất cả bài viết.

Ví dụ:

draft
hidden
scheduled

không nên xuất hiện trong API public.

Model Post của chúng ta đã có scope:

Post::published()

Do đó Controller có thể viết:

public function index()
{
    return Post::published()
        ->with(['user', 'category'])
        ->latest('published_at')
        ->paginate(10);
}

Khi đó:

GET /api/posts

chỉ lấy những bài đã publish.

Đây chính là cách kết hợp:

Eloquent
+
Scope
+
Relationship
+
Pagination
+
REST API

17. API response có cấu trúc rõ ràng

Thay vì trả thẳng:

return Post::all();

chúng ta có thể tạo response:

return response()->json([
    'success' => true,
    'data' => Post::all()
]);

Kết quả:

{
    "success": true,
    "data": [
        {
            "id": 1,
            "title": "Laravel 13 là gì?"
        },
        {
            "id": 2,
            "title": "Laravel Routing"
        }
    ]
}

Cách này giúp client dễ xử lý response.

18. HTTP Status Code

API không chỉ trả dữ liệu.

API còn cần trả về HTTP status code phù hợp.

Một số status code quan trọng:

Ví dụ lấy dữ liệu thành công:

return response()->json([
    'data' => $posts
], 200);

19. API tạo Post(---)

Ví dụ:

public function store(Request $request)
{
    $post = Post::create([
        'user_id' => $request->user()->id,
        'title' => $request->title,
        'slug' => $request->slug,
        'content' => $request->content,
    ]);

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

Nhớ import:

use Illuminate\Http\Request;

Client gửi:

POST /api/posts

Body:

{
    "title": "Laravel 13 REST API",
    "slug": "laravel-13-rest-api",
    "content": "..."
}

Nếu tạo thành công:

HTTP 201 Created

Ghi chú:

lấy hàm store trong Bài 27 — CRUD Posts rồi sửa khúc return là xong.

20. Validation cho API

API vẫn cần Validation giống Website.

Ví dụ:

$request->validate([
    'title' => ['required', 'string', 'max:255'],
    'slug' => ['required', 'string', 'max:255'],
    'content' => ['required', 'string'],
]);

Nếu dữ liệu không hợp lệ, Laravel có thể trả về lỗi validation dưới dạng JSON đối với request API.

Ví dụ client có thể nhận:

{
    "message": "The title field is required.",
    "errors": {
        "title": [
            "The title field is required."
        ]
    }
}

API client có thể dùng thông tin này để hiển thị lỗi cho người dùng.

21. API Update

Ví dụ:

public function update(Request $request, Post $post)
{
    $request->validate([
        'title' => ['required', 'string', 'max:255'],
        'content' => ['required', 'string'],
    ]);

    $post->update([
        'title' => $request->title,
        'content' => $request->content,
    ]);

    return response()->json([
        'message' => 'Post updated successfully',
        'data' => $post
    ]);
}

Route:

Route::put('/posts/{post}', [PostController::class, 'update']);

Client:

PUT /api/posts/1

22. API Delete

Controller:

public function destroy(Post $post)
{
    $post->delete();

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

Route:

Route::delete('/posts/{post}', [PostController::class, 'destroy']);

Client:

DELETE /api/posts/1

Có thể trả về:

{
    "message": "Post deleted successfully"
}

23. Resource Controller cho API

Thay vì khai báo từng route:

Route::get('/posts', ...);
Route::get('/posts/{post}', ...);
Route::post('/posts', ...);
Route::put('/posts/{post}', ...);
Route::delete('/posts/{post}', ...);

Laravel hỗ trợ resource routing.

Ví dụ:

Route::apiResource('posts', PostController::class);

Lúc này Laravel tạo nhóm route CRUD cho API.

Có thể kiểm tra bằng:

php artisan route:list

Hoặc:

php artisan route:list --path=api

Bạn sẽ thấy các route tương ứng với:

GET       /api/posts
POST      /api/posts
GET       /api/posts/{post}
PUT/PATCH /api/posts/{post}
DELETE    /api/posts/{post}

Đây là cách rất phù hợp cho Blog CMS.

24. Hoàn chỉnh PostController cơ bản

Sau khi học xong phần này, chúng ta có thể hình dung Controller:

<?php

namespace App\Http\Controllers\Api;

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

class PostController extends Controller
{
    public function index()
    {
        $posts = Post::published()
            ->with(['user', 'category'])
            ->latest('published_at')
            ->paginate(10);

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

    public function show(Post $post)
    {
        return response()->json([
            'success' => true,
            'data' => $post
        ]);
    }

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

        $post = Post::create([
            ...$validated,
            'user_id' => $request->user()->id,
        ]);

        return response()->json([
            'success' => true,
            'message' => 'Post created successfully',
            'data' => $post
        ], 201);
    }

    public function update(Request $request, Post $post)
    {
        $validated = $request->validate([
            'title' => ['required', 'string', 'max:255'],
            'slug' => ['required', 'string', 'max:255'],
            'content' => ['required', 'string'],
        ]);

        $post->update($validated);

        return response()->json([
            'success' => true,
            'message' => 'Post updated successfully',
            'data' => $post
        ]);
    }

    public function destroy(Post $post)
    {
        $post->delete();

        return response()->json([
            'success' => true,
            'message' => 'Post deleted successfully'
        ]);
    }
}

Đây là API Controller cơ bản.

Tuy nhiên, trong dự án thực tế chúng ta sẽ chưa dừng ở đây.

25. Route API hoàn chỉnh

routes/api.php:

<?php

use App\Http\Controllers\Api\PostController;
use Illuminate\Support\Facades\Route;

Route::apiResource('posts', PostController::class);

Kết quả:

GET       /api/posts
POST      /api/posts
GET       /api/posts/{post}
PUT       /api/posts/{post}
PATCH     /api/posts/{post}
DELETE    /api/posts/{post}

Đây chính là REST API cho resource:

posts

26. Test API bằng trình duyệt

Các request GET đơn giản có thể test trực tiếp bằng trình duyệt.

Ví dụ:

http://127.0.0.1:8000/api/posts

Hoặc:

http://127.0.0.1:8000/api/posts/1

Browser sẽ hiển thị JSON.

Ví dụ:

{
    "success": true,
    "data": {
        "id": 1,
        "title": "Laravel 13"
    }
}

27. Test API bằng Postman

Khi API có:

GET
POST
PUT
PATCH
DELETE

thì Postman sẽ thuận tiện hơn trình duyệt.

Ví dụ:

GET
http://127.0.0.1:8000/api/posts

POST:

POST
http://127.0.0.1:8000/api/posts

Body:

{
    "title": "Bài viết mới",
    "slug": "bai-viet-moi",
    "content": "Nội dung bài viết"
}

PUT:

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

DELETE:

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

Như vậy Postman có thể đóng vai trò như một client của Laravel API.

28. API không phải là Website

Đây là điểm người mới học Laravel rất dễ nhầm.

Website:

GET /blog
        ↓
Controller
        ↓
Blade
        ↓
HTML

API:

GET /api/posts
        ↓
Controller
        ↓
Eloquent
        ↓
JSON

Hai thứ đều sử dụng Laravel.

Nhưng mục đích khác nhau.

29. Một API có thể phục vụ nhiều ứng dụng

Ví dụ chúng ta có:

                 Laravel 13 API
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
       Website      Android        iOS
          │            │            │
          └────────────┼────────────┘
                       ↓
                    Database

API trở thành tầng trung gian giữa frontend và database.

Ví dụ:

GET /api/posts

Website lấy dữ liệu.

Mobile App cũng gọi:

GET /api/posts

Một ứng dụng React cũng có thể gọi:

GET /api/posts

Không cần xây dựng ba hệ thống backend riêng biệt.

30. REST API trong Blog CMS của chúng ta

Project hiện tại có:

users
categories
posts

Sau khi hoàn thành phần API, chúng ta có thể xây dựng:

/api/posts
/api/categories
/api/users

Ví dụ:

GET /api/posts
GET /api/posts/1

GET /api/categories
GET /api/categories/1

Sau này có thể phát triển tiếp:

POST   /api/posts
PUT    /api/posts/1
DELETE /api/posts/1

Nhưng vấn đề tiếp theo xuất hiện:

Dữ liệu trả về có nên được đưa thẳng từ Model ra JSON hay không?

Ví dụ Model Post có:

user_id
category_id
view_count
created_at
updated_at

Trong khi frontend có thể chỉ cần:

id
title
slug
excerpt
image
published_at
category
author

Đây chính là lý do chúng ta cần học API Resource.

31. API Resource giải quyết vấn đề gì?

Hiện tại:

return $post;

Laravel có thể chuyển Model thành JSON.

Nhưng chúng ta không kiểm soát tốt cấu trúc dữ liệu.

API Resource cho phép định nghĩa:

Model
  ↓
Resource
  ↓
JSON

Ví dụ:

Post
 ↓
PostResource
 ↓
{
    id,
    title,
    slug,
    excerpt,
    image,
    category,
    author
}

Đây sẽ là nội dung của:

👉 Bài 42 — API Resource

32. API và bảo mật

Một API public không có nghĩa là:

Ai cũng được phép làm mọi thứ.

Ví dụ:

GET /api/posts

có thể public.

Nhưng:

POST /api/posts
PUT /api/posts/1
DELETE /api/posts/1

thì cần kiểm tra người dùng.

Có thể cần:

Authentication
Authorization
Token
Permission
Policy

Đây chính là phần chúng ta sẽ học tiếp trong:

Bài 43 — Sanctum
Bài 44 — API Authentication

Vì vậy trong bài này chúng ta mới chỉ xây dựng REST API cơ bản.

33. Kiến trúc REST API của Blog CMS

Sau khi hoàn thành Phần 9, kiến trúc sẽ có dạng:

                    Laravel 13
                        │
             ┌──────────┴──────────┐
             │                     │
          Website                  API
             │                     │
          web.php               api.php
             │                     │
          Controller            Controller
             │                     │
          Blade                Resource
             │                     │
           HTML                  JSON
             │                     │
             └──────────┬──────────┘
                        ↓
                     Eloquent
                        ↓
                     MySQL

Đây là một bước rất quan trọng trong quá trình chuyển từ:

Laravel Website

sang:

Laravel Backend API

34. Bài tập thực hành

Bài tập 1

Cài API routing:

php artisan install:api

Kiểm tra:

routes/api.php

Bài tập 2

Tạo:

/api/hello

Trả về:

{
    "message": "Hello Laravel 13 API"
}

Bài tập 3

Tạo:

GET /api/posts

Trả về danh sách Post.

Bài tập 4

Tạo:

GET /api/posts/{post}

Trả về một Post.

Bài tập 5

Tạo REST CRUD:

GET       /api/posts
GET       /api/posts/{post}
POST      /api/posts
PUT       /api/posts/{post}
DELETE    /api/posts/{post}

Có thể sử dụng:

Route::apiResource('posts', PostController::class);

Bài tập 6

Dùng Postman kiểm tra:

GET
POST
PUT
DELETE

và quan sát:

HTTP Status Code
JSON Response
Validation Error

35. Tổng kết

Trong bài này, chúng ta đã làm quen với:

• REST API

• API là gì?

• REST là gì?

• HTTP Methods

• GET

• POST

• PUT

• PATCH

• DELETE

• JSON

• API routes

• php artisan install:api

• routes/api.php

• API Controller

• Route Model Binding

• response()->json()

• HTTP Status Code

• Validation

• Route::apiResource()

• Test API bằng Browser

• Test API bằng Postman

• REST API trong Blog CMS

Quan trọng nhất cần nhớ:

Website
   ↓
HTML

API
   ↓
JSON

Và:

GET     → Read
POST    → Create
PUT     → Update
PATCH   → Update một phần
DELETE  → Delete

Một REST API cơ bản của Blog CMS:

/api/posts
/api/posts/{post}

có thể trở thành backend dùng chung cho:

Website
Mobile App
React
Vue
Next.js
Third-party Application

🎯 Lộ trình tiếp theo

Chúng ta đã có REST API.

Nhưng response hiện tại vẫn còn khá "thô":

return $post;

hoặc:

return Post::all();

Ở bài tiếp theo, chúng ta sẽ học cách kiểm soát chính xác dữ liệu JSON trả về bằng:

🚀 BÀI 42 — API RESOURCE

Luồng xử lý sẽ trở thành:

Database
    ↓
Eloquent Model
    ↓
API Resource
    ↓
JSON
    ↓
Frontend / Mobile App

Đây là bước rất quan trọng để biến API Laravel thành một API có cấu trúc rõ ràng và phù hợp với dự án thực tế.

Khi ứng dụng còn nhỏ, chúng ta có thể nhìn vào màn hình và đoán lỗi.

Nhưng khi Blog CMS bắt đầu có nhiều Controller, Model, Middleware, Event, Queue, Mail, Cache và Storage thì việc theo dõi hoạt động của ứng dụng trở nên rất quan trọng.

Laravel cung cấp hệ thống Logging và nhiều công cụ Debug giúp chúng ta biết:

• Request nào đang xảy ra.

• Query nào được thực thi.

• Exception nào xuất hiện.

• User nào đang thực hiện hành động.

• Queue nào đang chạy.

• Ứng dụng đang gặp vấn đề ở đâu.

Trong bài này chúng ta tìm hiểu ba công cụ chính:

Log
Debugbar
Telescope

1. Logging là gì?

Logging là quá trình ghi lại thông tin hoạt động của ứng dụng.

Ví dụ:

User đăng nhập
Post được tạo
Post được cập nhật
File được upload
Email được gửi
Exception xảy ra

Thay vì chỉ nhìn thấy:

500 Server Error

Log có thể cho chúng ta biết:

16:20:31
PostController@update

Post ID: 25

Image upload failed

Nhờ đó việc tìm lỗi trở nên dễ dàng hơn.

2. Laravel Logging

Laravel sử dụng hệ thống Logging dựa trên:

Monolog

Ứng dụng có thể ghi Log thông qua:

use Illuminate\Support\Facades\Log;

Ví dụ:

Log::info('Laravel 13 đang chạy');

3. Log các mức độ khác nhau

Laravel cung cấp nhiều Log level.

Một số level thường gặp:

emergency
alert
critical
error
warning
notice
info
debug

Có thể hình dung:

Emergency
    ↑
Alert
    ↑
Critical
    ↑
Error
    ↑
Warning
    ↑
Notice
    ↑
Info
    ↑
Debug

Trong ứng dụng thông thường, chúng ta thường sử dụng:

Log::debug();
Log::info();
Log::warning();
Log::error();

4. Log::info()

Dùng để ghi thông tin hoạt động bình thường:

Log::info('User đã đăng nhập');

Ví dụ trong Controller:

Log::info('Post được tạo thành công');

5. Log::warning()

Dùng khi có vấn đề cần chú ý nhưng chưa phải lỗi nghiêm trọng:

Log::warning(
    'Post chưa có hình ảnh'
);

Ví dụ:

if (!$post->image) {
    Log::warning(
        'Post không có image',
        [
            'post_id' => $post->id,
        ]
    );
}

6. Log::error()

Dùng khi xảy ra lỗi:

Log::error(
    'Không thể upload image'
);

Có thể truyền thêm context:

Log::error(
    'Không thể upload image',
    [
        'post_id' => $post->id,
    ]
);

Kết quả Log sẽ có thêm thông tin giúp chúng ta xác định lỗi.

7. Log::debug()

debug() thường được sử dụng trong quá trình phát triển:

Log::debug(
    'Post update',
    [
        'post_id' => $post->id,
    ]
);

Ví dụ:

Post update
post_id = 15

Điều này rất hữu ích khi muốn theo dõi flow của code.

8. Log Context

Một trong những tính năng quan trọng của Log là Context.

Thay vì:

Log::info('Post updated');

ta có thể:

Log::info(
    'Post updated',
    [
        'post_id' => $post->id,
        'user_id' => auth()->id(),
    ]
);

Khi đó Log không chỉ nói:

Post updated

mà còn biết:

post_id
user_id

Đây là thói quen rất tốt khi xây dựng ứng dụng thực tế.

9. Log File mặc định

Laravel mặc định có thể ghi Log vào:

storage/logs/

Ví dụ:

storage/
└── logs/
    └── laravel.log

Khi ứng dụng xảy ra lỗi hoặc chúng ta gọi:

Log::error(...)

thông tin có thể được ghi vào file Log.

10. Ví dụ đọc Log

Ví dụ Log:

Log::info(
    'Post created',
    [
        'post_id' => 25,
        'user_id' => 1,
    ]
);

Sau đó mở:

storage/logs/laravel.log

ta có thể tìm thấy thông tin tương ứng.

11. Log trong Blog CMS

Ví dụ khi tạo Post:

$post = Post::create($validated);

Log::info(
    'Post created',
    [
        'post_id' => $post->id,
        'user_id' => auth()->id(),
    ]
);

Khi cập nhật:

Log::info(
    'Post updated',
    [
        'post_id' => $post->id,
        'user_id' => auth()->id(),
    ]
);

Khi xóa:

Log::info(
    'Post deleted',
    [
        'post_id' => $post->id,
        'user_id' => auth()->id(),
    ]
);

Như vậy chúng ta có thể theo dõi các hoạt động quan trọng của Blog CMS.

12. try / catch và Log

Có thể kết hợp Exception với Log:

try {

    $post->update($validated);

} catch (\Throwable $e) {

    Log::error(
        'Post update failed',
        [
            'post_id' => $post->id,
            'error' => $e->getMessage(),
        ]
    );

    throw $e;
}

Điều này giúp ghi lại lỗi trước khi Exception tiếp tục được xử lý.

13. Log Exception

Có thể ghi trực tiếp Exception:

try {

    // Code

} catch (\Throwable $e) {

    Log::error(
        'Unexpected error',
        [
            'exception' => $e,
        ]
    );

    throw $e;
}

Thông tin Exception giúp quá trình Debug dễ dàng hơn rất nhiều.

14. Logging không chỉ dành cho lỗi

Một quan niệm sai:

Log = Error

Không đúng.

Log có thể dùng để theo dõi:

Application Flow
User Activity
Business Event
Warning
Error
Performance

Ví dụ:

Log::info('Post published');

không phải lỗi.

Nó chỉ là thông tin quan trọng về hoạt động của hệ thống.

15. Logging Channel

Laravel hỗ trợ nhiều Log Channel.

Có thể hình dung:

Laravel
   │
   └── Logging
        │
        ├── single
        ├── daily
        ├── stack
        └── ...

Cấu hình nằm tại:

config/logging.php

16. Daily Log

Một cấu hình thường dùng là Daily Log.

Thay vì:

laravel.log

mọi thứ dồn vào một file rất lớn, có thể chia theo ngày:

laravel-2026-09-13.log
laravel-2026-09-14.log
laravel-2026-09-15.log

Điều này thuận tiện khi hệ thống hoạt động lâu dài.

17. Log Channel trong Code

Có thể chỉ định channel:

Log::channel('daily')->info(
    'Post created'
);

Nếu project có channel riêng:

Log::channel('payments')->error(
    'Payment failed'
);

Nhờ vậy những loại Log khác nhau có thể được tách riêng.

18. Debug là gì?

Debug là quá trình tìm nguyên nhân khiến chương trình hoạt động không đúng.

Ví dụ:

Form
 ↓
Request
 ↓
Controller
 ↓
Validation
 ↓
Model
 ↓
Database

Nếu dữ liệu không được lưu:

Lỗi nằm ở đâu?

Có thể là:

Form
Request
Validation
Controller
Model
Database

Debug giúp chúng ta tìm chính xác vị trí đó.

19. APP_DEBUG

Laravel có biến:

APP_DEBUG=true

Khi phát triển Local:

APP_DEBUG=true

có thể giúp hiển thị thông tin Debug chi tiết khi xảy ra Exception.

Ví dụ:

Exception
File
Line
Stack Trace

20. Production phải tắt Debug

Khi Deploy:

APP_ENV=production
APP_DEBUG=false

Không nên để:

APP_DEBUG=true

trên Website thật.

Bởi vì thông tin Debug có thể tiết lộ:

File path
Database information
Environment information
Stack trace
Application internals

Đây là vấn đề bảo mật.

21. dd()

Trong Laravel có:

dd();

Tên của nó có thể hiểu là:

Dump and Die

Ví dụ:

dd($post);

Laravel sẽ:

Hiển thị dữ liệu
      ↓
Dừng chương trình

22. dd() với nhiều biến

dd(
    $request->all(),
    $post,
    $user
);

Rất hữu ích khi Debug Controller.

Ví dụ:

public function update(Request $request, Post $post)
{
    dd(
        $request->all(),
        $post
    );

    // ...
}

23. dump()

Khác với:

dd()

dump() không dừng chương trình.

dump($post);

Sau đó code vẫn tiếp tục chạy.

Có thể:

dump($request->all());

$post->update($validated);

Trong Debug nhanh:

dump()
    ↓
xem dữ liệu
    ↓
tiếp tục chạy

Còn:

dd()
    ↓
xem dữ liệu
    ↓
dừng

24. Debugbar

Một công cụ rất phổ biến trong Laravel development là:

Laravel Debugbar

Package phổ biến:

barryvdh/laravel-debugbar

Debugbar có thể giúp quan sát:

Queries
Time
Memory
Route
Views
Events

Tùy cấu hình và phiên bản package.

25. Cài Laravel Debugbar

Trong môi trường development:

composer require barryvdh/laravel-debugbar --dev

Điểm quan trọng là:

--dev

Debugbar phục vụ quá trình phát triển, không phải chức năng người dùng cuối.

26. Debugbar hoạt động như thế nào?

Sau khi cài đặt, khi mở Website ở môi trường Local, Debugbar thường xuất hiện ở phía dưới trang.

Có thể hình dung:

┌─────────────────────────────┐
│         Blog CMS            │
│                             │
│      Nội dung Website       │
│                             │
└─────────────────────────────┘

───────────────────────────────
 Debugbar
 Queries | Route | Views | ...
───────────────────────────────

27. Debugbar — Query

Một tính năng rất hữu ích là xem Database Query.

Ví dụ Controller:

$posts = Post::with([
    'user',
    'category'
])->latest()->get();

Debugbar có thể cho chúng ta quan sát những Query được thực thi.

Ví dụ:

select * from posts
select * from users where ...
select * from categories where ...

Điều này đặc biệt hữu ích khi học:

Eloquent
Relationship
Eager Loading
N+1 Problem

28. N+1 Query

Ví dụ không tốt:

$posts = Post::all();

Sau đó trong Blade:

@foreach ($posts as $post)

    {{ $post->category->name }}

@endforeach

Có thể dẫn tới nhiều Query không cần thiết.

Thay vào đó:

$posts = Post::with('category')->get();

Debugbar giúp chúng ta nhìn thấy sự khác biệt này.

29. Debugbar — Route

Debugbar cũng có thể giúp quan sát Route hiện tại:

GET /blog

Controller:

BlogController@index

Middleware:

web
auth
...

Điều này hữu ích khi Route trở nên phức tạp.

30. Debugbar — View

Có thể quan sát các View được render.

Ví dụ:

blog.index
components.blog.sidebar
components.post.card

Nếu một trang có quá nhiều View hoặc Component, Debugbar giúp chúng ta hiểu quá trình render.

31. Debugbar — Performance

Debugbar cũng có thể cho chúng ta thông tin về:

Time
Memory
Queries

Ví dụ:

Time: 120 ms
Memory: 18 MB
Queries: 8

Đây không phải công cụ benchmark production, nhưng rất hữu ích trong quá trình phát triển.

32. Telescope

Laravel còn có một công cụ Debug mạnh hơn:

Laravel Telescope

Telescope là một debugging assistant dành cho Laravel.

Nó cung cấp giao diện để quan sát nhiều hoạt động của ứng dụng.

Ví dụ:

Requests
Commands
Schedule
Jobs
Batches
Database Queries
Exceptions
Logs
Mail
Notifications
Cache

Tùy phiên bản và cấu hình, Telescope cung cấp nhiều watcher khác nhau.

33. Cài Telescope

Có thể cài bằng:

composer require laravel/telescope

Sau đó:

php artisan telescope:install

và:

php artisan migrate

Sau khi cài đặt, Telescope có Dashboard riêng.

Ghi chú: vào link này trên local:&http://127.0.0.1:8000/telescope

34. Telescope Dashboard

Có thể hình dung:

Laravel Application
        │
        ▼
     Telescope
        │
 ┌──────┼───────────────┐
 ▼      ▼               ▼
Request Query         Exception
 │      │               │
 ▼      ▼               ▼
Job    Mail            Log

Dashboard giúp Developer quan sát hệ thống từ một nơi.

35. Telescope — Requests

Telescope có thể theo dõi Request.

Ví dụ:

GET /blog

Có thể quan sát thông tin liên quan đến Request, Response và thời gian xử lý tùy watcher/cấu hình.

Điều này hữu ích khi Debug:

404
403
500

36. Telescope — Queries

Telescope có thể ghi nhận Database Query.

Ví dụ:

select * from posts

và:

select * from categories

Điều này rất hữu ích khi phân tích:

Eloquent
Relationship
N+1
Slow Query

37. Telescope — Exceptions

Nếu ứng dụng xảy ra Exception:

ModelNotFoundException
QueryException
ValidationException
...

Telescope có thể giúp Developer theo dõi Exception tùy cấu hình watcher.

Thay vì chỉ biết:

500

chúng ta có thể điều tra:

Exception
 ↓
Request
 ↓
Query
 ↓
Application Flow

38. Telescope — Jobs

Trong bài Queue trước đó chúng ta đã tìm hiểu Job.

Ví dụ:

SendWelcomeEmail::dispatch($user);

Telescope có thể giúp theo dõi hoạt động liên quan đến Job.

Có thể hình dung:

Job dispatched
      ↓
Queue
      ↓
Worker
      ↓
Job processed

Nếu Job thất bại, công cụ quan sát như Telescope rất hữu ích trong quá trình Debug.

39. Telescope — Mail

Ứng dụng Blog CMS có thể gửi:

Email
Notification

Telescope có thể giúp Developer theo dõi hoạt động Mail trong môi trường development tùy watcher/configuration.

Điều này rất hữu ích khi:

Email không gửi
Email gửi sai
Mailable không chạy
Queue Mail bị lỗi

40. Telescope — Notifications

Tương tự Mail, Telescope có thể hỗ trợ quan sát Notifications.

Ví dụ:

PostPublished
      ↓
Notification
      ↓
User

Nếu Notification không hoạt động như mong muốn, Telescope giúp chúng ta có thêm dữ liệu để điều tra.

41. Telescope và Production

Telescope là công cụ rất mạnh.

Nhưng không nên hiểu:

Telescope
=
luôn bật công khai

Đặc biệt với Production, cần cân nhắc:

Authorization
Storage
Performance
Sensitive Data
Retention

Telescope Dashboard nên được bảo vệ bằng authorization phù hợp.

Laravel cũng cung cấp cơ chế pruning để giới hạn lượng dữ liệu Telescope lưu trữ. (laravel.com)

Ghi chú:

42. Debugbar và Telescope khác nhau

Có thể hiểu đơn giản:

Debugbar

Debug ngay trên trang đang mở

Phù hợp:

Local Development
Query nhanh
Route
View
Performance

Telescope

Dashboard quan sát ứng dụng

Phù hợp:

Requests
Queries
Jobs
Mail
Notifications
Exceptions
Logs

Có thể hình dung:

             DEBUG

        ┌──────┴──────┐
        │             │
    Debugbar       Telescope
        │             │
     Nhanh        Chi tiết
     Local        Dashboard

43. Log vs Debugbar vs Telescope

Không có công cụ nào thay thế hoàn toàn công cụ còn lại.

44. Quy trình Debug thực tế

Khi Blog CMS gặp lỗi:

User báo lỗi
       ↓
Kiểm tra Log
       ↓
Kiểm tra Exception
       ↓
Kiểm tra Request
       ↓
Kiểm tra Query
       ↓
Kiểm tra Controller
       ↓
Kiểm tra Model
       ↓
Kiểm tra Database

Trong Local có thể dùng:

dd()
dump()
Debugbar
Telescope

Trong Production nên ưu tiên:

Log
Monitoring
Exception Tracking

và tránh để thông tin Debug nhạy cảm hiển thị cho người dùng.

45. Ví dụ Debug Post Update

Giả sử:

public function update(
    Request $request,
    Post $post
) {
    $validated = $request->validate([
        'title' => ['required'],
        'content' => ['required'],
    ]);

    $post->update($validated);

    return redirect()
        ->route('posts.index');
}

Nhưng dữ liệu không được cập nhật.

Bước đầu:

dd($request->all());

Kiểm tra:

Request có dữ liệu không?

Sau đó:

dd($validated);

Kiểm tra:

Validation có đúng không?

Sau đó:

dd($post);

Kiểm tra:

Route Model Binding có đúng Post không?

Cuối cùng kiểm tra:

Debugbar

hoặc:

Telescope

để xem Query.

46. Debug Upload Image

Giả sử Upload Image không hoạt động.

Có thể kiểm tra:

dd(
    $request->hasFile('image'),
    $request->file('image')
);

Nếu:

false

kiểm tra Form:

enctype="multipart/form-data"

Nếu có file:

UploadedFile

thì kiểm tra:

dd(
    $request->file('image')->getMimeType()
);

Sau đó kiểm tra Storage.

Đây là cách Debug theo từng tầng thay vì đoán.

47. Debug Database Query

Ví dụ:

$posts = Post::with([
    'user',
    'category'
])->latest()->get();

Nếu nghi ngờ Query quá nhiều:

Debugbar

hoặc:

Telescope

có thể giúp quan sát Query.

Ta có thể phát hiện:

N+1
Query dư thừa
Query quá nhiều
Query chậm

48. Không dùng dd() để Debug Production

Không nên để:

dd($request->all());

trên Website thật.

Bởi vì:

dd()
 ↓
dừng request
 ↓
hiển thị dữ liệu

Nếu dữ liệu chứa thông tin nhạy cảm, hậu quả có thể nghiêm trọng.

Sau khi Debug xong:

XÓA dd()

49. Debug và Security

Debug phải luôn đi cùng Security.

Không nên Log:

Password
API Secret
Private Key
Credit Card
Authentication Token

Ví dụ không nên:

Log::info(
    'Login',
    [
        'password' => $request->password,
    ]
);

Thay vào đó chỉ Log thông tin cần thiết:

Log::info(
    'User login',
    [
        'user_id' => $user->id,
    ]
);

50. Debug trong Blog CMS

Đến thời điểm này Blog CMS đã có:

Authentication
Authorization
CRUD
Upload
Soft Delete
Scope
Observer
Event
Listener
Queue
Mail
Notification
Cache
Storage

Do đó Debug trở nên đặc biệt quan trọng.

Có thể hình dung:

                    BLOG CMS
                        │
        ┌───────────────┼───────────────┐
        │               │               │
      Log           Debugbar        Telescope
        │               │               │
        ▼               ▼               ▼
   Application       Request        Application
     Events          Queries         Activity
     Errors          Views           Jobs
     Warning         Route           Mail

51. Mô hình Debug nên ghi nhớ

Khi gặp lỗi:

              ERROR
                │
                ▼
             REPRODUCE
                │
                ▼
             INSPECT
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
      Log    Debugbar Telescope
       │        │        │
       └────────┼────────┘
                ▼
             FIND CAUSE
                │
                ▼
              FIX
                │
                ▼
              TEST

Đây là tư duy Debug quan trọng hơn việc chỉ biết một vài lệnh.

52. Tổng kết

Trong bài này chúng ta đã tìm hiểu:

• Logging.

• Log::info().

• Log::warning().

• Log::error().

• Log::debug().

• Log Context.

• Log File.

• Log Channel.

• Daily Log.

• APP_DEBUG.

• dd().

• dump().

• Laravel Debugbar.

• Query Debug.

• N+1 Query.

• Route Debug.

• View Debug.

• Performance Debug.

• Laravel Telescope.

• Telescope Requests.

• Telescope Queries.

• Telescope Exceptions.

• Telescope Jobs.

• Telescope Mail.

• Telescope Notifications.

• Debug Production.

• Debug Security.

• Quy trình Debug Blog CMS.

🎯 BÀI TẬP THỰC HÀNH

Bài tập 1 — Logging

Trong PostController, ghi Log khi:

Create Post
Update Post
Delete Post

Ví dụ:

Log::info(
    'Post created',
    [
        'post_id' => $post->id,
        'user_id' => auth()->id(),
    ]
);

Bài tập 2 — Debug Request

Sử dụng:

dd($request->all());

để kiểm tra dữ liệu Form Post.

Sau khi kiểm tra xong:

Xóa dd() khỏi code.

Bài tập 3 — Debug Query

Cài:

composer require barryvdh/laravel-debugbar --dev

Sau đó kiểm tra:

Post Query
Category Query
User Query

Bài tập 4 — Tìm N+1

Thử:

$posts = Post::all();

sau đó truy cập:

{{ $post->category->name }}

Quan sát Query.

Sau đó sửa thành:

$posts = Post::with('category')->get();

và so sánh.

Bài tập 5 — Telescope

Cài:

composer require laravel/telescope

Sau đó:

php artisan telescope:install

và:

php artisan migrate

Truy cập Telescope Dashboard trong môi trường Local.

Thử:

Request
Query
Exception
Log
Job
Mail

và quan sát hoạt động của Blog CMS.

💡 GHI NHỚ

Log giúp chúng ta biết ứng dụng đã làm gì.

Debugbar giúp chúng ta nhìn thấy những gì đang xảy ra trong request hiện tại.

Telescope giúp chúng ta quan sát nhiều hoạt động của Laravel từ một Dashboard.

dd() và dump() rất hữu ích khi học và Debug Local, nhưng phải loại bỏ khỏi Production code.

APP_DEBUG=true chỉ nên sử dụng trong môi trường phát triển.

Production phải sử dụng APP_DEBUG=false.

Một Developer Laravel không chỉ cần biết viết:

$post->update();

mà còn phải biết trả lời:

Tại sao nó không update?

Query nào chạy?

Request có dữ liệu không?

Validation có đúng không?

Exception nằm ở đâu?

Database có vấn đề không?

Queue có chạy không?

File có tồn tại không?

Đó chính là lúc Logging và Debugging trở thành kỹ năng bắt buộc.

Với Blog CMS, chúng ta đã đi từ:

PHP
 ↓
Laravel
 ↓
Database
 ↓
Eloquent
 ↓
CRUD
 ↓
Authentication
 ↓
Authorization
 ↓
Advanced Laravel
 ↓
Logging & Debug

và đã hoàn thành Phần 8 — Nâng cao.

Bài tiếp theo: Bài 41 — REST API, bắt đầu Phần 9 — REST API, nơi Blog CMS sẽ mở dữ liệu cho các ứng dụng khác thông qua HTTP API.

x1
quay về MỤC LỤC

Storage là hệ thống quản lý file của Laravel.

Thay vì tự xử lý đường dẫn file bằng PHP thuần, Laravel cung cấp Storage để làm việc với upload, lưu trữ, đọc, xóa, di chuyển và tạo URL cho file một cách thống nhất.

Trong Blog CMS của chúng ta, Storage đặc biệt quan trọng vì hệ thống có:

• Upload ảnh bài viết.

• Hiển thị ảnh bài viết.

• Thay thế ảnh cũ.

• Xóa ảnh khi xóa Post.

• Lưu đường dẫn ảnh vào Database.

• Quản lý file public/private.

• Sau này có thể chuyển từ Local Storage sang S3 hoặc dịch vụ tương thích S3.

Laravel 13 sử dụng filesystem abstraction dựa trên Flysystem, cho phép ứng dụng sử dụng cùng một API khi làm việc với Local, SFTP, Amazon S3 và các filesystem tương thích S3.

📌 Ghi chú:

🚀 Nếu đã upload mã nguồn lên host thật, nên chọn Amazon S3 ngay từ đầu (vì số lượng 📷 ảnh và 🎬 videos chèn trong posts sẽ rất lớn trong tương lai) 👉 xem mục 35.

🛠️ Mã nguồn hoàn chỉnh CRUD post có kèm upload ảnh đã có sẵn trong Bài 20 — Upload File 📤 và Bài 27 — CRUD Posts 📝.

1. Storage là gì?

Trong PHP thuần, nếu muốn upload file, chúng ta thường phải làm việc trực tiếp với:

move_uploaded_file()

và tự xử lý:

đường dẫn
tên file
thư mục
quyền truy cập
URL
xóa file

Laravel đơn giản hóa toàn bộ quá trình này thông qua:

use Illuminate\Support\Facades\Storage;

Ví dụ:

Storage::put(
    'example.txt',
    'Hello Laravel 13'
);

Laravel sẽ xử lý việc lưu file thông qua filesystem đang được cấu hình.

2. Filesystem trong Laravel

File cấu hình chính:

config/filesystems.php

Có thể hình dung:

Laravel Application
        │
        ▼
   Storage API
        │
 ┌──────┼───────────┐
 ▼      ▼           ▼
Local  SFTP        S3

Điểm quan trọng:

Code Laravel có thể gần như không thay đổi khi chuyển nơi lưu trữ file.

Ví dụ:

Storage::put('photos/image.jpg', $content);

Sau này có thể chuyển từ Local sang S3 bằng cấu hình disk thay vì viết lại toàn bộ logic upload.

3. Storage Disk

Laravel gọi mỗi nơi lưu trữ là một Disk.

Ví dụ:

local
public
s3

Có thể hình dung:

Storage
   │
   ├── local
   │
   ├── public
   │
   └── s3

Khi gọi:

Storage::put(...)

Laravel sử dụng default disk.

Nếu muốn chỉ rõ disk:

Storage::disk('public')->put(...);

4. Local Disk

Trong Laravel 13, local disk mặc định lưu file tương đối với:

storage/app/private

Ví dụ:

Storage::disk('local')->put(
    'example.txt',
    'Hello Laravel'
);

File sẽ nằm trong vùng private của ứng dụng.

Theo cấu hình filesystem mặc định của Laravel 13, local driver sử dụng storage/app/private.

5. Public Disk

Nếu file cần được trình duyệt truy cập trực tiếp, Laravel cung cấp:

public

disk.

Mặc định:

storage/app/public

Ví dụ:

Storage::disk('public')->put(
    'images/example.jpg',
    $content
);

File sẽ được lưu vào:

storage/app/public/images/example.jpg

Nhưng chỉ lưu file ở đây chưa đủ.

6. storage:link

Để file trong:

storage/app/public

có thể truy cập thông qua web, Laravel sử dụng symbolic link:

public/storage
        ↓
storage/app/public

Tạo link:

php artisan storage:link

Sau đó:

public/storage

sẽ trỏ tới:

storage/app/public

Laravel khuyến nghị sử dụng symbolic link này để những file public trong storage/app/public có thể được truy cập từ web.

7. Cấu trúc thư mục

Sau khi chạy:

php artisan storage:link

có thể hình dung:

project/
│
├── app/
├── public/
│   ├── index.php
│   └── storage/
│
├── storage/
│   └── app/
│       ├── private/
│       └── public/
│           ├── images/
│           └── posts/
│
└── config/
    └── filesystems.php

Quan hệ:

public/storage
       │
       ▼
storage/app/public

8. Storage Facade

Import:

use Illuminate\Support\Facades\Storage;

Ví dụ:

Storage::put(
    'hello.txt',
    'Laravel 13'
);

Đọc file:

$content = Storage::get('hello.txt');

Kiểm tra file:

if (Storage::exists('hello.txt')) {
    // File tồn tại
}

9. Lưu file bằng put()

Ví dụ:

Storage::put(
    'documents/example.txt',
    'Hello Laravel 13'
);

Nếu sử dụng:

Storage::disk('public')->put(
    'documents/example.txt',
    'Hello Laravel 13'
);

file sẽ nằm trong public disk.

10. Lưu UploadedFile bằng store(---)

Đây là phần quan trọng nhất đối với Blog CMS.

Giả sử Form:

<form
    method="POST"
    enctype="multipart/form-data"
>
    @csrf

    <input
        type="file"
        name="image"
    >

    <button type="submit">
        Upload
    </button>
</form>

Trong Controller:

$image = $request->file('image');

$path = $image->store('posts', 'public');

Laravel sẽ lưu file vào:

storage/app/public/posts/

và trả về path, ví dụ:

posts/abc123.jpg

Laravel sử dụng tên file duy nhất khi store() được gọi, đồng thời xác định extension dựa trên MIME type của file.

11. Lưu ảnh Blog Post

Ví dụ Controller:

if ($request->hasFile('image')) {

    $path = $request->file('image')
        ->store('posts', 'public');

    $post->image = $path;
}

Database chỉ cần lưu:

posts/abc123.jpg

Không nên lưu toàn bộ:

D:\www\...

hoặc:

http://localhost/...

Database nên lưu relative path.

Ví dụ:

posts/abc123.jpg

12. Vì sao Database chỉ lưu Path?

Giả sử:

Database

image
----------------------
posts/abc123.jpg

Local:

storage/app/public/posts/abc123.jpg

Sau này chuyển sang S3:

S3
└── posts/abc123.jpg

Database vẫn có thể giữ:

posts/abc123.jpg

Code chỉ cần thay đổi disk hoặc cấu hình Storage.

Đây là một trong những lợi ích lớn của filesystem abstraction.

13. Hiển thị ảnh

Sau khi chạy:

php artisan storage:link

có thể sử dụng:

<img
    src="{{ Storage::url($post->image) }}"
    alt="{{ $post->title }}"
>

Import trong Blade:

@php
    use Illuminate\Support\Facades\Storage;
@endphp

Hoặc trong nhiều trường hợp có thể dùng:

<img
    src="{{ asset('storage/' . $post->image) }}"
    alt="{{ $post->title }}"
>

Tuy nhiên:

Storage::url()

là cách phù hợp hơn khi muốn code phụ thuộc vào filesystem disk thay vì hard-code đường dẫn /storage. Laravel cung cấp url() để tạo URL tương ứng với disk đang sử dụng.

14. Storage::url()

Ví dụ:

$url = Storage::url(
    'posts/abc123.jpg'
);

Với local public disk, URL thường có dạng:

/storage/posts/abc123.jpg

Với S3:

https://bucket.example.com/posts/abc123.jpg

Như vậy Controller/Blade không nhất thiết phải biết file đang nằm ở Local hay Cloud.

15. storeAs()

store() tự tạo tên file.

Nếu muốn tự đặt tên:

$path = $request->file('image')
    ->storeAs(
        'posts',
        'my-post.jpg',
        'public'
    );

Kết quả:

storage/app/public/posts/my-post.jpg

Cấu trúc:

storeAs(
    $directory,
    $filename,
    $disk
);

16. hashName()

Laravel cũng cung cấp:

$file->hashName();

Ví dụ:

$name = $request->file('image')->hashName();

Kết quả có thể giống:

X7k8p9Lm2.jpg

Đây là một cách tránh các vấn đề khi người dùng upload nhiều file có cùng tên.

17. Lấy Extension

Có thể lấy extension:

$extension = $file->extension();

Ví dụ:

jpg

hoặc:

png

Laravel xác định extension dựa trên MIME type thay vì chỉ tin vào tên file do client gửi lên.

18. Lấy MIME Type

Có thể sử dụng:

$mime = Storage::mimeType(
    $post->image
);

Ví dụ:

image/jpeg

image/png

19. Kiểm tra file tồn tại

if (Storage::disk('public')->exists(
    $post->image
)) {
    // File tồn tại
}

Điều này rất hữu ích trước khi:

• Xóa file.

• Đọc file.

• Hiển thị file.

• Kiểm tra file cũ trước khi thay thế.

20. Xóa File

Để xóa:

Storage::disk('public')->delete(
    $post->image
);

Ví dụ:

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

Đây chính là logic phù hợp với Blog CMS của chúng ta.

21. Xóa ảnh cũ khi Update Post

Đây là trường hợp rất thực tế.

Admin đang có:

posts/old-image.jpg

Sau đó upload:

posts/new-image.jpg

Nếu chỉ update Database:

Database
    ↓
new-image.jpg

thì:

old-image.jpg

vẫn nằm trong Storage.

Kết quả:

Database
   ↓
new-image.jpg

Storage
   ├── old-image.jpg   ← rác
   └── new-image.jpg

Do đó phải xóa ảnh cũ.

22. Ví dụ Update Post hoàn chỉnh

use Illuminate\Support\Facades\Storage;

public function update(Request $request, Post $post)
{
    $validated = $request->validate([
        'title' => ['required', 'string', 'max:255'],
        'slug' => ['required', 'string', 'max:255'],
        'excerpt' => ['nullable', 'string'],
        'content' => ['required', 'string'],
        'image' => [
            'nullable',
            'image',
            'max:2048',
        ],
    ]);

    if ($request->hasFile('image')) {

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

        $validated['image'] = $request
            ->file('image')
            ->store('posts', 'public');
    }

    $post->update($validated);

    return redirect()
        ->route('posts.index')
        ->with(
            'success',
            'Cập nhật bài viết thành công.'
        );
}

Ở đây:

'max:2048'

tương đương:

2048 KB ≈ 2 MB

23. Xóa Post và ảnh

Khi xóa Post:

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

    $post->delete();

    return redirect()
        ->route('posts.index')
        ->with(
            'success',
            'Xóa bài viết thành công.'
        );
}

Điểm quan trọng:

if ($post->image)

để tránh cố gắng xóa một path rỗng hoặc null.

24. Copy File

Có thể copy:

Storage::copy(
    'posts/old.jpg',
    'posts/new.jpg'
);

Hoặc chỉ rõ disk:

Storage::disk('public')->copy(
    'posts/old.jpg',
    'posts/new.jpg'
);

25. Move File

Di chuyển:

Storage::move(
    'posts/old.jpg',
    'posts/new.jpg'
);

Ví dụ:

posts/draft/image.jpg

sang:

posts/published/image.jpg

26. Liệt kê Files

Lấy danh sách file trong một thư mục:

$files = Storage::files('posts');

Nếu muốn lấy cả file trong thư mục con:

$files = Storage::allFiles('posts');

Laravel cung cấp cả files() và allFiles() cho việc liệt kê file.

27. Làm việc với Directory

Tạo thư mục:

Storage::makeDirectory('posts');

Xóa thư mục:

Storage::deleteDirectory('posts');

Lấy danh sách directory:

$directories = Storage::directories('posts');

Hoặc toàn bộ directory con:

$directories = Storage::allDirectories('posts');

28. File Size

Có thể lấy kích thước file:

$size = Storage::size(
    'posts/example.jpg'
);

Kết quả tính bằng:

bytes

Ví dụ:

204800

Có thể chuyển thành:

200 KB

29. Last Modified

Lấy thời điểm file được chỉnh sửa:

$time = Storage::lastModified(
    'posts/example.jpg'
);

Kết quả là UNIX timestamp.

30. File Visibility

Laravel có khái niệm:

public
private

Public

File có thể được người khác truy cập.

Ví dụ:

Ảnh bài viết
Ảnh sản phẩm
Avatar

Private

File không nên được truy cập trực tiếp.

Ví dụ:

Tài liệu cá nhân
File nội bộ
File download cần kiểm tra quyền

Laravel filesystem abstraction sử dụng visibility để biểu diễn quyền truy cập file trên các backend khác nhau.

31. Lưu File Public

Ví dụ:

Storage::put(
    'posts/example.jpg',
    $content,
    'public'
);

Hoặc:

Storage::disk('public')->put(
    'posts/example.jpg',
    $content
);

32. Private File

Không phải tất cả file đều nên nằm trong:

storage/app/public

Nếu file nhạy cảm hoặc cần kiểm tra quyền trước khi download, có thể sử dụng private storage.

Ví dụ:

storage/app/private/documents/

Controller kiểm tra quyền:

if (! $user->can('download', $document)) {
    abort(403);
}

Sau đó mới trả file cho người dùng.

33. Download File

Laravel có thể trả file download thông qua:

return Storage::download(
    'documents/example.pdf'
);

Có thể chỉ định tên file download:

return Storage::download(
    'documents/example.pdf',
    'tai-lieu.pdf'
);

Đây là một mô hình phù hợp cho:

Private files
      ↓
Authorization
      ↓
Download

thay vì để file public trực tiếp.

34. Temporary URL

Laravel hỗ trợ URL có thời hạn:

$url = Storage::temporaryUrl(
    'file.jpg',
    now()->addMinutes(5)
);

Ví dụ:

URL
 ↓
có hiệu lực 5 phút
 ↓
hết hạn
 ↓
không truy cập được nữa

Điều này đặc biệt hữu ích với file private hoặc cloud storage. Laravel 13 hỗ trợ temporary URLs cho local và S3 trong các cấu hình phù hợp.

35. Amazon S3

Khi Website lớn hơn, có thể chuyển file sang:

Amazon S3

Laravel hỗ trợ S3 thông qua Flysystem.

Cài package:

composer require league/flysystem-aws-s3-v3 "^3.0" --with-all-dependencies

Sau đó cấu hình:

AWS_ACCESS_KEY_ID=your-key
AWS_SECRET_ACCESS_KEY=your-secret
AWS_DEFAULT_REGION=your-region
AWS_BUCKET=your-bucket
AWS_USE_PATH_STYLE_ENDPOINT=false

Sau đó:

FILESYSTEM_DISK=s3

Code upload có thể vẫn rất giống:

$path = $request->file('image')
    ->store('posts', 's3');

Đây chính là lợi ích của filesystem abstraction.

36. S3-Compatible Storage

Không chỉ Amazon S3.

Laravel 13 có thể làm việc với các storage tương thích S3 như:

Cloudflare R2
DigitalOcean Spaces
Vultr Object Storage
Hetzner Cloud Storage
RustFS

Thông thường chỉ cần cấu hình credentials và endpoint phù hợp.

37. Upload File trong Blog CMS

Quy trình của Blog CMS:

User
 │
 ▼
Form Upload
 │
 ▼
Validation
 │
 ▼
UploadedFile
 │
 ▼
Storage
 │
 ▼
storage/app/public/posts
 │
 ▼
Database
 │
 └── posts/abc123.jpg

Database:

posts.image
       ↓
posts/abc123.jpg

Storage:

storage/app/public/posts/abc123.jpg

URL:

/storage/posts/abc123.jpg

38. Không nên lưu file trực tiếp vào Database

Không nên thiết kế:

posts
----------------
image = BINARY DATA

cho ảnh Blog thông thường.

Thay vào đó:

posts
----------------
image = posts/abc123.jpg

File:

Storage
   ↓
posts/abc123.jpg

Database chỉ quản lý:

Path

Storage quản lý:

File

39. Storage và Upload Validation

Storage không thay thế Validation.

Trước khi lưu file:

$request->validate([
    'image' => [
        'nullable',
        'image',
        'max:2048',
    ],
]);

Sau đó:

$request->file('image')
    ->store('posts', 'public');

Quy trình:

Upload
  ↓
Validation
  ↓
Storage

Không nên:

Upload
  ↓
Storage ngay

mà không kiểm tra file.

40. Storage và Blog CMS của chúng ta

Trong project hiện tại, Post có:

image

nên quy ước có thể là:

storage/app/public/posts/

Ví dụ:

posts/
├── a8d91.jpg
├── b73k2.png
└── c91mx.webp

Database:

posts.image

chỉ lưu:

posts/a8d91.jpg

Khi hiển thị:

<img
    src="{{ Storage::url($post->image) }}"
    alt="{{ $post->title }}"
>

Khi thay ảnh:

Xóa ảnh cũ
     ↓
Upload ảnh mới
     ↓
Lưu path mới

Khi xóa Post:

Xóa file
     ↓
Xóa Database record

41. Một Controller hoàn chỉnh

Ví dụ phần Store:

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Storage;

public function store(Request $request)
{
    $validated = $request->validate([
        'title' => ['required', 'string', 'max:255'],
        'slug' => ['required', 'string', 'max:255'],
        'excerpt' => ['nullable', 'string'],
        'content' => ['required', 'string'],
        'category_id' => [
            'nullable',
            'exists:categories,id',
        ],
        'image' => [
            'nullable',
            'image',
            'max:2048',
        ],
    ]);

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

    $validated['user_id'] = $request->user()->id;

    Post::create($validated);

    return redirect()
        ->route('posts.index')
        ->with(
            'success',
            'Tạo bài viết thành công.'
        );
}

Đây là flow hoàn chỉnh:

Validate
   ↓
Check File
   ↓
Store File
   ↓
Get Path
   ↓
Add user_id
   ↓
Create Post

42. Controller Update hoàn chỉnh

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Storage;

public function update(
    Request $request,
    Post $post
) {
    $validated = $request->validate([
        'title' => ['required', 'string', 'max:255'],
        'slug' => ['required', 'string', 'max:255'],
        'excerpt' => ['nullable', 'string'],
        'content' => ['required', 'string'],
        'category_id' => [
            'nullable',
            'exists:categories,id',
        ],
        'image' => [
            'nullable',
            'image',
            'max:2048',
        ],
    ]);

    if ($request->hasFile('image')) {

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

        $validated['image'] = $request
            ->file('image')
            ->store('posts', 'public');
    }

    $post->update($validated);

    return redirect()
        ->route('posts.index')
        ->with(
            'success',
            'Cập nhật bài viết thành công.'
        );
}

43. Controller Destroy hoàn chỉnh

use Illuminate\Support\Facades\Storage;

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

    $post->delete();

    return redirect()
        ->route('posts.index')
        ->with(
            'success',
            'Xóa bài viết thành công.'
        );
}

Đây là pattern mà Blog CMS nên sử dụng:

Delete Database
+
Delete Physical File

tránh tình trạng:

Database đã xóa
nhưng file vẫn tồn tại

44. Laravel 13 và Read-Through Filesystem

Laravel 13 có thêm một filesystem driver đáng chú ý:

read-through

Mô hình:

Application
     │
     ▼
Primary Disk
     │
     │ không có file
     ▼
Fallback Disk

Nếu file chỉ tồn tại ở fallback disk, Laravel có thể đọc file từ đó và đưa bản sao sang primary disk để các request sau sử dụng primary. Đây là tính năng hữu ích khi muốn di chuyển file giữa các storage mà không phải downtime.

Đây là nội dung nâng cao.

Người mới học Storage chưa cần sử dụng ngay.

45. Storage Testing

Laravel cũng hỗ trợ Fake Storage để kiểm thử upload.

Ví dụ:

Storage::fake('photos');

Sau đó test upload:

Storage::disk('photos')
    ->assertExists('photo.jpg');

Laravel cung cấp Storage::fake() để tạo filesystem giả, giúp kiểm thử upload mà không cần ghi file thật vào storage.

Phần này sẽ được giới thiệu lại kỹ hơn trong Bonus PHPUnit của khóa học.

46. Những lỗi thường gặp

Lỗi 1 — Không chạy storage:link

Upload thành công nhưng:

ảnh không hiển thị

Kiểm tra:

php artisan storage:link

Lỗi 2 — Sai Disk

Lưu:

Storage::disk('public')

nhưng lại lấy:

Storage::disk('local')

Có thể dẫn tới không tìm thấy file.

Lỗi 3 — Database lưu sai đường dẫn

Không nên lưu:

/storage/posts/image.jpg

hoặc:

C:\xampp\...

Nên lưu:

posts/image.jpg

Lỗi 4 — Xóa Database nhưng quên xóa file

$post->delete();

nhưng không:

Storage::disk('public')
    ->delete($post->image);

Kết quả:

Database
   ↓
file đã mất record

Storage
   ↓
file rác vẫn còn

Lỗi 5 — Upload ảnh mới nhưng quên ảnh cũ

Khi Update Post:

old.jpg
new.jpg

Nếu không xóa:

old.jpg

Storage sẽ ngày càng phình to.

47. Tóm tắt các phương thức quan trọng

48. Tổng kết

Trong bài này chúng ta đã tìm hiểu:

• Storage là gì.

• Filesystem của Laravel.

• Disk.

• Local Storage.

• Public Storage.

• storage:link.

• Storage Facade.

• put().

• get().

• exists().

• store().

• storeAs().

• hashName().

• Upload Image.

• Storage URL.

• Delete File.

• Copy File.

• Move File.

• Directory.

• File Metadata.

• Public / Private Visibility.

• Download.

• Temporary URL.

• Amazon S3.

• S3-Compatible Storage.

• Storage Testing.

• Read-Through Filesystem trong Laravel 13.

• Ứng dụng Storage vào Blog CMS.

🎯 BÀI TẬP THỰC HÀNH

Bài tập 1 — Upload ảnh Post

Tạo Form:

<input
    type="file"
    name="image"
>

Upload vào:

storage/app/public/posts

Bài tập 2 — Hiển thị ảnh

Sử dụng:

Storage::url($post->image)

để hiển thị ảnh trong Blog.

Bài tập 3 — Thay ảnh

Khi Admin upload ảnh mới:

Xóa ảnh cũ
     ↓
Upload ảnh mới
     ↓
Update Database

Bài tập 4 — Xóa Post

Khi xóa Post:

Xóa Image
     ↓
Xóa Post

Bài tập 5 — Kiểm tra Storage

Chạy:

php artisan storage:link

Sau đó kiểm tra:

storage/app/public

và:

public/storage

💡 GHI NHỚ

Database lưu thông tin về file.

Storage lưu file thật.

Public Disk dành cho những file cần truy cập công khai.

Private Storage dành cho những file cần kiểm soát quyền truy cập.

Khi thay hoặc xóa file, đừng quên xử lý file vật lý trong Storage.

Đối với Blog CMS:

                    POST
                     │
          ┌──────────┴──────────┐
          │                     │
      Database               Storage
          │                     │
          ▼                     ▼
image = posts/a.jpg    posts/a.jpg

Đây là cách Laravel tách biệt:

DATA

và:

FILES

giúp ứng dụng dễ bảo trì và sau này có thể chuyển từ Local Storage sang Cloud Storage mà không phải viết lại toàn bộ chức năng upload.

Bài tiếp theo: Bài 40 — Logging & Debug, tìm hiểu Log, Debugbar và Telescope để theo dõi, debug và quan sát ứng dụng Laravel trong quá trình phát triển.

x1
quay về MỤC LỤC

Trong quy trình phát triển Laravel tiêu chuẩn (từ Laravel 9 trở đi và hiện tại là Laravel 13), vị trí đặt các file .js và .css do developer tự viết được phân chia rõ ràng theo mục đích sử dụng:

1. Nơi chứa mã nguồn (Source Code) — Phổ biến nhất

Tất cả các file JS/CSS do developer tự định nghĩa, chưa qua đóng gói/biên dịch sẽ đặt tại thư mục resources/

my-laravel-project/
├── resources/
│   ├── css/
│   │   ├── app.css           # File CSS chính
│   │   └── custom.css        # CSS tự định nghĩa thêm
│   └── js/
│       ├── app.js            # File JS chính (entry point)
│       ├── components/       # Chứa các module JS/Vue/React
│       └── custom.js         # JS tự viết

Vì sao đặt ở resources/?

Tài liệu Official (Trang chủ Laravel) quy định resources/css và resources/js là nơi lưu trữ tất cả frontend assets.

Các file này sẽ được Vite (công cụ đóng gói mặc định) đọc, nén, tối ưu hóa (bundle/minify) và tạo mã hash để chống cache trình duyệt trước khi phát hành (production).

Cách liên kết vào Blade Layout:

Trình biên dịch Vite sẽ biên dịch các file từ resources/ và nhúng vào HTML thông qua directive @vite():

<!-- resources/views/layouts/app.blade.php -->

@vite(['resources/css/app.css', 'resources/js/app.js'])

2. Nơi chứa file static (Đã nén hoặc dùng trực tiếp)

Nếu có các file .js hoặc .css thuần (như library bên ngoài hoặc file script legacy) không qua trình đóng gói Vite, developer sẽ đặt trực tiếp tại thư mục public/:

my-laravel-project/
├── public/
│   ├── css/
│   │   └── static-style.css
│   └── js/
│       └── static-script.js

Cách nhúng vào Blade Layout:

Nhúng trực tiếp bằng thẻ HTML thông thường qua helper asset():

<link rel="stylesheet" href="{{ asset('css/static-style.css') }}">
<script src="{{ asset('js/static-script.js') }}"></script>

3. Quy chuẩn sắp xếp của Senior / Pro Developers

Khi tham khảo các repository lớn trên GitHub (như Laravel Breeze, Laravel Jetstream, hay các project mã nguồn mở chuẩn):

Sử dụng cấu trúc Module / Component:

Trong resources/js/, họ không viết chung trong 1 file app.js lớn mà chia nhỏ thành các thư mục như components/, pages/, services/, utils/.

Sử dụng CSS Framework / Preprocessor:

Thay vì file .css thuần, dự án chuyên nghiệp thường dùng Tailwind CSS hoặc Sass/SCSS (resources/css/app.css hoặc resources/scss/app.scss).

Cấu hình vite.config.js:&

Mọi file JS/CSS đóng vai trò là "Entry Point" (file gốc) đều phải khai báo trong file vite.config.js:

// vite.config.js

import { defineConfig } from 'vite';

import laravel from 'laravel-vite-plugin';



export default defineConfig({

    plugins: [

        laravel([

            'resources/css/app.css',

            'resources/js/app.js',

        ]),

    ],

});

Tóm tắt nhanh

File tự viết cần compile/bundle (Khuyên dùng) → resources/css/ và resources/js/.

File static dùng trực tiếp (Không qua Vite) → public/css/ và public/js/.

Dưới đây là hướng dẫn thực tế từng bước để tạo và chèn file custom.js vào file Blade theo chuẩn Laravel mới nhất (sử dụng Vite).

Bước 1: Tạo file custom.js

Tạo file tại đường dẫn: resources/js/custom.js

// resources/js/custom.js

console.log("File custom.js đã chạy thành công!");
document.addEventListener('DOMContentLoaded', function () {

    const btn = document.getElementById('myBtn');

    if (btn) {

        btn.addEventListener('click', function () {

            alert('Bạn vừa bấm nút!');

        });

    }

});

Ghi chú:

nếu file custom.js là 01 class thì phải thêm đúng 1 dòng này ở cuối file để xuất class ra phạm vi toàn cục.

Lí do: Vì Vite đóng gói JS dưới dạng ES Module (mọi thứ bị nhốt riêng bên trong file), nếu không đẩy nó ra window.ImageCoordinateTracker = ..., đoạn <script> ở Blade sẽ không bao giờ nhìn thấy Class đó và báo lỗi Uncaught ReferenceError.

class ImageCoordinateTracker {
    constructor(config) {
        // ... code khởi tạo hiện tại của bạn ...
    }
}

// Gán vào window để Blade ở đâu cũng gọi được
window.ImageCoordinateTracker = ImageCoordinateTracker;

Bước 2: Khai báo vào vite.config.js

Mở file vite.config.js ở thư mục gốc của dự án và thêm đường dẫn file custom.js vào mảng input:

// vite.config.js

import { defineConfig } from 'vite';

import laravel from 'laravel-vite-plugin';



export default defineConfig({

    plugins: [

        laravel({

            input: [

                'resources/css/app.css',

                'resources/js/app.js',

                'resources/js/custom.js', // THÊM DÒNG NÀY

            ],

            refresh: true,

        }),

    ],

});

Bước 3: Nhúng vào file Blade View

Thêm chỉ thị @vite() chứa file custom.js vào thẻ <head> hoặc trước khi đóng thẻ </body> trong giao diện Blade:

<!-- resources/views/welcome.blade.php (hoặc file layout của bạn) -->

<!DOCTYPE html>

<html lang="vi">

<head>

    <meta charset="UTF-8">

    <title>Ví dụ chèn JS trong Laravel</title>

    

    <!-- Nhúng CSS chính và file custom.js -->

    @vite(['resources/css/app.css', 'resources/js/app.js', 'resources/js/custom.js'])

</head>

<body>

    <h1>Trang web Laravel</h1>

    <button id="myBtn">Click thử</button>

</body>

</html>

Bước 4: Chạy lệnh biên dịch Assets

Khi phát triển (Development Mode), bạn bật terminal ở thư mục dự án và chạy:

npm run dev

Lưu ý: Nếu deploy lên server thật (Production), bạn cần chạy lệnh npm run build để Vite đóng gói và tối ưu file custom.js.

Có thể, nhưng không khuyên dùng đối với môi trường chuyên nghiệp.

Dưới đây là cách thực hiện nếu bạn vẫn muốn làm, cùng với lý do vì sao cách này tồn tại nhiều rủi ro.

Cách làm (Nếu làm theo ý bạn)

Chạy lệnh đóng gói ở Local:

Mở Terminal tại thư mục dự án bên máy bạn và chạy:

npm run build

Kiểm tra thư mục đầu ra:

Lệnh trên sẽ tạo ra thư mục public/build/. Thư mục này chứa tất cả file CSS/JS đã được nén, tối ưu và đặt tên theo mã hash (ví dụ: custom-A1b2C3.js).

Upload lên Host:

Sử dụng FTP (FileZilla) hoặc cPanel File Manager để upload toàn bộ thư mục public/build/ từ máy bạn lên host thật.

Bỏ qua Node.js trên Host:

Host thật không cần cài Node.js hay npm vẫn chạy được giao diện bình thường.

Rủi ro & Nhược điểm cần lưu ý

Xung đột môi trường (Environment Mismatch): File .env ở Local và Production thường khác nhau (ví dụ: APP_URL). Một số thư viện JavaScript đọc cấu hình từ file .env lúc build. Nếu build ở Local, nó sẽ mang theo cấu hình Local lên Production.

Tốn dung lượng Git (Nếu dùng Git): Nếu bạn đẩy cả thư mục public/build/ lên GitHub/GitLab, file lưu trữ sẽ phình to rất nhanh vì mỗi lần rebuild lại tạo ra các file mã hash mới.

Quên upload: Rất dễ xảy ra trường hợp bạn sửa file custom.js, chạy npm run build nhưng quên upload thư mục public/build/ mới lên host, khiến giao diện thực tế không thay đổi.

Chuẩn Pro / CI-CD làm như thế nào?

Trên các dự án thực tế, người ta áp dụng một trong hai quy trình sau:

Dùng SSH chạy trên Host:

Upload mã nguồn (bao gồm file gốc resources/js/custom.js), mở SSH trên Host và chạy trực tiếp:

npm install && npm run build

Dùng CI/CD Automation (GitHub Actions / GitLab CI):

Developer chỉ cần git push mã nguồn lên.

Server CI/CD tự động bật một môi trường ảo, tự chạy npm run build, sau đó tự đẩy thư mục public/build/ sang Production Server.

Cache là một trong những kỹ thuật quan trọng để tăng tốc ứng dụng web.

Thay vì mỗi request đều phải truy vấn Database hoặc thực hiện lại một công việc tốn thời gian, Laravel có thể lưu kết quả vào Cache và sử dụng lại trong những request tiếp theo.

Trong các dự án thực tế, Cache đặc biệt hữu ích với:

• Danh mục sản phẩm.

• Danh sách bài viết.

• Thông tin cấu hình.

• Thống kê.

• Dữ liệu được truy vấn thường xuyên.

• API response.

• Những phép tính hoặc truy vấn Database tốn thời gian.

  

Ghi chú:&

1. mục 9 trờ đi mới có ví dụ chạy được.
2. mục 29 liệt kê các chỗ thường dùng cache.
3. mục 30 -> ví dụ hoàn chỉnh dùng cache trong Controller.

1. Cache là gì?

Giả sử Blog CMS của chúng ta có đoạn code:

$categories = Category::active()
    ->withCount('posts')
    ->orderBy('name')
    ->get();

Mỗi lần người dùng truy cập Blog:

Request
   ↓
Controller
   ↓
Database
   ↓
Query categories
   ↓
Render View

Nếu có 1.000 người truy cập, câu query này có thể được thực hiện rất nhiều lần.

Trong khi danh mục Blog có thể chỉ thay đổi vài lần trong ngày.

Ta có thể Cache kết quả:

Request
   ↓
Cache?
 ┌─┴─────────┐
 │           │
Có          Không
 │           │
 ↓           ↓
Cache      Database
 │           │
 └─────┬─────┘
       ↓
     View

Lần đầu:

Request
   ↓
Cache không có
   ↓
Database
   ↓
Lưu kết quả vào Cache
   ↓
Response

Những lần sau:

Request
   ↓
Cache có dữ liệu
   ↓
Lấy từ Cache
   ↓
Response

Mục tiêu của Cache không phải là thay thế Database.

Cache là một lớp lưu trữ tạm thời nằm giữa Application và nguồn dữ liệu.

2. Laravel Cache hoạt động như thế nào?

Laravel cung cấp một API thống nhất cho Cache.

Ta có thể sử dụng:

use Illuminate\Support\Facades\Cache;

Sau đó:

Cache::get('key');

Điểm quan trọng là Controller không cần quan tâm quá nhiều đến Cache đang được lưu ở đâu.

Laravel cung cấp nhiều Cache driver khác nhau.

Ví dụ:

Laravel Application
        │
        ▼
   Cache API
        │
 ┌──────┼─────────┐
 ▼      ▼         ▼
Database Redis  Memcached

Theo tài liệu Laravel, Cache có thể sử dụng các backend phổ biến như Database, Redis, Memcached và một số driver khác.

3. Cấu hình Cache

Cấu hình Cache nằm trong:

config/cache.php

Laravel sử dụng biến môi trường:

CACHE_STORE=database

Tùy cấu hình project, bạn có thể sử dụng Cache store khác.

Ví dụ:

CACHE_STORE=database

hoặc:

CACHE_STORE=redis

Sau khi thay đổi .env, nếu ứng dụng đang Cache configuration thì có thể chạy:

php artisan config:clear

4. Database Cache

Một lựa chọn thuận tiện khi học Laravel là sử dụng Database Cache.

Nếu project chưa có bảng Cache, tạo migration:

php artisan make:cache-table

Sau đó:

php artisan migrate

Laravel sẽ tạo bảng dùng để lưu dữ liệu Cache.

Ví dụ có thể hình dung:

Database

users
categories
posts
cache
cache_locks

Cache Database phù hợp cho môi trường học tập hoặc những ứng dụng chưa cần Redis.

5. Cache::put()

Để lưu một giá trị vào Cache:

use Illuminate\Support\Facades\Cache;

Cache::put('name', 'Laravel 13', 60);

Trong đó:

name
    ↓
Cache Key

Laravel 13
    ↓
Cache Value

60
    ↓
TTL - thời gian sống

Sau 60 giây, Cache hết hạn.

Ta cũng có thể sử dụng DateTime:

Cache::put(
    'name',
    'Laravel 13',
    now()->addMinutes(10)
);

Laravel hỗ trợ cả thời gian tính bằng giây và thời điểm hết hạn cụ thể.

6. Cache::get()

Để lấy dữ liệu:

$value = Cache::get('name');

Nếu Cache tồn tại:

Laravel 13

Nếu Cache không tồn tại:

null

Có thể cung cấp giá trị mặc định:

$value = Cache::get('name', 'Default Value');

Nếu key không tồn tại:

Default Value

7. Cache::has()

Kiểm tra Cache có tồn tại hay không:

if (Cache::has('name')) {
    // Cache tồn tại
}

Ví dụ:

if (Cache::has('categories')) {
    $categories = Cache::get('categories');
}

8. Cache::remember()

Đây là một trong những phương thức quan trọng nhất khi làm Laravel.

Thay vì viết:

if (Cache::has('categories')) {

    $categories = Cache::get('categories');

} else {

    $categories = Category::active()
        ->withCount('posts')
        ->orderBy('name')
        ->get();

    Cache::put(
        'categories',
        $categories,
        3600
    );
}

Ta có thể viết ngắn gọn:

$categories = Cache::remember(
    'categories',
    3600,
    function () {
        return Category::active()
            ->withCount('posts')
            ->orderBy('name')
            ->get();
    }
);

Logic:

Cache::remember()

        │
        ▼
   Cache có key?
      /      \
    Có        Không
    │           │
    ▼           ▼
Return       Closure
cache          ↓
             Database
                ↓
          Lưu vào Cache
                ↓
             Return

Đây là pattern rất phổ biến trong các Laravel project thực tế.

9. Ví dụ Cache Categories trong Blog CMS

Giả sử BlogController đang có:

public function index()
{
    $posts = Post::published()
        ->whereHas('category', fn ($q) => $q->active())
        ->with(['user', 'category'])
        ->latest('published_at')
        ->paginate(10);

    $categories = Category::active()
        ->withCount('posts')
        ->orderBy('name')
        ->get();

    return view('blog.index', compact(
        'posts',
        'categories'
    ));
}

Ta có thể Cache $categories:

use Illuminate\Support\Facades\Cache;

public function index()
{
    $posts = Post::published()
        ->whereHas('category', fn ($q) => $q->active())
        ->with(['user', 'category'])
        ->latest('published_at')
        ->paginate(10);

    $categories = Cache::remember(
        'blog.categories',
        3600,
        function () {
            return Category::active()
                ->withCount('posts')
                ->orderBy('name')
                ->get();
        }
    );

    return view('blog.index', compact(
        'posts',
        'categories'
    ));
}

Ở đây:

'blog.categories'

là Cache Key.

3600

là:

3600 giây = 60 phút

Chú ý: đôi khi sẽ phải ép kiểu về object (có thể do lỗi Serialize của Laravel lúc render view biến obj thành string)

-> nên cài Debugbar để dò lỗi BÀI 40 — LOGGING & DEBUG

-> Telescope&PRO hơn do có dashboard riêng và file cấu hình riêng...

$categories = Cache::remember('categories', 60, function () {
    return Category::active()
        ->withCount([
            'posts as total_count' => function ($query) {
                $query->published();
            }
        ])
        ->orderBy('name')
        ->get()
        ->toArray(); // ép thành array trước khi cache
});

// rồi convert lại thành Collection of Models
$categories = Category::hydrate($categories);

// kiểm tra kiểu dữ liệu
//dd($categories);

return view('components.blog-categories', compact('categories'));

10. Cache Key

Cache Key nên được đặt tên rõ ràng.

Ví dụ:

'blog.categories'

'blog.latest_posts'

'blog.popular_posts'

'user.' . $user->id

'post.' . $post->id

Không nên sử dụng những key quá chung chung:

'data'

'list'

'users'

Trong một project lớn, nên tổ chức Cache Key có quy ước.

Ví dụ:

blog.categories
blog.posts.latest
blog.posts.popular

user.1
user.2

post.15
post.16

11. Cache dữ liệu theo ID

Ví dụ lấy User:

$user = Cache::remember(
    'user.' . $id,
    3600,
    function () use ($id) {
        return User::find($id);
    }
);

Hoặc Post:

$post = Cache::remember(
    'post.' . $id,
    3600,
    function () use ($id) {
        return Post::with([
            'user',
            'category'
        ])->findOrFail($id);
    }
);

Đây là cách rất hữu ích đối với những dữ liệu được đọc nhiều nhưng thay đổi ít.

12. Cache Query Database

Cache đặc biệt hữu ích khi Query phức tạp.

Ví dụ:

$posts = Cache::remember(
    'blog.latest_posts',
    600,
    function () {
        return Post::published()
            ->with(['user', 'category'])
            ->latest('published_at')
            ->limit(10)
            ->get();
    }
);

Ở đây Cache sống:

600 giây
= 10 phút

Nếu trong 10 phút có 100 request:

Request 1  → Database
Request 2  → Cache
Request 3  → Cache
Request 4  → Cache
...
Request 100 → Cache

Thay vì:

100 Database Queries

ta có thể giảm xuống gần:

1 Database Query
+
99 Cache Reads

Đây chính là một trong những mục đích quan trọng nhất của Cache.

13. Xóa Cache bằng forget()

Khi dữ liệu thay đổi, đôi khi phải xóa Cache.

Ví dụ:

Cache::forget('blog.categories');

Sau đó request tiếp theo:

Cache không tồn tại
       ↓
Query Database
       ↓
Tạo Cache mới

14. Ví dụ khi cập nhật Category

Giả sử Admin sửa Category:

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

    $category->update($validated);

    Cache::forget('blog.categories');

    return redirect()
        ->route('categories.index')
        ->with('success', 'Cập nhật danh mục thành công.');
}

Điều này rất quan trọng.

Bởi vì nếu:

Category Database
      ↓
đã thay đổi

nhưng:

Cache
      ↓
vẫn chứa dữ liệu cũ

thì Blog có thể tiếp tục hiển thị dữ liệu cũ.

15. Xóa Cache khi tạo Category

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

    Category::create($validated);

    Cache::forget('blog.categories');

    return redirect()
        ->route('categories.index')
        ->with('success', 'Thêm danh mục thành công.');
}

16. Xóa Cache khi xóa Category

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

    Cache::forget('blog.categories');

    return redirect()
        ->route('categories.index')
        ->with('success', 'Xóa danh mục thành công.');
}

Như vậy:

Create Category
       ↓
Forget Cache

Update Category
       ↓
Forget Cache

Delete Category
       ↓
Forget Cache

Đây là nguyên tắc rất quan trọng:

Dữ liệu thay đổi → phải nghĩ đến việc Invalidate Cache.

17. Cache::add()

add() chỉ lưu dữ liệu nếu key chưa tồn tại.

Cache::add(
    'name',
    'Laravel 13',
    3600
);

Nếu:

name chưa tồn tại

thì lưu.

Nếu:

name đã tồn tại

thì không ghi đè.

Phương thức này hữu ích trong một số trường hợp cần tạo giá trị một lần.

18. Cache::increment()

Cache cũng có thể dùng để tăng một giá trị:

Cache::increment('views');

Hoặc:

Cache::increment('views', 5);

Ví dụ:

views = 10

increment()

        ↓

views = 11

19. Cache::decrement()

Tương tự:

Cache::decrement('stock');

Hoặc:

Cache::decrement('stock', 5);

Ví dụ:

stock = 100

decrement(..., 5)

        ↓

stock = 95

Trong những bài toán liên quan đến counter hoặc giới hạn tài nguyên, các thao tác atomic của Cache có thể hữu ích.

20. Cache::pull()

Nếu muốn:

Lấy Cache
   +
Xóa Cache

có thể sử dụng:

$value = Cache::pull('name');

Ví dụ:

Cache::put('coupon', 'ABC123', 600);

$coupon = Cache::pull('coupon');

Sau khi pull():

coupon
   ↓
đã bị xóa

Laravel cũng cung cấp pull() cho trường hợp lấy giá trị rồi xóa khỏi Cache.

21. Cache::flush()

Có thể xóa toàn bộ Cache:

Cache::flush();

Cẩn thận với phương thức này.

flush() không quan tâm prefix Cache của ứng dụng và có thể xóa toàn bộ entries trong cache store đang sử dụng. Vì vậy không nên tùy tiện gọi trong code production nếu Cache store được chia sẻ với ứng dụng khác.

Thông thường khi phát triển:

php artisan cache:clear

cũng có thể được sử dụng để xóa application cache.

22. Cache Helper

Ngoài:

Cache::get(...)

Laravel còn cung cấp helper:

cache()

Ví dụ:

$value = cache('name');

Có thể lưu:

cache([
    'name' => 'Laravel 13'
], 3600);

Hoặc:

$value = cache()->remember(
    'name',
    3600,
    fn () => 'Laravel 13'
);

Laravel cung cấp cả Cache facade và global cache() helper.

23. Cache::flexible()

Laravel cung cấp một kỹ thuật rất hữu ích gọi là:

Stale-While-Revalidate

Thông qua:

Cache::flexible()

Ví dụ:

$value = Cache::flexible(
    'blog.categories',
    [300, 600],
    function () {
        return Category::active()
            ->withCount('posts')
            ->orderBy('name')
            ->get();
    }
);

Hai giá trị:

[300, 600]

có nghĩa:

0 ───────── 300 ───────── 600
     Fresh        Stale

Trong khoảng:

0 → 300 giây

Cache còn fresh.

Trong khoảng:

300 → 600 giây

Laravel có thể trả dữ liệu cũ trước, sau đó đăng ký việc refresh dữ liệu sau response.

Sau:

600 giây

Cache được xem là hết hạn và dữ liệu cần được tính lại ngay.

Đây là cách giảm tình trạng nhiều request cùng lúc phải chờ một tác vụ tạo Cache mới. Laravel mô tả Cache::flexible() chính là implementation cho pattern stale-while-revalidate.

24. Cache::touch() trong Laravel 13

Laravel 13 bổ sung:

Cache::touch()

Mục đích là gia hạn TTL của Cache hiện tại mà không cần lấy giá trị ra rồi lưu lại. Đây là một điểm mới đáng chú ý khi học Cache trên Laravel 13.

Ví dụ:

Cache::touch(
    'blog.categories',
    3600
);

Có thể hiểu:

Cache hiện tại
      ↓
Giữ nguyên value
      ↓
Gia hạn TTL

Thay vì phải:

get()
 ↓
put()

25. Cache Store

Laravel cho phép chọn Cache Store.

Ví dụ:

Cache::store('redis')->get('name');

Hoặc:

Cache::store('database')->get('name');

Điều này cho phép một ứng dụng sử dụng nhiều Cache backend tùy mục đích.

Ví dụ:

Laravel
   │
   ├── database
   │
   ├── redis
   │
   └── memcached

26. Redis Cache

Trong các hệ thống lớn, Redis là một lựa chọn rất phổ biến.

Ví dụ:

CACHE_STORE=redis

Redis có ưu điểm lớn về tốc độ và phù hợp với những ứng dụng cần đọc/ghi Cache với tần suất cao.

Laravel 13 có hỗ trợ Redis thông qua cấu hình Redis của framework.

Có thể hình dung:

Laravel
   │
   ▼
Redis
   │
   ├── Cache
   ├── Session
   ├── Queue
   └── Data

Tuy nhiên, khi học Laravel trên máy local, không nhất thiết phải bắt đầu bằng Redis.

Có thể bắt đầu bằng:

Database Cache

Sau đó khi triển khai VPS hoặc hệ thống lớn:

Redis

27. Cache và Database khác nhau như thế nào?

Đây là vấn đề người mới học Laravel rất dễ nhầm.

Database

Dữ liệu chính thức của hệ thống:

users
posts
categories
orders
products

Cache

Dữ liệu tạm thời để tăng tốc:

cached_categories
cached_posts
cached_statistics

Database có tính:

Persistence

Cache có tính:

Temporary

Ví dụ:

DATABASE

Category
Laravel
PHP
MySQL

Cache:

blog.categories
       ↓
Laravel
PHP
MySQL

Nếu Cache bị xóa:

Không sao.

Ứng dụng có thể lấy lại dữ liệu từ Database và tạo Cache mới.

28. Cache Invalidation

Một trong những vấn đề khó nhất của Cache là:

Khi nào phải xóa Cache?

Ví dụ:

Database
Category = Laravel

Cache:

blog.categories
Category = Laravel

Admin đổi:

Laravel

thành:

Laravel 13

Database:

Laravel 13

nhưng Cache vẫn:

Laravel

Nếu không invalidate Cache:

Database ≠ Cache

Vì vậy cần:

Cache::forget('blog.categories');

Sau đó request tiếp theo tạo Cache mới.

29. Cache trong Blog CMS

Với project Blog CMS đang xây dựng, những dữ liệu phù hợp để Cache có thể là:

Categories

blog.categories

Popular Posts

blog.posts.popular

Latest Posts

blog.posts.latest

Statistics

blog.statistics

User information

user.{id}

Post information

post.{id}

Không nên Cache mọi thứ.

Ví dụ danh sách Post có:

paginate(10)

và thay đổi liên tục thì cần cân nhắc kỹ trước khi Cache.

Ghi chú:&

Bài toán paging không nên dùng Laravel để giải vì Datatables đã giải quyết rất ngọt ngào trong BÀI 29 — SEARCH, SORT, FILTER, PAGINATION & DATATABLES mục 26

30. Một ví dụ hoàn chỉnh

Controller:

<?php

namespace App\Http\Controllers;

use App\Models\Category;
use App\Models\Post;
use Illuminate\Support\Facades\Cache;

class BlogController extends Controller
{
    public function index()
    {
        $posts = Post::published()
            ->whereHas(
                'category',
                fn ($query) => $query->active()
            )
            ->with(['user', 'category'])
            ->latest('published_at')
            ->paginate(10);

        $categories = Cache::remember(
            'blog.categories',
            3600,
            function () {
                return Category::active()
                    ->withCount('posts')
                    ->orderBy('name')
                    ->get();
            }
        );

        return view(
            'blog.index',
            compact('posts', 'categories')
        );
    }
}

Khi Blog được truy cập:

Request
   ↓
BlogController@index
   ↓
Posts → Database
   ↓
Categories
   ↓
Cache
   ↓
View

Lần đầu:

Categories
     ↓
Database
     ↓
Cache

Các request sau:

Categories
     ↓
Cache

31. Khi nào nên sử dụng Cache?

Nên cân nhắc Cache khi:

• Query Database nhiều lần.

• Dữ liệu ít thay đổi.

• Dữ liệu được nhiều người đọc.

• Tính toán dữ liệu tốn CPU.

• Gọi API bên ngoài tốn thời gian.

• Thống kê cần thời gian xử lý.

• Website có lượng truy cập lớn.

Ví dụ:

Category
Site Settings
Popular Posts
Statistics
Exchange Rates
API Response

32. Khi nào không nên Cache?

Không phải dữ liệu nào cũng nên Cache.

Ví dụ:

Thông tin thanh toán
Số dư tài khoản
Dữ liệu thay đổi liên tục
Thông tin cần realtime

Nếu Cache sai cách có thể dẫn tới:

Dữ liệu cũ
     ↓
Người dùng nhìn thấy
     ↓
Logic ứng dụng sai

Vì vậy:

Cache phải được thiết kế dựa trên đặc tính của dữ liệu.

33. Cache không làm Database biến mất

Một sai lầm phổ biến là nghĩ:

Cache = Database nhanh hơn

Không chính xác.

Cache thường đóng vai trò:

Application
     ↓
Cache
     ↓
Database

Cache giúp giảm số lần phải truy cập Database.

Nhưng Database vẫn là nguồn dữ liệu chính của ứng dụng.

34. Cache trong kiến trúc ứng dụng

Một ứng dụng Laravel thực tế có thể có kiến trúc:

                  USER
                   │
                   ▼
                Laravel
                   │
          ┌────────┴────────┐
          │                 │
        Cache             Database
          │
       Redis

Khi dữ liệu đã có trong Cache:

User
 ↓
Laravel
 ↓
Redis
 ↓
Response

Nếu Cache miss:

User
 ↓
Laravel
 ↓
Redis ❌
 ↓
Database
 ↓
Redis ← lưu kết quả
 ↓
Response

Đây là mô hình rất phổ biến trong các hệ thống web hiện đại.

35. Tổng kết

Trong bài này chúng ta đã tìm hiểu:

• Cache là gì.

• Cache hoạt động như thế nào.

• Cấu hình Cache.

• Database Cache.

• Cache::put().

• Cache::get().

• Cache::has().

• Cache::remember().

• Cache Query Database.

• Cache Key.

• Cache::forget().

• Cache::add().

• Cache::increment().

• Cache::decrement().

• Cache::pull().

• Cache::flush().

• cache() helper.

• Cache::flexible().

• Stale-While-Revalidate.

• Cache::touch() trong Laravel 13.

• Cache Store.

• Redis Cache.

• Cache Invalidation.

• Ứng dụng Cache vào Blog CMS.

🎯 BÀI TẬP THỰC HÀNH

Bài tập 1 — Cache Categories

Sử dụng:

Cache::remember()

để Cache:

Category::active()
    ->withCount('posts')
    ->orderBy('name')
    ->get();

Thời gian:

60 phút

Bài tập 2 — Xóa Cache

Trong:

CategoryController

thực hiện:

Cache::forget('blog.categories');

sau khi:

• Tạo Category.

• Cập nhật Category.

• Xóa Category.

Bài tập 3 — Cache Post

Tạo Cache:

post.{id}

và sử dụng:

Cache::remember()

để lấy Post cùng:

user
category

Bài tập 4 — Cache Statistics

Tạo một Cache:

blog.statistics

chứa:

[
    'posts' => ...,
    'categories' => ...,
    'users' => ...,
]

Bài tập 5 — Thử Cache::flexible()

Thử:

Cache::flexible(
    'blog.categories',
    [300, 600],
    function () {
        return Category::active()
            ->withCount('posts')
            ->orderBy('name')
            ->get();
    }
);

Quan sát cách Laravel xử lý dữ liệu trong khoảng:

0 → 300 giây

và:

300 → 600 giây

💡 GHI NHỚ

Database lưu dữ liệu chính.

Cache lưu dữ liệu tạm thời để tăng tốc.

Cache Hit → lấy dữ liệu nhanh từ Cache.

Cache Miss → lấy dữ liệu từ nguồn và tạo Cache mới.

Dữ liệu thay đổi → phải nghĩ đến Cache Invalidation.

Với Blog CMS của chúng ta, một ví dụ điển hình là:

Category
    ↓
Database
    ↓
Cache
    ↓
Blog Sidebar

Thay vì mỗi request đều query:

Category::active()
    ->withCount('posts')
    ->orderBy('name')
    ->get();

ta có thể Cache kết quả và chỉ tạo lại khi Cache hết hạn hoặc khi Category thay đổi.

Đó chính là cách Cache bắt đầu trở thành một phần của kiến trúc ứng dụng thực tế, chứ không đơn thuần là một mẹo tăng tốc.

Bài tiếp theo: Bài 39 — Storage, tìm hiểu cách Laravel quản lý file, disk, storage/app, public, upload, URL và Storage facade.

x1
quay về MỤC LỤC

Đây là phần quan trọng nhất của toàn bộ khóa học.

Ở 5 phần trước, chúng ta đã học:

🛒 Tìm sản phẩm
      ↓
👥 Tìm khách
      ↓
📱 Làm nội dung
      ↓
💰 Chạy quảng cáo
      ↓
🔥 Bán lại cho khách cũ
      ↓
🌐 Google + Website
      ↓
🤖 AI + Automation

Nhưng tất cả những thứ đó vẫn chỉ là kiến thức nếu chưa có một sản phẩm thật, khách hàng thật và giao dịch thật.

Vì vậy, ở Phần 6 chúng ta sẽ:

Đưa toàn bộ hệ thống vào thực tế.

Không còn hỏi:

"Nếu bán thì sao?"

Mà bắt đầu hỏi:

"Hôm nay tôi bán được bao nhiêu?"

🧪 28. Chọn một sản phẩm thật

Đừng bắt đầu bằng:

"Tôi muốn xây một thương hiệu lớn."

Hãy bắt đầu nhỏ hơn:

"Tôi sẽ thử bán một sản phẩm."

Sản phẩm đầu tiên nên tương đối đơn giản.

Có thể bắt đầu bằng một sản phẩm:

• Dễ hiểu.

• Dễ trình bày bằng hình ảnh/video.

• Có nhu cầu rõ ràng.

• Có mức giá phù hợp với khách hàng mục tiêu.

• Có biên lợi nhuận đủ để thử nghiệm.

• Có nguồn hàng ổn định.

• Không quá phức tạp về vận chuyển hoặc bảo hành.

🎯 Đừng chọn sản phẩm chỉ vì "thấy hay"

Ví dụ bạn nhìn thấy một sản phẩm rất đẹp:

😍 Đẹp
🔥 Đang hot
📱 TikTok nhiều người nói

Điều đó chưa đủ.

Hãy đặt câu hỏi:

Có người cần không?
        ↓
Có người trả tiền không?
        ↓
Giá bán bao nhiêu?
        ↓
Giá vốn bao nhiêu?
        ↓
Còn lợi nhuận không?
        ↓
Có thể tìm khách ở đâu?
        ↓
Có thể bán lại không?

Nếu câu trả lời tương đối rõ ràng:

Có thể test.

🧮 Tính kinh tế của sản phẩm trước khi bán

Ví dụ:

Giá bán:                  300.000đ
Giá vốn:                  150.000đ
Đóng gói:                  10.000đ
Phí nền tảng / thanh toán: 15.000đ
Chi phí khác:              15.000đ
----------------------------------
Còn lại trước quảng cáo:  110.000đ

Như vậy bạn biết:

Mỗi đơn có khoảng 110.000đ để trang trải chi phí thu hút khách và tạo lợi nhuận.

Nếu chi phí để có một đơn hàng là:

50.000đ

thì còn:

110K - 50K
= 60K

Đây mới là con số đáng quan tâm.

📱 29. Dựng kênh bán hàng thật

Không cần xây một hệ thống khổng lồ ngay từ đầu.

Bạn có thể bắt đầu:

SẢN PHẨM
   ↓
📱 TikTok / Facebook
   ↓
💬 Tin nhắn
   ↓
🛒 Đơn hàng

Hoặc:

SẢN PHẨM
   ↓
🌐 Website
   ↓
🛒 Đặt hàng

Hoặc:

GOOGLE
   ↓
🌐 Website
   ↓
💰 Đơn hàng

Không cần làm tất cả cùng lúc.

Một sản phẩm + một nhóm khách + một kênh chính là đủ để bắt đầu.

🏗️ Tạo "bộ bán hàng" tối thiểu

Trước khi đưa sản phẩm ra thị trường, hãy chuẩn bị:

📦 Sản phẩm
   ↓
🖼️ Ảnh
   ↓
🎬 Video
   ↓
✍️ Nội dung
   ↓
💰 Giá
   ↓
🎁 Ưu đãi
   ↓
💬 Cách liên hệ
   ↓
🛒 Cách đặt hàng
   ↓
🚚 Cách giao hàng

Nếu khách nhìn thấy sản phẩm nhưng không biết:

"Mua ở đâu?"

thì bạn đã mất một cơ hội bán hàng.

🎬 Nội dung đầu tiên không cần hoàn hảo

Đây là lúc những gì học ở Phần 1 và Phần 5 được sử dụng.

Ví dụ một sản phẩm có thể làm:

Video 1:
Vấn đề khách hàng

Video 2:
Cách sử dụng

Video 3:
Demo sản phẩm

Video 4:
So sánh

Video 5:
Review

Video 6:
Câu hỏi thường gặp

Video 7:
Sai lầm khi chọn sản phẩm

Không cần chờ:

máy quay chuyên nghiệp.

Chỉ cần:

điện thoại + ánh sáng đủ tốt + sản phẩm thật + nội dung rõ ràng.

💰 30. Chạy chiến dịch thật

Bây giờ chúng ta bước vào phần thú vị nhất:

Đưa tiền thật vào hệ thống.

Nhưng đừng bắt đầu bằng ngân sách lớn.

Hãy coi chiến dịch đầu tiên là:

một thí nghiệm kinh doanh.

🧪 Chiến dịch thử nghiệm

Ví dụ:

Sản phẩm:
Bình giữ nhiệt

Giá:
299.000đ

Ngân sách thử:
100.000đ/ngày

Thời gian:
Một khoảng thử nghiệm đủ để có dữ liệu

Mục tiêu ban đầu không phải:

"Phải kiếm 10 triệu."

Mục tiêu là:

Tìm hiểu xem thị trường phản ứng như thế nào.

📊 Theo dõi từng bước

Đừng chỉ ghi:

"Hôm nay bán được 3 đơn."

Hãy ghi toàn bộ phễu:

10.000
Lượt tiếp cận
      ↓
500
Lượt xem / click
      ↓
80
Tin nhắn
      ↓
20
Người quan tâm thực sự
      ↓
8
Đơn hàng
      ↓
7
Đơn hoàn tất

Bây giờ bạn có dữ liệu để phân tích.

🔍 Có thể có vấn đề ở đâu?

Ví dụ:

10.000 người thấy
        ↓
10 người click

→ Có thể nội dung/Hook chưa đủ hấp dẫn.

Hoặc:

1.000 người click
        ↓
5 người mua

→ Có thể vấn đề nằm ở trang bán hàng, giá, niềm tin hoặc sản phẩm.

Hoặc:

100 người mua
        ↓
30 người hoàn hàng

→ Có thể vấn đề nằm ở chất lượng sản phẩm, kỳ vọng khách hàng hoặc quy trình giao hàng.

Đây là lý do:

Đừng chỉ nhìn kết quả cuối cùng.

Hãy tìm xem nút thắt nằm ở đâu.

💰 31. Đo tiền vào — tiền ra

Đây là bước biến một người bán hàng thành người kinh doanh.

Bạn phải biết:

Tiền đi đâu?

Một bảng đơn giản:

Doanh thu:

10 triệu

nghe rất lớn.

Nhưng thứ bạn thực sự cần quan tâm là:

1,7 triệu lợi nhuận.

⚠️ Đừng nhầm doanh thu với tiền kiếm được

Có người nói:

"Tôi bán được 100 triệu mỗi tháng!"

Nghe rất ấn tượng.

Nhưng nếu:

Doanh thu      100M
Chi phí         98M
-------------------
Lợi nhuận        2M

thì mô hình đó chưa chắc tốt.

Một người khác:

Doanh thu       40M
Chi phí         25M
-------------------
Lợi nhuận       15M

có thể đang có một mô hình khỏe hơn.

Vì vậy:

Đừng chạy theo doanh thu nếu không biết lợi nhuận.

📊 Bảng điều khiển tối thiểu

Mỗi ngày hoặc mỗi tuần, hãy theo dõi:

👥 Khách mới
🛒 Số đơn
💰 Doanh thu
📦 Giá vốn
📢 Chi phí quảng cáo
💬 Số tin nhắn
🔄 Số khách mua lại
💎 AOV
🎯 CAC
📈 Lợi nhuận

Chỉ cần một file Excel hoặc Google Sheets đơn giản cũng đủ để bắt đầu.

🧮 Một số công thức quan trọng

AOV

AOV =
Doanh thu / Số đơn

CAC

CAC =
Chi phí thu hút khách / Số khách mới

Conversion Rate

Conversion Rate =
Số người mua / Số người tiếp cận

ROAS

ROAS =
Doanh thu từ quảng cáo / Chi phí quảng cáo

Nhưng hãy nhớ:

ROAS cao không tự động có nghĩa là lợi nhuận cao.

🚀 32. Tối ưu để có lợi nhuận

Đây là lúc bắt đầu chơi "trò chơi" thật sự.

Giả sử:

100 khách
↓
5 đơn

Mục tiêu đầu tiên có thể là:

100 khách
↓
7 đơn

Không cần tăng traffic.

Chỉ cần:

tăng tỷ lệ chuyển đổi.

🔧 Tối ưu ở đâu?

Có 5 khu vực lớn.

1. 🎬 Tối ưu nội dung

Hook tốt hơn.

Video rõ hơn.

Demo thực tế hơn.

2. 🛒 Tối ưu trang bán hàng

Ảnh tốt hơn
↓
Thông tin rõ hơn
↓
Đánh giá tốt hơn
↓
CTA rõ hơn

3. 💰 Tối ưu giá

Có thể thử:

299K

so với:

279K

hoặc:

299K
+
quà tặng

Không phải lúc nào giảm giá cũng tốt.

4. 📦 Tối ưu giá trị đơn hàng

Từ:

AOV = 250K

tăng lên:

AOV = 320K

bằng:

• Combo.

• Upsell.

• Cross-sell.

• Sản phẩm bổ sung.

5. 🔄 Tối ưu mua lại

Một khách:

Mua 1 lần

có thể trở thành:

Mua
 ↓
Mua lại
 ↓
Mua thêm
 ↓
Giới thiệu

Đây chính là sức mạnh của Phần 3.

📈 Tăng trưởng không nhất thiết là tăng quảng cáo

Đây là một tư duy rất quan trọng.

Giả sử:

100 khách
×
10% chuyển đổi
=
10 đơn

Nếu tối ưu tỷ lệ chuyển đổi:

100 khách
×
15%
=
15 đơn

Bạn tăng:

50% số đơn

mà không cần tăng số khách.

💎 Hoặc tăng AOV

Giả sử:

10 đơn
×
300K
=
3M doanh thu

Tăng AOV:

10 đơn
×
400K
=
4M

Vẫn:

10 khách mua.

Nhưng doanh thu tăng thêm:

1 triệu đồng.

🔥 Hoặc tăng mua lại

Khách hàng mua một lần:

100 khách
×
300K
=
30M

Nếu một phần khách mua lại:

100 khách
×
300K
×
2 lần
=
60M

Đây là lý do:

LTV cực kỳ quan trọng.

🏆 33. Xây hệ thống bán hàng có thể chạy mỗi ngày

Đây là mục tiêu cuối cùng của toàn bộ khóa học.

Không phải:

"Một ngày tôi bán được 20 đơn."

Mà là:

"Tôi có một hệ thống tạo ra đơn hàng đều đặn."

🏗️ Hệ thống bán hàng hoàn chỉnh

                 🛍️ SẢN PHẨM
                      ↓
              👥 KHÁCH HÀNG
                      ↓
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       📱 Social    🔎 Google    💰 Ads
          ↓           ↓           ↓
          └───────────┼───────────┘
                      ↓
                 🌐 WEBSITE
                      ↓
                  💬 TƯ VẤN
                      ↓
                  🛒 ĐƠN HÀNG
                      ↓
                  📦 GIAO HÀNG
                      ↓
                  😊 HÀI LÒNG
                      ↓
            ┌─────────┼─────────┐
            ↓         ↓         ↓
         🔄 MUA LẠI  ➕ MUA THÊM  📣 GIỚI THIỆU
            ↓         ↓         ↓
            └─────────┼─────────┘
                      ↓
                  💰 DOANH THU
                      ↓
                 📊 DỮ LIỆU
                      ↓
                 🤖 AI PHÂN TÍCH
                      ↓
                   ⚙️ TỐI ƯU
                      ↓
                  🚀 TĂNG TRƯỞNG

Đây không còn là một vài bài đăng bán hàng.

Đây là:

một hệ thống kinh doanh.

🔁 Hệ thống phải có vòng lặp

Một hệ thống tốt sẽ tự tạo ra dữ liệu cho lần tối ưu tiếp theo:

BÁN HÀNG
   ↓
CÓ DỮ LIỆU
   ↓
PHÂN TÍCH
   ↓
TÌM VẤN ĐỀ
   ↓
TEST
   ↓
KẾT QUẢ TỐT HƠN
   ↓
BÁN NHIỀU HƠN
   ↓
CÓ THÊM DỮ LIỆU
   ↓
PHÂN TÍCH
   ↓
...

Đó là:

Growth Loop — vòng lặp tăng trưởng.

🤖 AI tham gia ở đâu?

Hệ thống hoàn chỉnh có thể sử dụng AI ở nhiều vị trí:

Nghiên cứu
   ↓
🤖 AI

Nội dung
   ↓
🤖 AI

Video
   ↓
🤖 AI

Quảng cáo
   ↓
📊 Dữ liệu
   ↓
🤖 AI phân tích

Khách hàng
   ↓
🤖 AI hỗ trợ

Công việc lặp lại
   ↓
⚙️ Automation

Nhưng vẫn có một trung tâm:

CON NGƯỜI RA QUYẾT ĐỊNH.

🧠 Từ "làm tất cả" → "xây hệ thống"

Giai đoạn đầu:

Bạn
 ↓
Tự tìm khách
 ↓
Tự viết bài
 ↓
Tự bán
 ↓
Tự đóng gói
 ↓
Tự chăm sóc

Giai đoạn sau:

BẠN
 ↓
XÂY QUY TRÌNH
 ↓
AI + CÔNG CỤ + TỰ ĐỘNG HÓA
 ↓
HỆ THỐNG
 ↓
KHÁCH HÀNG
 ↓
ĐƠN HÀNG

Bạn không còn chỉ là:

người làm việc trong cửa hàng.

Bạn trở thành:

người thiết kế hệ thống bán hàng.

📋 CHECKLIST: HỆ THỐNG ĐÃ SẴN SÀNG CHƯA?

Hãy kiểm tra:

☐ Có một sản phẩm thật

☐ Biết giá vốn

☐ Biết giá bán

☐ Biết lợi nhuận trên đơn

☐ Xác định khách hàng mục tiêu

☐ Có kênh bán hàng

☐ Có nội dung

☐ Có cách nhận đơn

☐ Có cách giao hàng

☐ Có cách chăm sóc khách

☐ Có theo dõi doanh thu

☐ Có theo dõi chi phí

☐ Biết CAC

☐ Biết AOV

☐ Theo dõi mua lại

☐ Biết quảng cáo nào có lời

☐ Biết quảng cáo nào cần cắt

☐ Có quy trình test

☐ Có quy trình tối ưu

☐ Có thể sử dụng AI để giảm việc lặp lại

Nếu chưa đủ 20 mục cũng không sao.

Quan trọng là:

Bắt đầu xây từng mục một.

🧪 BÀI THỰC HÀNH CUỐI KHÓA

Bây giờ hãy thực sự chọn một sản phẩm.

Không chọn 10 sản phẩm.

Không mở 5 cửa hàng.

Không chạy 20 chiến dịch.

Chọn:

1 sản phẩm
     ↓
1 nhóm khách hàng
     ↓
1 kênh chính
     ↓
1 chiến dịch
     ↓
1 bảng theo dõi

Sau đó chạy thử.

Ngày 1

Chuẩn bị sản phẩm.

Ngày 2

Làm nội dung.

Ngày 3

Đưa sản phẩm lên kênh bán hàng.

Ngày 4

Bắt đầu kéo khách.

Ngày 5+

Theo dõi:

👥 Khách
💬 Tin nhắn
🛒 Đơn
💰 Doanh thu
📢 Chi phí
📈 Lợi nhuận

Sau đó hỏi:

"Điểm nào đang làm mất tiền?"

và:

"Điểm nào đang tạo tiền?"

🏆 ĐIỀU QUAN TRỌNG NHẤT CỦA TOÀN BỘ KHÓA HỌC

Bạn không cần:

❌ website triệu đô
❌ hàng nghìn sản phẩm
❌ hàng trăm nghìn follower
❌ văn phòng lớn
❌ đội ngũ khổng lồ

để bắt đầu.

Bạn cần:

Một sản phẩm có người muốn mua.

Sau đó:

TÌM KHÁCH
   ↓
BÁN
   ↓
ĐO
   ↓
HỌC
   ↓
TỐI ƯU
   ↓
BÁN TỐT HƠN
   ↓
TÁI ĐẦU TƯ
   ↓
MỞ RỘNG

Đó là toàn bộ tư duy của khóa học.

🌟 TỪ "BÁN HÀNG" ĐẾN "KINH DOANH"

Ban đầu:

Tôi cần một đơn hàng.

Sau đó:

Tôi cần nhiều đơn hàng.

Tiếp theo:

Tôi cần khách mua lại.

Sau nữa:

Tôi cần lợi nhuận.

Và cuối cùng:

Tôi cần một hệ thống có thể tạo ra lợi nhuận một cách ổn định.

Đây là sự thay đổi lớn nhất:

          NGƯỜI BÁN HÀNG
                 ↓
             CÓ ĐƠN
                 ↓
          NGƯỜI KINH DOANH
                 ↓
            CÓ LỢI NHUẬN
                 ↓
          NGƯỜI XÂY HỆ THỐNG
                 ↓
       HỆ THỐNG TẠO RA ĐƠN
                 ↓
       HỆ THỐNG TẠO RA LỢI NHUẬN

🏆 HOÀN THÀNH 33 BƯỚC

🛒 PHẦN 1
KIẾM ĐƠN KHÔNG CẦN QUẢNG CÁO
        ↓
💰 PHẦN 2
DÙNG TIỀN ĐỂ MUA KHÁCH
        ↓
🔥 PHẦN 3
KIẾM NHIỀU HƠN TỪ MỘT KHÁCH
        ↓
🌐 PHẦN 4
GOOGLE & WEBSITE
        ↓
🤖 PHẦN 5
AI GIÚP BÁN HÀNG
        ↓
🏆 PHẦN 6
LÀM RA TIỀN THẬT

Và toàn bộ khóa học có thể cô đọng thành một câu:

Tìm đúng sản phẩm → tìm đúng khách → đưa sản phẩm đến trước khách → biến khách thành người mua → biến người mua thành khách hàng lâu dài → đo lợi nhuận → tối ưu → tự động hóa → rồi mới mở rộng.

Đừng học mãi về cách kiếm tiền.
Hãy chọn một sản phẩm và bắt đầu thử bán.

Đó là lúc kiến thức biến thành tiền thật.

quay về MỤC LỤC&

Trong Bài 36 — Mail, chúng ta đã học cách Laravel gửi email bằng:

Mail
  ↓
Mailable
  ↓
Blade
  ↓
SMTP
  ↓
Người nhận

Nhưng trong một ứng dụng thực tế, thông báo không chỉ có Email.

Người dùng có thể cần nhận thông báo qua:

• 📧 Email

• 🗃️ Database

• 📱 SMS

• 💬 Slack

• 🔔 Các kênh thông báo khác

Đây chính là lúc Notification của Laravel trở nên hữu ích.

Notification giúp chúng ta xây dựng một thông báo theo cách thống nhất, sau đó quyết định thông báo đó sẽ được gửi qua kênh nào.

📚 MỤC LỤC

Trong bài này chúng ta sẽ tìm hiểu:

1. Notification là gì?
2. Notification khác Mail thế nào?
3. Tạo Notification
4. notify()
5. Notifiable
6. Mail Notification
7. Database Notification
8. Đọc Notification
9. Đánh dấu đã đọc
10. Xóa Notification
11. Markdown Notification
12. Notification + Queue
13. Notification + Event
14. Notification theo nhiều kênh
15. Notification trong Blog CMS
16. Bài tập thực hành
17. Tổng kết

1. 🔔 Notification trong Laravel là gì?

Notification là cơ chế của Laravel dùng để gửi thông báo đến một đối tượng nhận thông báo.

Ví dụ:

User đăng ký
     ↓
Notification
     ↓
"Chào mừng bạn!"

Hoặc:

Admin xuất bản bài viết
     ↓
Notification
     ↓
"Có bài viết mới"

Hoặc:

Đơn hàng hoàn tất
     ↓
Notification
     ↓
"Đơn hàng #1001 đã được giao"

Notification đặc biệt hữu ích vì một thông báo có thể được gửi qua nhiều channel.

Ví dụ:

                    Notification
                         │
            ┌────────────┼────────────┐
            ▼            ▼            ▼
          Email       Database      Slack

2. 📧 Notification khác Mail thế nào?

Đây là điểm rất dễ nhầm.

Mail

Mail tập trung vào việc tạo và gửi email.

Mailable
    ↓
Email

Ví dụ:

Mail::to($user->email)
    ->send(new WelcomeUser($user));

Notification

Notification tập trung vào thông báo.

Notification
      ↓
   Channel
      ↓
Email / Database / Slack / ...

Ví dụ:

$user->notify(
    new NewPostNotification($post)
);

Notification có thể chọn nhiều channel:

return ['mail', 'database'];

Vì vậy có thể hiểu đơn giản:

Mailable = xây dựng một email.

Notification = xây dựng một thông báo có thể đi qua nhiều kênh.

3. 👤 Notification cần đối tượng nhận

Notification thường được gửi tới một đối tượng có trait:

Notifiable

Thông thường chúng ta sẽ thấy trait này trong model&User.

Ví dụ:

use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use Notifiable;
}

Sau đó User có thể nhận Notification:

$user->notify(
    new NewPostNotification($post)
);

Luồng:

User
 │
 └── Notifiable
          │
          ▼
    Notification

4. 🛠️ Tạo Notification

Laravel cung cấp Artisan để tạo Notification:

php artisan make:notification NewPostNotification

Laravel tạo:

app/
└── Notifications/
    └── NewPostNotification.php

Một Notification thường có cấu trúc:

<?php

namespace App\Notifications;

use Illuminate\Bus\Queueable;
use Illuminate\Notifications\Notification;

class NewPostNotification extends Notification
{
    use Queueable;

    public function __construct()
    {
        //
    }

    public function via(object $notifiable): array
    {
        return ['mail'];
    }
}

Phần quan trọng nhất là:

via()

Nó quyết định Notification được gửi qua channel nào.

5. 📡 via() — chọn Channel

Ví dụ chỉ gửi Email:

public function via(object $notifiable): array
{
    return ['mail'];
}

Gửi Database:

public function via(object $notifiable): array
{
    return ['database'];
}

Gửi cả hai:

public function via(object $notifiable): array
{
    return [
        'mail',
        'database',
    ];
}

Mô hình:

             Notification
                   │
             ┌─────┴─────┐
             ▼           ▼
           Mail       Database

Đây là một trong những ưu điểm lớn của Notification.

Laravel lưu trong bảng notifications. Bạn cần chạy migration:

php artisan notifications:table
php artisan migrate

Chỉnh trong class NewPostNotification

use App\Models\Post;

class NewPostNotification extends Notification
{
    use Queueable;

    public $post;

    /**
     * Create a new notification instance.
     */
    public function __construct(Post $post)
    {
        $this->post = $post;
    }

    /**
     * Get the notification's delivery channels.
     *
     * @return array
     */
    public function via(object $notifiable): array
    {
        return [
            'mail',
            'database',
        ];
    }

    /**
     * Get the mail representation of the notification.
     */
    public function toMail(object $notifiable): MailMessage
    {
        return (new MailMessage)
        ->subject('Có bài viết mới')
        ->greeting('Xin chào!')
        ->line('Một bài viết mới vừa được tạo: ' . $this->post->title)
        ->action(
            'Xem bài viết',
            route('blog.show', $this->post->slug)
        )
        ->line('Cảm ơn bạn đã theo dõi!');
    }


    public function toDatabase($notifiable)
    {
        return [
            'post_id' => $this->post->id,
            'title' => $this->post->title,
            'slug' => $this->post->slug,
        ];
    }
    ...
}

Sau mục 7, kiểm tra trong DB xem có bản ghi mới chưa().

6. 📧 Mail Notification

Ví dụ chúng ta muốn thông báo:

Có bài viết mới được xuất bản.

Notification:

public function via(object $notifiable): array
{
    return ['mail'];
}

Sau đó tạo:

public function toMail(object $notifiable): MailMessage
{
    return (new MailMessage)
        ->subject('Có bài viết mới')
        ->greeting('Xin chào!')
        ->line('Một bài viết mới vừa được xuất bản.')
        ->action(
            'Xem bài viết',
            url('/blog')
        )
        ->line('Cảm ơn bạn đã theo dõi!');
}

Import:

use Illuminate\Notifications\Messages\MailMessage;

Laravel sẽ xây dựng email từ Notification.

Ghi chú: nếu có lỗi chỗ này, Laravel 13 sẽ gửi mẫu mail default của họ.

7. 🚀 Gửi Notification

Sau khi có Notification vào PostController

use App\Models\User;
use Illuminate\Support\Facades\Auth;

public function store(Request $request)
{
    $post = Post::create([
        ...
    ]);

    $post->tags()->sync($request->tags ?? []);

    if ($post->status === 'published') {
        event(new PostPublished($post));
    }

    // Lấy user hiện tại từ Auth sau khi login
    $user = Auth::user();
    $user->notify(new NewPostNotification($post));

    return redirect()
        ->route('admin.posts.show', $post)
        ->with('success', 'Bài viết đã được tạo thành công.');
}

Hoặc:

$user->notify(
    new NewPostNotification($post)
);

Laravel sẽ gọi:

$user
   ↓
notify()
   ↓
Notification
   ↓
via()
   ↓
mail
   ↓
Email

8. 🗃️ Database Notification

Một tính năng rất hay của Laravel Notification là lưu thông báo vào Database.

Ví dụ:

🔔 Thông báo

Có bài viết mới.

5 phút trước

Notification:

public function via(object $notifiable): array
{
    return [
        'database',
    ];
}

Sau đó định nghĩa:

public function toDatabase(
    object $notifiable
): array {
    return [
        'title' => 'Có bài viết mới',
        'message' => 'Một bài viết vừa được xuất bản.',
    ];
}

Laravel sẽ lưu dữ liệu Notification vào database.

9. 🗄️ Tạo bảng Notifications

Laravel cung cấp Artisan command:

php artisan make:notifications-table

Sau đó:

php artisan migrate

Laravel tạo bảng:

notifications

Bảng này dùng để lưu các Database Notifications.

Một Notification có thể được liên kết với User thông qua hệ thống polymorphic của Laravel.

Mô hình:

users
  │
  │
  ▼
notifications

10. 🔔 Lấy Notification của User

User có thể truy cập các Notification của mình:

$user->notifications

Ví dụ:

foreach ($user->notifications as $notification) {

    echo $notification->data['title'];

}

Dữ liệu trong data chính là dữ liệu mà chúng ta trả về từ:

toDatabase()

Ví dụ:

return [
    'title' => 'Có bài viết mới',
    'message' => 'Laravel 13 đã ra mắt.',
];

11. 🆕 Unread Notifications

Laravel cũng hỗ trợ phân biệt:

Unread
Read

Có thể lấy Notification chưa đọc:

$user->unreadNotifications

Ví dụ:

$count = $user
    ->unreadNotifications
    ->count();

Sau đó hiển thị trên Navbar:

🔔 5

12. 👀 Đánh dấu Notification đã đọc

Khi người dùng mở Notification:

$notification->markAsRead();

Ví dụ:

foreach ($user->unreadNotifications as $notification) {

    $notification->markAsRead();

}

Có thể đánh dấu tất cả:

$user->unreadNotifications
    ->markAsRead();

Mô hình:

NEW
 │
 ▼
Unread
 │
 │ User mở
 ▼
Read

13. 🗑️ Xóa Notification

Notification không nhất thiết phải tồn tại mãi mãi.

Có thể xóa:

$notification->delete();

Hoặc:

$user->notifications()->delete();

Ví dụ trong trang:

🔔 Notifications

Có bài viết mới
Đơn hàng đã giao
Tài khoản đã được cập nhật

[ Xóa tất cả ]

14. 📝 Markdown Notification

Laravel cũng hỗ trợ Notification sử dụng Markdown.

Ví dụ:

return (new MailMessage)
    ->subject('Bài viết mới')
    ->greeting('Xin chào!')
    ->line('Một bài viết mới vừa được xuất bản.')
    ->action(
        'Xem bài viết',
        url('/blog')
    )
    ->line('Cảm ơn bạn!');

Laravel sẽ tạo email dựa trên các thành phần Markdown Mail Notification.

Điều này giúp chúng ta không phải tự xây dựng toàn bộ HTML email.

15. 🔀 Một Notification — nhiều Channel

Đây mới là sức mạnh thực sự.

Ví dụ:

public function via(object $notifiable): array
{
    return [
        'mail',
        'database',
    ];
}

Khi:

$user->notify(
    new NewPostNotification($post)
);

Laravel thực hiện:

                  NewPostNotification
                           │
                           ▼
                         via()
                           │
                  ┌────────┴────────┐
                  ▼                 ▼
                Mail             Database
                  │                 │
                  ▼                 ▼
               Email          Notification

Người dùng vừa nhận email:

📧 Có bài viết mới

vừa có Notification trong website:

🔔 Có bài viết mới

16. ⚡ Notification + Queue

Đây là phần rất quan trọng vì chúng ta vừa học Queue ở Bài 35.

Nếu Notification gửi Email:

User Action
    ↓
Notification
    ↓
Email
    ↓
SMTP

Request có thể phải chờ.

Thay vào đó, Notification có thể được đưa vào Queue.

Một Notification có thể implement:

ShouldQueue

Ví dụ:

use Illuminate\Contracts\Queue\ShouldQueue;

class NewPostNotification
    extends Notification
    implements ShouldQueue
{
    use Queueable;
}

Khi đó:

User
 ↓
Notification
 ↓
Queue
 ↓
Response ngay
 ↓
Queue Worker
 ↓
Email / Database / ...

Đây là mô hình rất phù hợp với hệ thống production.

17. 🔄 Event + Listener + Notification

Chúng ta đã học:

Bài 33
Observer

Bài 34
Event & Listener

Bài 35
Queue

Bài 36
Mail

Bây giờ Bài 37 kết nối tất cả:

                 User Action
                     │
                     ▼
                   Event
                     │
                     ▼
                  Listener
                     │
                     ▼
               Notification
                     │
              ┌──────┴──────┐
              ▼             ▼
            Email        Database
              │
              ▼
            Queue

Ví dụ:

Admin publish Post
        ↓
PostPublished
        ↓
SendNewPostNotification
        ↓
NewPostNotification
        ↓
Queue
        ↓
Subscribers

Đây là kiến trúc rất đẹp cho Blog CMS.

18. 📰 Notification trong Blog CMS

Hãy áp dụng vào dự án Blog CMS chúng ta đang xây dựng.

Giả sử có:

User
Post
Category

Một User có thể đăng ký nhận thông báo.

Khi Admin xuất bản Post:

Admin
  │
  ▼
Publish Post
  │
  ▼
Event
  │
  ▼
Listener
  │
  ▼
Notification
  │
  ├───────────────┐
  ▼               ▼
Email          Database

Database Notification:

🔔 Thông báo

Bài viết mới:
Laravel 13 — Notification

[Xem bài viết]

19. 📊 Notification Badge

01 ứng dụng thực tế thường hiển thị số Notification chưa đọc trong navigation.blade.php sau tên user.

Ví dụ Blade:

<x-slot name="trigger">
    <button class="inline-flex items-center px-3 py-2 border border-transparent text-sm leading-4 font-medium rounded-md text-gray-500 bg-white hover:text-gray-700 focus:outline-none transition ease-in-out duration-150">
        <div>{{ Auth::user()->name }}</div>                            

        <!-- Phần Notifications -->
        <div class="hidden sm:flex sm:items-center sm:ms-6" 
            x-data="{ count: {{ Auth::user()->unreadNotifications->count() }} }"
            x-init="
                window.addEventListener('notification-read', e => {
                    if(count > 0) count--;
                });
                window.addEventListener('notification-read-all', e => {
                    count = 0;
                });
            ">
            <a href="{{ route('notifications.index') }}" class="relative inline-flex items-center px-3 py-2 text-gray-500 hover:text-gray-700">
                <!-- Icon chuông -->
                <svg class="h-6 w-6" fill="none" stroke="currentColor" viewBox="0 0 24 24">
                    <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2"
                        d="M15 17h5l-1.405-1.405A2.032 2.032 0 0118 14.158V11a6.002 
                            6.002 0 00-4-5.659V4a2 2 0 10-4 0v1.341C7.67 
                            6.165 6 8.388 6 11v3.159c0 .538-.214 
                            1.055-.595 1.436L4 17h5m6 0v1a3 3 0 
                            11-6 0v-1m6 0H9" />
                </svg>

                <!-- Badge số lượng -->
                <template x-if="count > 0">
                    <span class="absolute top-0 right-0 inline-flex items-center justify-center px-2 py-1 text-xs font-bold leading-none text-white bg-red-600 rounded-full"
                        x-text="count"></span>
                </template>
            </a>
        </div>
        <!-- END Phần Notifications -->
        

Kết quả:

┌───────────────┐
│ 🔔 3          │
└───────────────┘

Người dùng click:

🔔
 ↓
Notifications
 ↓
Mark as Read

20. 📋 Trang Notification

1. Tạo route trong routes/web.php

// bài 37 - Notifications
use App\Http\Controllers\NotificationController;
Route::prefix('notifications')->name('notifications.')->middleware('auth')->group(function () {
    // 1. Khai báo các route TĨNH trước
    Route::get('/', [NotificationController::class, 'index'])->name('index');
    Route::post('/read-all', [NotificationController::class, 'markAllAsRead'])->name('readAll');
    Route::delete('/delete-all', [NotificationController::class, 'deleteAll'])->name('deleteAll');

    // 2. Khai báo các route CÓ THAM SỐ {id} sau
    Route::post('/{id}/read', [NotificationController::class, 'markAsRead'])->name('read');
    Route::delete('/{id}', [NotificationController::class, 'destroy'])->name('destroy');
});

2. Tạo controller

php artisan make:controller NotificationController

Trong file app/Http/Controllers/NotificationController.php

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class NotificationController extends Controller
{
    public function index()
    {
        $notifications = auth()->user()->notifications;
        return view('notifications.index', compact('notifications'));
    }

    public function markAsRead($id)
    {
        $notification = auth()->user()->notifications()->find($id);

        if ($notification) {
            $notification->markAsRead();
        }

        return redirect()->route('notifications.index');
    }

    public function markAllAsRead()
    {
        // Đánh dấu tất cả thông báo chưa đọc của user hiện tại thành đã đọc
        auth()->user()->unreadNotifications->markAsRead();

        return response()->json(['success' => true]);
    }

    public function deleteAll()
    {
        // Xóa toàn bộ thông báo (cả đã đọc lẫn chưa đọc) của user hiện tại
        auth()->user()->notifications()->delete();

        return response()->json(['success' => true]);
    }

    public function destroy($id)
    {
        $notification = auth()->user()->notifications()->findOrFail($id);
        $notification->delete();

        return response()->json(['success' => true]);
    }

}

3. Tạo view resources/views/notifications/index.blade.php

<x-app-layout>
    <div class="max-w-7xl mx-auto py-8" 
         x-data="{ 
            unreadCount: {{ auth()->user()->unreadNotifications->count() }},
            allRead: false,
            allDeleted: false
         }">

        <x-ui.card>
            <!-- THANH TIÊU ĐỀ & CÁC NÚT THAO TÁC HÀNG LOẠT -->
            <div class="flex items-center justify-between mb-4 border-b pb-3">
                <h1 class="text-2xl font-bold flex items-center">
                    Thông báo
                    <template x-if="unreadCount > 0">
                        <span class="ml-2 inline-flex items-center px-2 py-1 text-xs font-bold leading-none text-white bg-red-600 rounded-full"
                              x-text="unreadCount"></span>
                    </template>
                </h1>

                <div class="flex items-center space-x-4">
                    <!-- Nút Đánh dấu tất cả đã đọc -->
                    <button 
                        x-show="unreadCount > 0"
                        @click.prevent="
                            fetch('{{ route('notifications.readAll') }}', {
                                method: 'POST',
                                headers: {
                                    'X-CSRF-TOKEN': '{{ csrf_token() }}',
                                    'Accept': 'application/json'
                                }
                            }).then(res => res.json())
                              .then(data => {
                                  if(data.success){
                                      unreadCount = 0;
                                      allRead = true;
                                  }
                              })
                        "
                        class="text-sm text-blue-600 hover:text-blue-800 font-medium hover:underline">
                        Đánh dấu tất cả là đã đọc
                    </button>

                    <!-- Nút Xóa tất cả thông báo -->
                    <button 
                        @click.prevent="
                            if (confirm('Bạn có chắc chắn muốn xóa TẤT CẢ thông báo?')) {
                                fetch('{{ route('notifications.deleteAll') }}', {
                                    method: 'DELETE',
                                    headers: {
                                        'X-CSRF-TOKEN': '{{ csrf_token() }}',
                                        'Accept': 'application/json'
                                    }
                                }).then(res => res.json())
                                  .then(data => {
                                      if(data.success){
                                          unreadCount = 0;
                                          allDeleted = true;
                                      }
                                  })
                            }
                        "
                        class="text-sm text-red-600 hover:text-red-800 font-medium hover:underline">
                        Xóa tất cả
                    </button>
                </div>
            </div>

            <!-- DANH SÁCH THÔNG BÁO -->
            <template x-if="!allDeleted">
                <div>
                    @forelse($notifications as $notification)
                        <div class="border-b py-3 flex items-center justify-between" 
                             x-data="{ 
                                read: {{ $notification->read_at ? 'true' : 'false' }}, 
                                deleted: false 
                             }"
                             x-show="!deleted"
                             x-transition>

                            <div>
                                <strong>{{ $notification->data['title'] }}</strong>
                                <p class="text-gray-600 text-sm">{{ $notification->data['slug'] }}</p>
                            </div>

                            <div class="flex items-center space-x-3">
                                <!-- Trạng thái Đã đọc / Chưa đọc lẻ -->
                                <template x-if="!read && !allRead">
                                    <button 
                                        @click.prevent="
                                            fetch('{{ route('notifications.read', $notification->id) }}', {
                                                method: 'POST',
                                                headers: {
                                                    'X-CSRF-TOKEN': '{{ csrf_token() }}',
                                                    'Accept': 'application/json'
                                                }
                                            }).then(res => res.json())
                                              .then(data => {
                                                  if(data.success){
                                                      read = true;
                                                      if(unreadCount > 0) unreadCount--;
                                                  }
                                              })
                                        "
                                        class="text-blue-600 hover:underline text-sm">
                                        Đánh dấu đã đọc
                                    </button>
                                </template>

                                <template x-if="read || allRead">
                                    <span class="text-gray-400 text-sm">Đã đọc</span>
                                </template>

                                <!-- Nút Xóa từng thông báo -->
                                <button 
                                    @click.prevent="
                                        if (confirm('Bạn có chắc muốn xóa thông báo này?')) {
                                            fetch('{{ route('notifications.destroy', $notification->id) }}', {
                                                method: 'DELETE',
                                                headers: {
                                                    'X-CSRF-TOKEN': '{{ csrf_token() }}',
                                                    'Accept': 'application/json'
                                                }
                                            }).then(res => res.json())
                                              .then(data => {
                                                  if(data.success){
                                                      if(!read && !allRead && unreadCount > 0) {
                                                          unreadCount--;
                                                      }
                                                      deleted = true;
                                                  }
                                              })
                                        }
                                    "
                                    class="text-red-600 hover:underline text-sm">
                                    Xóa
                                </button>
                            </div>

                        </div>
                    @empty
                        <p class="text-gray-500 py-4">Không có thông báo nào.</p>
                    @endforelse
                </div>
            </template>

            <!-- THÔNG BÁO KHI ĐÃ XÓA SẠCH SẼ -->
            <template x-if="allDeleted">
                <p class="text-gray-500 py-4">Không có thông báo nào.</p>
            </template>
        </x-ui.card>
    </div>
</x-app-layout>

21. 🧱 Notification nên chứa gì?

Không nên nhồi quá nhiều dữ liệu vào Notification.

Ví dụ tốt:

return [
    'title' => 'Bài viết mới',
    'message' => 'Laravel 13 — Notification',
    'post_id' => $post->id,
];

Sau đó có thể dùng:

$post = Post::find(
    $notification->data['post_id']
);

Hoặc tốt hơn, xây dựng URL từ ID:

url('/posts/' . $notification->data['post_id'])

Mục tiêu là Notification chỉ chứa những thông tin cần thiết.

22. 🧠 Notification không thay thế Event

Hai khái niệm này khác nhau.

Event

Mô tả:

Một chuyện gì đó đã xảy ra.

Ví dụ:

PostPublished

Notification

Mô tả:

Thông báo cho ai đó về chuyện đó.

Ví dụ:

NewPostNotification

Có thể hình dung:

EVENT
"Post đã được publish"
       │
       ▼
LISTENER
"Thông báo cho subscribers"
       │
       ▼
NOTIFICATION
"Có bài viết mới"

23. 📧 Notification hay Mailable?

Có thể dùng quy tắc đơn giản:

Dùng Mailable khi:

Email phức tạp
Hóa đơn
Báo giá
PDF
Email marketing
Email template riêng

Dùng Notification khi:

Thông báo hệ thống
Thông báo bài viết
Thông báo đơn hàng
Thông báo tài khoản
Unread notification
Nhiều channel

Ví dụ:

Invoice
   ↓
Mailable

Trong khi:

"Đơn hàng của bạn đã được giao"
   ↓
Notification
   ├── Email
   └── Database

24. 🧪 Test Notification

Khi viết Test, chúng ta không muốn gửi Notification thật.

Laravel cung cấp:

Notification::fake();

Sau đó:

$user->notify(
    new NewPostNotification($post)
);

Kiểm tra:

Notification::assertSentTo(
    $user,
    NewPostNotification::class
);

Mô hình:

Test
 ↓
Notification::fake()
 ↓
Action
 ↓
Notification
 ↓
Assert

Không có email thật được gửi đi.

25. 🎯 Bài tập thực hành

Bây giờ hãy xây dựng Notification cho Blog CMS.

Bước 1 — Tạo Notification

php artisan make:notification NewPostNotification

Bước 2 — Notification nhận Post

public function __construct(
    public Post $post
) {}

Bước 3 — Chọn channel

public function via(object $notifiable): array
{
    return [
        'mail',
        'database',
    ];
}

Bước 4 — Mail

public function toMail(
    object $notifiable
): MailMessage {

    return (new MailMessage)
        ->subject('Có bài viết mới')
        ->greeting('Xin chào!')
        ->line(
            'Một bài viết mới vừa được xuất bản.'
        )
        ->action(
            'Xem bài viết',
            url('/posts/' . $this->post->id)
        );
}

Bước 5 — Database

public function toDatabase(
    object $notifiable
): array {

    return [
        'title' => 'Có bài viết mới',
        'message' => $this->post->title,
        'post_id' => $this->post->id,
    ];
}

Bước 6 — Gửi Notification

$user->notify(
    new NewPostNotification($post)
);

Bước 7 — Queue

Sau khi Notification hoạt động ổn định, chuyển sang:

implements ShouldQueue

Sau đó chạy:

php artisan queue:work

Khi đó hệ thống sẽ có:

Publish Post
     ↓
Notification
     ↓
Queue
     ↓
Worker
     ├── Email
     └── Database

26. 🏆 Kiến trúc Blog CMS sau Bài 37

Sau 37 bài, dự án của chúng ta bắt đầu có kiến trúc khá hoàn chỉnh:

                         BLOG CMS
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
           Request         Event          Model
              │              │              │
              ▼              ▼              ▼
         Controller       Listener       Eloquent
              │              │
              │              ▼
              │         Notification
              │              │
              │       ┌──────┴──────┐
              │       ▼             ▼
              │     Mail         Database
              │       │
              │       ▼
              │     Queue
              │       │
              └───────┴──────────────► User

Đây không còn đơn thuần là:

Route
 ↓
Controller
 ↓
View

mà đã bắt đầu trở thành một ứng dụng có kiến trúc thực tế.

27. 📌 Những kiến thức cần nhớ

28. 🔥 Tổng kết Bài 37

Notification giải quyết một bài toán rất phổ biến:

Làm thế nào để thông báo cho người dùng mà không phải tự xây dựng một hệ thống riêng cho từng loại thông báo?

Laravel cho phép chúng ta xây dựng:

                    🔔 Notification
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
           📧 Mail      🗃️ Database   💬 Channel khác
              │            │
              ▼            ▼
           Email       Notification
                           │
                           ▼
                         User

Và khi kết hợp với Queue:

Event
  ↓
Listener
  ↓
Notification
  ↓
Queue
  ↓
Worker
  ↓
Mail / Database

Đây là một trong những mô hình rất đáng học vì nó kết nối trực tiếp những kiến thức chúng ta đã học từ Bài 33 → Bài 37:

33 — Observer
       ↓
34 — Event & Listener
       ↓
35 — Queue
       ↓
36 — Mail
       ↓
37 — Notification

📘 Bài tiếp theo — Bài 38: Cache

Chúng ta sẽ chuyển từ bài toán:

"Làm sao thông báo cho User?"

sang:

"Làm sao để Laravel không phải truy vấn Database liên tục?"

và bắt đầu tìm hiểu:

Cache
Redis
File Cache
Database Cache
remember()
forget()
flush()
Cache::put()
Cache::get()

Đây sẽ là bước đầu tiên để tối ưu hiệu năng Laravel 13.

x1
quay về MỤC LỤC

Sau 4 phần, chúng ta đã xây được một quy trình:

TÌM SẢN PHẨM
    ↓
TÌM KHÁCH
    ↓
LÀM NỘI DUNG
    ↓
QUẢNG CÁO
    ↓
BÁN HÀNG
    ↓
KHÁCH MUA LẠI
    ↓
GOOGLE + WEBSITE

Nhưng khi bắt đầu làm thật, bạn sẽ gặp một vấn đề:

Có quá nhiều việc phải làm.

Mỗi ngày có thể phải:

• Nghĩ ý tưởng.

• Viết bài.

• Viết tiêu đề.

• Làm hình.

• Làm video.

• Trả lời khách.

• Phân tích quảng cáo.

• Theo dõi đơn.

• Chăm sóc khách cũ.

Nếu một người tự làm tất cả, rất dễ rơi vào tình trạng:

Sáng:     Nghĩ nội dung
Trưa:     Làm video
Chiều:    Trả lời khách
Tối:      Phân tích quảng cáo
Đêm:      Chuẩn bị bài ngày mai

Và đây là lúc AI trở thành một trợ lý cực kỳ hữu ích.

Nhưng cần hiểu đúng:

AI không phải cỗ máy tự động kiếm tiền.

AI là công cụ giúp bạn:

làm nhanh hơn, thử nhiều hơn và phân tích tốt hơn.

🤖 23. Dùng AI tìm ý tưởng sản phẩm

Một trong những công việc khó nhất khi bán hàng là:

Bán cái gì?

Nếu chọn sai sản phẩm, tất cả những bước phía sau đều khó.

AI có thể giúp bạn nghiên cứu ban đầu.

Ví dụ bạn muốn bán đồ cho:

🏠 gia đình

Thay vì ngồi suy nghĩ:

Bán gì?
Bán gì?
Bán gì?

Bạn có thể yêu cầu AI phân tích:

Khách hàng:
Gia đình trẻ

Hãy liệt kê:
- những vấn đề thường gặp
- sản phẩm có thể giải quyết
- sản phẩm dễ làm nội dung
- sản phẩm có khả năng mua lại
- sản phẩm có thể bán kèm

AI có thể biến một thị trường lớn thành:

THỊ TRƯỜNG
    ↓
VẤN ĐỀ
    ↓
NHU CẦU
    ↓
SẢN PHẨM
    ↓
Ý TƯỞNG KINH DOANH

🧠 Nhưng AI không biết chắc sản phẩm nào sẽ bán được

Đây là điều phải nhớ.

AI có thể đưa ra:

giả thuyết.

Nhưng thị trường mới đưa ra:

câu trả lời.

Ví dụ AI nói:

"Bình giữ nhiệt là sản phẩm tiềm năng."

Điều đó không có nghĩa bạn nhập 1.000 chiếc về sẽ bán hết.

Phải kiểm tra:

AI
 ↓
Ý tưởng
 ↓
Kiểm tra thị trường
 ↓
Test nội dung
 ↓
Có người hỏi?
 ↓
Có người mua?
 ↓
CÓ
 ↓
MỚI TĂNG QUY MÔ

🔎 AI có thể giúp nghiên cứu theo 5 hướng

1. 👥 Khách hàng

Khách là ai?

2. 😣 Nỗi đau

Họ đang gặp vấn đề gì?

3. 💰 Khả năng chi trả

Họ có sẵn sàng trả tiền không?

4. 🔄 Tần suất mua

Có mua lại không?

5. ➕ Sản phẩm liên quan

Có thể bán thêm gì?

🎯 Ví dụ

Bạn muốn bán:

🎧 Tai nghe Bluetooth.

AI có thể giúp bạn xây bản đồ:

Tai nghe
  │
  ├── Người đi tập
  │      ├── Nhẹ
  │      ├── Không rơi
  │      └── Chống mồ hôi
  │
  ├── Người đi làm
  │      ├── Gọi điện
  │      ├── Chống ồn
  │      └── Pin lâu
  │
  └── Game thủ
         ├── Độ trễ thấp
         ├── Micro
         └── Âm thanh

Từ một sản phẩm, bạn đã có nhiều nhóm khách hàng.

Và mỗi nhóm lại có:

một lý do mua khác nhau.

✍️ 24. Dùng AI sản xuất nội dung

Đây có lẽ là ứng dụng dễ thấy nhất.

Bạn có một sản phẩm.

Thay vì mỗi ngày phải tự nghĩ:

"Hôm nay đăng gì?"

AI có thể giúp tạo ra:

1 sản phẩm
    ↓
10 vấn đề
    ↓
10 ý tưởng video
    ↓
10 tiêu đề
    ↓
10 bài viết
    ↓
10 kịch bản

Một sản phẩm có thể trở thành:

hàng chục hoặc hàng trăm nội dung khác nhau.

🎬 Công thức biến sản phẩm thành nội dung

Ví dụ:

☕ Máy pha cà phê mini.

AI có thể giúp bạn tạo:

Nội dung 1 — Vấn đề

"Tại sao cà phê ở nhà thường không ngon bằng quán?"

Nội dung 2 — Hướng dẫn

"3 bước pha cà phê nhanh trước khi đi làm."

Nội dung 3 — So sánh

"Máy pha cà phê mini khác gì máy thông thường?"

Nội dung 4 — Tình huống

"7 giờ sáng, bạn không muốn xếp hàng mua cà phê..."

Nội dung 5 — Review

"Dùng máy pha cà phê mini 30 ngày, đây là điều tôi nhận ra."

🧠 AI không chỉ viết bài

Bạn có thể sử dụng AI cho toàn bộ dây chuyền:

Ý tưởng
  ↓
Tiêu đề
  ↓
Hook
  ↓
Kịch bản
  ↓
Caption
  ↓
CTA
  ↓
Lịch đăng

Ví dụ:

Sản phẩm:
Bình giữ nhiệt

       ↓

50 ý tưởng

       ↓

10 ý tưởng tốt nhất

       ↓

5 kịch bản

       ↓

3 video thử nghiệm

       ↓

Video hiệu quả nhất

       ↓

Làm thêm biến thể

Đây là cách sử dụng AI thông minh hơn:

AI tạo số lượng → con người chọn chất lượng.

🎣 Hook — 3 giây đầu tiên

Video bán hàng thường cần gây chú ý rất nhanh.

AI có thể tạo nhiều kiểu Hook:

❓ "Bạn có đang mắc lỗi này không?"

😱 "Đừng mua sản phẩm này trước khi biết điều này."

💡 "Có một cách đơn giản để..."

⚠️ "90% người dùng đang làm sai..."

🎯 "Nếu bạn đang gặp vấn đề này, hãy xem..."

Nhưng đừng biến mọi video thành:

"90% người dùng..."

"Bạn sẽ không tin..."

"Đừng bỏ qua..."

Nếu dùng quá nhiều, nội dung sẽ trở nên:

giật tít và thiếu tin cậy.

Hook tốt phải liên quan trực tiếp đến nội dung thật.

🎬 25. Dùng AI làm video

Đây là bước tiếp theo.

Trước đây:

Ý tưởng
 ↓
Viết kịch bản
 ↓
Quay
 ↓
Cắt
 ↓
Lồng tiếng
 ↓
Phụ đề
 ↓
Đăng

Có thể mất hàng giờ.

AI có thể hỗ trợ một số công đoạn:

Ý tưởng
 ↓
Kịch bản AI
 ↓
Hình ảnh / video AI
 ↓
Giọng đọc AI
 ↓
Phụ đề tự động
 ↓
Biên tập
 ↓
Đăng

⚠️ Nhưng đừng biến video bán hàng thành "video AI"

Đây là một lỗi rất phổ biến.

AI có thể tạo:

Người mẫu hoàn hảo
+
Căn phòng hoàn hảo
+
Ánh sáng hoàn hảo
+
Giọng nói hoàn hảo

Nhưng khách hàng có thể cảm thấy:

"Đây là quảng cáo AI."

Trong nhiều trường hợp, video quay bằng điện thoại thật lại đáng tin hơn.

Ví dụ:

📱 Tay thật
📦 Sản phẩm thật
🏠 Không gian thật
👤 Người bán thật

Sau đó dùng AI để:

• Viết kịch bản.

• Tạo phụ đề.

• Xóa tạp âm.

• Cắt đoạn thừa.

• Tạo nhiều phiên bản.

• Viết caption.

Đây thường là cách thực tế hơn.

🧠 AI nên làm gì?

Hãy chia công việc:

AI
├── Tìm ý tưởng
├── Viết nháp
├── Phân tích
├── Tạo biến thể
└── Tự động hóa

CON NGƯỜI
├── Chọn sản phẩm
├── Kiểm tra sự thật
├── Quay sản phẩm
├── Kiểm tra chất lượng
├── Nói chuyện với khách
└── Quyết định cuối cùng

AI mạnh ở:

tốc độ + số lượng + xử lý thông tin.

Con người mạnh ở:

phán đoán + trải nghiệm + niềm tin + quyết định.

📊 26. Dùng AI phân tích quảng cáo

Đây là một ứng dụng rất mạnh.

Ở Phần 2, chúng ta đã có các dữ liệu:

Chi phí
Lượt hiển thị
Click
Tin nhắn
Đơn hàng
Doanh thu

Ví dụ:

Quảng cáo A
Chi phí: 500K
Đơn: 2
Doanh thu: 600K

Quảng cáo B
Chi phí: 500K
Đơn: 8
Doanh thu: 2.400K

Quảng cáo C
Chi phí: 500K
Đơn: 5
Doanh thu: 1.500K

Thay vì chỉ nhìn bảng số liệu, bạn có thể đưa dữ liệu cho AI và yêu cầu:

"Hãy tìm quảng cáo có hiệu quả tốt nhất, chỉ ra điểm bất thường và đề xuất các giả thuyết để test tiếp."

AI có thể giúp bạn:

DỮ LIỆU
   ↓
AI PHÂN TÍCH
   ↓
PHÁT HIỆN MẪU
   ↓
ĐẶT GIẢ THUYẾT
   ↓
TEST
   ↓
DỮ LIỆU MỚI

🧮 AI có thể giúp đọc các chỉ số

Ví dụ:

CTR
CPC
CPM
Conversion Rate
CAC
AOV
ROAS

Nhưng phải hiểu:

AI tính toán được không có nghĩa AI hiểu toàn bộ doanh nghiệp của bạn.

Ví dụ ROAS cao nhưng lợi nhuận thấp.

Tại sao?

ROAS cao
   ↓
Doanh thu tốt
   ↓
Nhưng...
   ↓
Giá vốn cao
+
Phí cao
+
Khuyến mãi lớn
   ↓
LỢI NHUẬN THẤP

Vì vậy:

Đừng tối ưu doanh thu nếu mục tiêu thực sự là lợi nhuận.

⚙️ 27. Tự động hóa những việc lặp lại

Đây là cấp độ cao nhất của phần này.

Hãy nhìn một ngày bán hàng:

Khách nhắn tin
      ↓
Trả lời
      ↓
Gửi thông tin
      ↓
Khách đặt hàng
      ↓
Ghi đơn
      ↓
Xác nhận
      ↓
Theo dõi
      ↓
Chăm sóc

Một số bước có thể tự động hóa.

Ví dụ:

KHÁCH ĐIỀN FORM
       ↓
HỆ THỐNG NHẬN DỮ LIỆU
       ↓
LƯU KHÁCH HÀNG
       ↓
GỬI THÔNG BÁO
       ↓
TẠO ĐƠN
       ↓
GỬI XÁC NHẬN

Con người chỉ cần xử lý những trường hợp đặc biệt.

🤖 AI Chatbot

Ví dụ khách hỏi:

"Sản phẩm này còn hàng không?"

AI có thể trả lời dựa trên dữ liệu được cung cấp.

Khách hỏi:

"Bao lâu giao tới?"

Hệ thống có thể đưa ra thông tin phù hợp.

Khách hỏi:

"Có màu đen không?"

AI kiểm tra dữ liệu sản phẩm rồi trả lời.

Nhưng với những trường hợp:

Khiếu nại
Hoàn tiền
Tranh chấp
Khách VIP
Vấn đề phức tạp

nên chuyển cho:

con người.

🔄 Mô hình AI + Con người

Đừng xây:

AI
 ↓
Làm tất cả

Hãy xây:

             CON NGƯỜI
                 │
        ┌────────┴────────┐
        ↓                 ↓
       AI              HỆ THỐNG
        ↓                 ↓
   Tạo / phân tích     Tự động hóa
        │                 │
        └────────┬────────┘
                 ↓
              KẾT QUẢ

AI là:

trợ lý.

Không phải:

ông chủ.

🚀 Từ một người bán hàng thành một "đội ngũ nhỏ"

Hãy tưởng tượng một người bán hàng có:

👤 Bạn
│
├── 🤖 AI nghiên cứu
│
├── ✍️ AI viết nội dung
│
├── 🎬 AI hỗ trợ video
│
├── 📊 AI phân tích dữ liệu
│
├── 💬 Chatbot hỗ trợ khách
│
└── ⚙️ Automation xử lý việc lặp lại

Bạn vẫn chỉ có một người.

Nhưng năng lực sản xuất có thể lớn hơn rất nhiều so với việc làm tất cả bằng tay.

Đây chính là:

Leverage — đòn bẩy.

⚠️ 5 điều không nên giao hoàn toàn cho AI

1. 💰 Quyết định nhập hàng lớn

AI có thể phân tích.

Bạn phải quyết định.

2. 📢 Chi ngân sách quảng cáo lớn

AI có thể đề xuất.

Bạn phải kiểm soát.

3. 🧾 Thông tin sản phẩm

AI có thể viết.

Bạn phải kiểm tra.

4. 🤝 Quan hệ với khách hàng quan trọng

AI có thể hỗ trợ.

Con người nên xử lý khi cần.

5. ⚖️ Quyết định kinh doanh

AI có thể đưa ra nhiều góc nhìn.

Nhưng:

người chịu trách nhiệm cuối cùng vẫn là bạn.

🧠 Công thức sử dụng AI hiệu quả

Đừng hỏi AI:

"Bán hàng thế nào?"

Hãy đưa cho AI bối cảnh + dữ liệu + mục tiêu.

Ví dụ:

SẢN PHẨM:
Bình giữ nhiệt 500ml

KHÁCH HÀNG:
Nhân viên văn phòng 25–35 tuổi

GIÁ:
299.000đ

LỢI THẾ:
Giữ nhiệt lâu, nhỏ gọn

MỤC TIÊU:
Tạo video TikTok bán hàng

HÃY TẠO:
- 10 Hook
- 5 ý tưởng video
- 3 kịch bản
- CTA cho từng video

Kết quả thường tốt hơn rất nhiều so với:

"Viết cho tôi một bài quảng cáo."

🏗️ AI SALES SYSTEM

Nếu kết hợp toàn bộ những gì đã học:

                  🤖 AI
                   │
       ┌───────────┼───────────┐
       ↓           ↓           ↓
    NGHIÊN CỨU   NỘI DUNG    PHÂN TÍCH
       │           │           │
       └───────────┼───────────┘
                   ↓
              MARKETING
                   ↓
          ┌────────┴────────┐
          ↓                 ↓
      TỰ NHIÊN           QUẢNG CÁO
          ↓                 ↓
          └────────┬────────┘
                   ↓
                WEBSITE
                   ↓
               ĐƠN HÀNG
                   ↓
              KHÁCH HÀNG
                   ↓
              MUA LẠI
                   ↓
                LTV ↑

Đây mới là cách nhìn AI trong kinh doanh:

Không phải "AI làm thay tôi".

Mà là:

"AI giúp hệ thống bán hàng của tôi mạnh hơn."

🧪 BÀI TẬP THỰC HÀNH

Chọn một sản phẩm thật.

Sau đó dùng AI thực hiện 5 nhiệm vụ:

🤖 Nhiệm vụ 1

Tạo:

30 ý tưởng nội dung.

✍️ Nhiệm vụ 2

Chọn 5 ý tưởng tốt nhất và viết:

5 kịch bản video.

🎬 Nhiệm vụ 3

Tạo:

3 phiên bản Hook cho mỗi video.

📊 Nhiệm vụ 4

Sau khi chạy quảng cáo, đưa dữ liệu vào AI và yêu cầu:

Phân tích quảng cáo nào tốt/xấu và đưa ra giả thuyết test tiếp theo.

⚙️ Nhiệm vụ 5

Liệt kê tất cả công việc lặp lại trong quy trình bán hàng và đánh dấu:

🟢 Có thể tự động hóa
🟡 AI có thể hỗ trợ
🔴 Cần con người

🏆 KẾT THÚC PHẦN 5

Bây giờ toàn bộ hệ thống đã tiến thêm một bước:

PHẦN 1
📱 Kiếm khách tự nhiên

        ↓

PHẦN 2
💰 Dùng tiền mua khách

        ↓

PHẦN 3
🔥 Kiếm nhiều hơn từ khách cũ

        ↓

PHẦN 4
🌐 Google + Website

        ↓

PHẦN 5
🤖 AI + Automation

Nhưng AI không phải điểm kết thúc.

Điểm quan trọng nhất vẫn là:

Làm thật.

Chọn một sản phẩm.

Đưa lên một kênh.

Tạo nội dung.

Tìm khách.

Chạy thử quảng cáo.

Nhận đơn.

Ghi lại doanh thu.

Ghi lại chi phí.

Tính lợi nhuận.

Sau đó:

tối ưu.

Và đó chính là bước chuyển từ học bán hàng sang làm kinh doanh thật.

🏆 PHẦN 6 — LÀM RA TIỀN THẬT

28. 🧪 Chọn một sản phẩm thật
29. 📱 Dựng kênh bán hàng thật
30. 💰 Chạy chiến dịch thật
31. 📊 Đo tiền vào — tiền ra
32. 🚀 Tối ưu để có lợi nhuận
33. 🏆 Xây hệ thống bán hàng có thể chạy mỗi ngày

quay về MỤC LỤC

Ở Phần 1, chúng ta tìm khách bằng nội dung.

Ở Phần 2, chúng ta dùng tiền để mua khách bằng quảng cáo.

Ở Phần 3, chúng ta học cách kiếm nhiều tiền hơn từ khách hàng cũ.

Nhưng còn một nguồn khách cực kỳ đặc biệt:

Những người đang chủ động đi tìm thứ họ muốn mua.

Ví dụ một người mở Google và gõ:

"mua máy in gần đây"

hoặc:

"bàn phím cơ giá rẻ"

hoặc:

"cửa hàng sửa laptop quận 1"

Đây là những khách hàng có ý định mua rất rõ ràng.

Thay vì cố làm cho họ nhìn thấy quảng cáo, chúng ta có thể xây dựng hệ thống để:

Khi khách tìm → sản phẩm của chúng ta xuất hiện.

🔎 19. Đưa sản phẩm lên Google

Google không chỉ là nơi tìm thông tin.

Google cũng là:

một cái chợ khổng lồ.

Mỗi ngày có rất nhiều người tìm kiếm:

sản phẩm
dịch vụ
giá cả
địa điểm
đánh giá
so sánh

Ví dụ:

"giày chạy bộ nam"

"mua nồi cơm điện"

"máy lọc nước giá bao nhiêu"

"shop bán phụ kiện điện thoại"

Người tìm kiếm đã có một vấn đề.

Nhiệm vụ của chúng ta là:

KHÁCH TÌM
   ↓
GOOGLE
   ↓
THẤY BẠN
   ↓
CLICK
   ↓
XEM SẢN PHẨM
   ↓
MUA

🧠 Google khác Facebook/TikTok như thế nào?

Đây là điểm rất quan trọng.

Trên Facebook hoặc TikTok:

Bạn tìm khách.

Trên Google:

Khách tìm bạn.

Ví dụ:

📱 TikTok

Bạn làm video:

"5 lỗi khiến điện thoại nhanh hết pin."

Người dùng đang xem video giải trí.

Bạn phải tạo sự chú ý.

🔎 Google

Người dùng gõ:

"thay pin iPhone gần đây"

Họ đã có nhu cầu.

Họ đang tìm nơi mua hoặc sử dụng dịch vụ.

Vì vậy có thể hình dung:

Facebook / TikTok

KHÁCH
  ↑
  │
BẠN ĐI TÌM KHÁCH


Google

BẠN
  ↑
  │
KHÁCH ĐI TÌM BẠN

Đây là lý do Google Search rất có giá trị đối với hoạt động bán hàng.

🏪 20. Làm trang bán hàng có khả năng chốt đơn

Đưa khách từ Google về website mới chỉ là một nửa công việc.

Nếu khách click vào:

https://example.com

mà nhìn thấy:

Trang chủ
Tin tức
Sản phẩm
Danh mục
Banner
Menu
...

nhưng không biết phải làm gì tiếp theo, khách có thể rời đi.

Website bán hàng cần trả lời thật nhanh:

Bạn bán gì?

Giá bao nhiêu?

Tại sao tôi nên mua?

Mua như thế nào?

🎯 Một trang sản phẩm đơn giản

Có thể thiết kế:

┌──────────────────────────────┐
│          HÌNH SẢN PHẨM       │
│                              │
├──────────────────────────────┤
│ TÊN SẢN PHẨM                 │
│                              │
│ ⭐⭐⭐⭐⭐                     │
│                              │
│ 💰 299.000đ                  │
│                              │
│ ✓ Lợi ích 1                  │
│ ✓ Lợi ích 2                  │
│ ✓ Lợi ích 3                  │
│                              │
│ [ 🛒 MUA NGAY ]              │
│ [ 💬 NHẮN TIN ]              │
│                              │
└──────────────────────────────┘

Không cần website quá phức tạp.

Một trang bán hàng tốt thường quan trọng hơn một website có hàng trăm tính năng nhưng khiến khách khó mua.

🧲 Landing Page

Một trang được thiết kế chủ yếu để thuyết phục khách thực hiện một hành động thường được gọi là:

Landing Page

Ví dụ:

GOOGLE
   ↓
Landing Page
   ↓
Thông tin sản phẩm
   ↓
Lợi ích
   ↓
Đánh giá
   ↓
Giá
   ↓
Ưu đãi
   ↓
MUA NGAY

✍️ Công thức một Landing Page đơn giản

Có thể bắt đầu bằng 7 phần:

1. 🎯 Tiêu đề

Nói ngay sản phẩm giải quyết vấn đề gì.

2. 🖼️ Hình ảnh

Cho khách thấy sản phẩm.

3. 💎 Lợi ích

Tại sao khách nên quan tâm?

4. 🧪 Bằng chứng

Đánh giá, hình ảnh khách hàng, trải nghiệm thực tế...

5. 💰 Giá

Nói rõ giá.

6. 🎁 Ưu đãi

Nếu có.

7. 🛒 CTA

Một hành động rõ ràng:

Mua ngay

Đặt hàng

Nhắn tin

Gọi ngay

📱 Website phải hoạt động tốt trên điện thoại

Đây là điều không được xem nhẹ.

Rất nhiều khách hàng đến từ:

TikTok
Facebook
Google

và phần lớn có thể truy cập bằng điện thoại.

Nếu website:

❌ chữ quá nhỏ
❌ nút khó bấm
❌ ảnh quá lớn
❌ tải quá chậm
❌ form quá dài

thì bạn có thể mất khách ngay cả khi đã đưa họ đến website.

Hãy kiểm tra:

📱 Mobile
💻 Desktop

và đặc biệt:

Khách có thể hiểu sản phẩm trong vài giây đầu tiên hay không?

📍 21. Kéo khách quanh khu vực cửa hàng

Nếu bạn có cửa hàng vật lý, Google còn mạnh hơn nữa.

Ví dụ:

"Cửa hàng laptop gần tôi"

"tiệm sửa điện thoại gần đây"

"quán ăn gần đây"

"mua hoa gần tôi"

Người tìm kiếm không chỉ muốn:

biết thông tin.

Họ có thể muốn:

đi đến cửa hàng ngay.

🗺️ Google Maps là một "mặt tiền cửa hàng"

Hãy tưởng tượng một người đang đứng cách cửa hàng của bạn 2 km.

Họ mở Google và tìm:

"sửa laptop"

Nếu thông tin doanh nghiệp của bạn xuất hiện:

🏪 Tên cửa hàng

⭐ 4.8
📍 1.2 km
🕐 Đang mở cửa
📞 Gọi
🗺️ Chỉ đường
🌐 Website

thì Google đã trở thành:

người dẫn khách đến cửa hàng.

🧾 Hồ sơ doanh nghiệp cần đầy đủ

Một doanh nghiệp địa phương nên chú ý đến những thông tin cơ bản:

Tên
Địa chỉ
Số điện thoại
Giờ mở cửa
Website
Danh mục
Hình ảnh
Sản phẩm / dịch vụ
Đánh giá

Thông tin càng rõ ràng, khách càng dễ quyết định.

Đặc biệt:

Đừng để khách phải đi tìm số điện thoại hoặc địa chỉ.

⭐ Đánh giá của khách hàng

Hãy tưởng tượng hai cửa hàng:

Cửa hàng A
⭐⭐⭐⭐⭐
350 đánh giá


Cửa hàng B
⭐⭐⭐
12 đánh giá

Nếu những yếu tố khác tương đương, khách thường có xu hướng tin cửa hàng có nhiều bằng chứng xã hội hơn.

Nhưng:

Đừng mua đánh giá giả.

Hãy xây dựng trải nghiệm đủ tốt để khách thật sự muốn đánh giá.

Sau khi khách mua hàng, có thể gửi một lời nhắc đơn giản:

"Nếu anh/chị hài lòng với sản phẩm, rất mong anh/chị dành một phút để đánh giá cửa hàng."

🛍️ 22. Bán hàng từ Google Search

Bây giờ chúng ta ghép toàn bộ hệ thống lại.

Một khách hàng có thể đi qua hành trình:

🔎 TÌM KIẾM
"máy lọc nước tốt"

        ↓

🌐 GOOGLE

        ↓

🏪 WEBSITE / TRANG SẢN PHẨM

        ↓

👀 XEM THÔNG TIN

        ↓

⭐ XEM ĐÁNH GIÁ

        ↓

💰 XEM GIÁ

        ↓

🛒 ĐẶT HÀNG

        ↓

💵 DOANH THU

Đây là một phễu bán hàng từ Google.

🎯 SEO — Xuất hiện tự nhiên trên Google

Có hai con đường chính để xuất hiện trên Google:

             GOOGLE
                │
        ┌───────┴───────┐
        ↓               ↓
     QUẢNG CÁO        TỰ NHIÊN
        ↓               ↓
    Google Ads          SEO

💵 Google Ads

Bạn trả tiền để quảng cáo có thể xuất hiện cho những tìm kiếm phù hợp.

🌱 SEO

Bạn xây dựng nội dung và website để có cơ hội xuất hiện trong kết quả tìm kiếm tự nhiên.

Quảng cáo có thể đưa khách đến nhanh hơn.

SEO thường cần thời gian hơn.

Nhưng nếu làm tốt, website có thể tiếp tục tạo ra lượng truy cập mà không phải trả tiền cho từng lượt click tự nhiên.

📝 Ví dụ SEO rất đơn giản

Giả sử bạn bán:

Máy lọc nước gia đình

Thay vì chỉ có một trang:

/products/may-loc-nuoc

Bạn có thể xây dựng thêm nội dung:

/may-loc-nuoc-gia-dinh

/may-loc-nuoc-cho-can-ho

/may-loc-nuoc-gia-bao-nhieu

/cach-chon-may-loc-nuoc

/may-loc-nuoc-nao-tot

/so-sanh-may-loc-nuoc

Mỗi nội dung có thể trả lời một nhu cầu tìm kiếm khác nhau.

             WEBSITE
                │
       ┌────────┼────────┐
       ↓        ↓        ↓
   Sản phẩm   Hướng dẫn  So sánh
       │        │        │
       └────────┼────────┘
                ↓
             GOOGLE
                ↓
             KHÁCH

🧠 Đừng chỉ SEO từ khóa có ý định mua

Một sai lầm là chỉ nghĩ:

"Tôi phải SEO từ khóa bán hàng."

Không nhất thiết.

Khách có thể trải qua nhiều giai đoạn:

CHƯA BIẾT
   ↓
CÓ VẤN ĐỀ
   ↓
TÌM HIỂU
   ↓
SO SÁNH
   ↓
TÌM SẢN PHẨM
   ↓
MUA

Ví dụ:

"Tại sao nước có mùi?"

        ↓

"Cách lọc nước tại nhà"

        ↓

"Máy lọc nước RO là gì?"

        ↓

"So sánh máy lọc nước A B"

        ↓

"Máy lọc nước A giá bao nhiêu?"

        ↓

"Mua máy lọc nước A"

Nếu website xuất hiện ở nhiều giai đoạn, bạn có cơ hội xây dựng niềm tin trước khi khách mua.

🔥 Google + Website + Nội dung

Đây là lúc những phần trước bắt đầu kết nối với nhau.

             NỘI DUNG
          /      |      \
         ↓       ↓       ↓
    Facebook   TikTok   SEO
         │       │       │
         └───────┼───────┘
                 ↓
              WEBSITE
                 ↓
             KHÁCH HÀNG
                 ↓
              ĐƠN HÀNG
                 ↓
             KHÁCH CŨ
                 ↓
            MUA LẠI

Bạn không còn xây từng kênh riêng biệt.

Bạn đang xây:

một hệ thống kéo khách.

🧪 BÀI TẬP THỰC HÀNH

Hãy chọn một sản phẩm thật.

Sau đó thử tìm trên Google:

"[tên sản phẩm]"

"mua [tên sản phẩm]"

"[tên sản phẩm] giá"

"[tên sản phẩm] tốt"

"[tên sản phẩm] gần tôi"

Ghi lại:

🔎 Khách đang tìm gì?

🏪 Đối thủ nào đang xuất hiện?

🌐 Họ dẫn khách đến đâu?

💰 Giá bán thế nào?

⭐ Có bao nhiêu đánh giá?

📱 Website của họ có dễ mua không?

Sau đó tự hỏi:

"Nếu khách tìm sản phẩm này hôm nay, họ có tìm thấy mình không?"

Nếu câu trả lời là không, bạn đã tìm thấy một cơ hội kinh doanh.

🏗️ XÂY "NGÔI NHÀ" RIÊNG TRÊN INTERNET

Facebook và TikTok giống như những nơi bạn đi thuê mặt bằng.

Google giống như một con đường cực kỳ đông người.

Còn website là:

🏠 ngôi nhà của chính bạn trên Internet.

Bạn có thể xây:

                    WEBSITE
                       │
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
   SẢN PHẨM         NỘI DUNG        KHÁCH HÀNG
       │               │               │
       ↓               ↓               ↓
    BÁN HÀNG           SEO           DỮ LIỆU

Và khác với một bài đăng trên mạng xã hội, website cho phép bạn kiểm soát nhiều hơn:

• Nội dung.

• Sản phẩm.

• Giá.

• Form đặt hàng.

• Dữ liệu khách hàng.

• Hành trình mua hàng.

• SEO.

• Thương hiệu.

💡 TƯ DUY QUAN TRỌNG NHẤT CỦA PHẦN 4

Đừng nghĩ:

"Tôi cần làm một website."

Hãy nghĩ:

"Tôi cần một nơi để biến người đang có nhu cầu thành khách hàng."

Website không phải để cho đẹp.

Website phải làm được:

GOOGLE
  ↓
KHÁCH
  ↓
HIỂU
  ↓
TIN
  ↓
MUA
  ↓
ĐỂ LẠI THÔNG TIN
  ↓
MUA LẠI

Đó mới là website bán hàng.

🏆 KẾT THÚC PHẦN 4

Đến đây, chúng ta đã có 4 mảnh ghép:

🛒 PHẦN 1
KIẾM ĐƠN KHÔNG CẦN QUẢNG CÁO
        ↓
📱 Nội dung + mạng xã hội


💰 PHẦN 2
DÙNG TIỀN ĐỂ MUA KHÁCH
        ↓
🎯 Quảng cáo


🔥 PHẦN 3
KIẾM NHIỀU HƠN TỪ MỘT KHÁCH
        ↓
🔄 Mua lại + bán thêm + giới thiệu


🌐 PHẦN 4
GOOGLE & WEBSITE
        ↓
🔎 Khách chủ động tìm bạn

Nhưng có một vấn đề mới:

Làm tất cả những việc này bằng tay sẽ rất mất thời gian.

Viết bài.

Nghĩ ý tưởng.

Viết quảng cáo.

Làm video.

Phân tích dữ liệu.

Trả lời khách.

Theo dõi đơn hàng.

Lặp đi lặp lại mỗi ngày.

Và đây chính là lúc một công cụ mới xuất hiện:

🤖 PHẦN 5 — AI GIÚP BÁN HÀNG

23. 🤖 Dùng AI tìm ý tưởng sản phẩm
24. ✍️ Dùng AI sản xuất nội dung
25. 🎬 Dùng AI làm video
26. 📊 Dùng AI phân tích quảng cáo
27. ⚙️ Tự động hóa những việc lặp lại

quay về MỤC LỤC

Ở Phần 1, chúng ta học cách kiếm khách mà không cần quảng cáo.

Ở Phần 2, chúng ta học cách dùng tiền để mua thêm khách.

Nhưng có một vấn đề lớn:

Tìm được một khách hàng mới thường tốn tiền và công sức.

Nếu khách mua một lần rồi biến mất, bạn phải quay lại từ đầu:

Tìm khách
   ↓
Quảng cáo
   ↓
Tư vấn
   ↓
Chốt đơn
   ↓
Tìm khách mới
   ↓
Quảng cáo
   ↓
Tư vấn
   ↓
Chốt đơn
   ↓
...

Đây là một mô hình rất mệt.

Một người bán hàng giỏi sẽ đặt câu hỏi khác:

"Khách đã mua rồi, làm sao để họ quay lại?"

Và cao hơn nữa:

"Làm sao để một khách hàng tạo ra nhiều doanh thu hơn trong suốt thời gian họ mua hàng của mình?"

Đó chính là tư duy của Customer Lifetime Value — giá trị vòng đời khách hàng.

🔄 14. Bán lại cho khách cũ

Đây là cách đơn giản nhất để kiếm thêm tiền từ khách hàng hiện tại.

Ví dụ bạn bán:

🧴 Dầu gội

Khách mua hôm nay.

Sau một thời gian, họ sẽ dùng hết.

Thay vì tiếp tục tìm một khách hoàn toàn mới, bạn có thể nhắc khách:

"Chị dùng gần hết dầu gội chưa ạ? Bên em đang có đợt hàng mới."

Đây là bán lại — repeat purchase.

🧠 Tại sao khách cũ dễ bán hơn?

Khách mới:

Chưa biết bạn
    ↓
Chưa tin bạn
    ↓
Phải thuyết phục
    ↓
Mới mua

Khách cũ:

Đã biết sản phẩm
    ↓
Đã biết người bán
    ↓
Đã từng mua
    ↓
Nếu hài lòng
    ↓
Có khả năng mua lại

Bạn không phải bắt đầu từ số 0.

📅 Xây chu kỳ mua hàng

Hãy tìm hiểu:

Khách thường mua lại sau bao lâu?

Ví dụ:

Đây chỉ là ví dụ để tư duy; sản phẩm thực tế phải dựa trên dữ liệu khách hàng của bạn.

Nếu khách thường mua lại sau 30 ngày:

Ngày 0
  ↓
Mua hàng

Ngày 20
  ↓
Nhắc nhẹ

Ngày 30
  ↓
Ưu đãi / đề nghị mua lại

Ngày 40
  ↓
Chăm sóc tiếp

Không cần spam.

Mục tiêu là:

Xuất hiện đúng lúc khách có khả năng cần sản phẩm.

🎁 15. Tạo chương trình khiến khách mua thêm

Khách đã quyết định mua một sản phẩm.

Đây là thời điểm rất tốt để giới thiệu:

sản phẩm bổ sung.

Ví dụ:

Khách mua laptop
      ↓
Có thể cần:
      ├── Chuột
      ├── Bàn phím
      ├── Túi
      └── Đế laptop

Đây gọi là cross-sell — bán chéo.

⬆️ Upsell — bán phiên bản cao hơn

Ví dụ:

Gói cơ bản
299K
   ↓
Gói nâng cao
399K
   ↓
Gói Premium
599K

Thay vì chỉ hỏi:

"Anh/chị có mua không?"

Bạn có thể đưa ra lựa chọn:

"Anh/chị muốn bản tiêu chuẩn hay bản đầy đủ?"

Khách đã có ý định mua sẽ dễ cân nhắc hơn khi các lựa chọn được trình bày rõ ràng.

💰 Một đơn hàng có thể lớn hơn rất nhiều

Giả sử:

100 khách
×
300.000đ
=
30.000.000đ

Nếu tăng giá trị trung bình mỗi đơn lên:

100 khách
×
400.000đ
=
40.000.000đ

Bạn vẫn có:

100 khách

nhưng doanh thu tăng thêm:

10.000.000đ

Đây là lý do không phải lúc nào muốn tăng doanh thu cũng phải tìm thêm khách.

📣 16. Biến khách hàng thành người giới thiệu

Một khách hàng hài lòng có thể trở thành:

một nhân viên bán hàng miễn phí.

Ví dụ bạn bán sản phẩm cho anh A.

Anh A dùng thấy tốt.

Anh A giới thiệu cho:

A
├── B
├── C
└── D

Nếu B, C, D tiếp tục hài lòng:

A
├── B ──┬── E
│       └── F
├── C
└── D ─── G

Khách hàng bắt đầu tạo ra khách hàng mới.

🎁 Chương trình giới thiệu

Bạn có thể thiết kế đơn giản:

Giới thiệu bạn bè
        ↓
Bạn mới mua hàng
        ↓
Người giới thiệu nhận ưu đãi
        ↓
Khách mới nhận ưu đãi

Ví dụ:

"Giới thiệu một người bạn mua hàng, cả hai cùng nhận ưu đãi."

Điểm quan trọng là:

Ưu đãi phải nhỏ hơn giá trị kinh tế mà khách mới mang lại.

Nếu một khách mới tạo ra lợi nhuận 200K, bạn không thể tặng 300K chỉ để lấy một khách.

🗣️ Đừng chỉ nói "giới thiệu bạn bè"

Hãy tạo lý do để khách muốn chia sẻ.

Ví dụ:

"Nếu bạn của anh/chị cũng đang tìm sản phẩm này, gửi họ mã giới thiệu này để cả hai được ưu đãi."

Khách không cảm thấy mình đang "làm việc bán hàng cho bạn".

Họ chỉ đơn giản:

chia sẻ một thứ họ thấy hữu ích.

💎 17. Tăng giá trị mỗi đơn hàng

Đây là một trong những đòn bẩy mạnh nhất của bán hàng.

Có 3 cách cơ bản:

1. ⬆️ Upsell

Bán sản phẩm phiên bản cao hơn.

299K
 ↓
399K
 ↓
599K

2. ➕ Cross-sell

Bán thêm sản phẩm liên quan.

Điện thoại
   +
Ốp
   +
Kính
   +
Sạc

3. 📦 Bundle

Gộp nhiều sản phẩm thành một gói.

Mua riêng:

A = 199K
B = 149K
C = 99K

Tổng = 447K

Tạo combo:

🔥 COMBO A + B + C

399K

Khách cảm thấy:

"Mua combo có lợi hơn."

Người bán:

tăng giá trị đơn hàng.

🧮 Chỉ số cần theo dõi: AOV

AOV — Average Order Value

Tức là:

Giá trị đơn hàng trung bình.

Công thức:

AOV = Tổng doanh thu / Số đơn hàng

Ví dụ:

Doanh thu = 50.000.000đ
Số đơn = 200

AOV = 50.000.000 / 200
    = 250.000đ

Nếu bạn nâng AOV lên:

300.000đ

với cùng 200 đơn:

200 × 300.000
= 60.000.000đ

Bạn tăng:

10 triệu doanh thu

mà không cần tăng số đơn.

🧲 18. Xây danh sách khách hàng riêng

Đây là bước cực kỳ quan trọng.

Nếu khách hàng chỉ tồn tại trên:

Facebook
TikTok
Sàn thương mại điện tử

thì bạn đang phụ thuộc vào nền tảng.

Một ngày thuật toán thay đổi:

Lượt tiếp cận ↓
Doanh thu ↓

Hoặc quảng cáo đắt lên:

CAC ↑
Lợi nhuận ↓

Bạn cần xây một tài sản riêng:

Danh sách khách hàng.

📋 Khách hàng có thể được lưu những gì?

Ở mức cơ bản:

Tên
Số điện thoại / kênh liên hệ
Sản phẩm đã mua
Ngày mua
Giá trị đơn
Lần mua gần nhất

Ghi chú:

Mình tạo sẵn file Excel có đủ 06 cột này + thêm tính năng chống trùng số điện thoại&+ lọc theo cột

->&đăng ký nhận file

Sau này có thể phân nhóm:

KH mới
   ↓
KH đã mua
   ↓
KH mua lại
   ↓
KH trung thành
   ↓
KH giá trị cao

🧠 Đừng xem mọi khách hàng giống nhau

Ví dụ:

100 khách hàng
      ↓
┌─────┼─────┐
↓     ↓     ↓
Mới  Cũ   VIP

🆕 Khách mới

Cần:

làm quen + tạo niềm tin.

🔄 Khách cũ

Cần:

nhắc mua lại + sản phẩm liên quan.

💎 Khách VIP

Cần:

ưu tiên + chăm sóc đặc biệt.

Nếu gửi cùng một thông điệp cho tất cả:

hiệu quả sẽ thấp.

🔥 Tư duy mới: Đừng chỉ tính "một đơn hàng"

Người mới thường nghĩ:

Khách
 ↓
Mua 300K
 ↓
Hết

Người kinh doanh bắt đầu nghĩ:

Khách
 ↓
Mua 300K
 ↓
Mua lại 300K
 ↓
Mua thêm 200K
 ↓
Giới thiệu 2 người
 ↓
Mua tiếp 500K
 ↓
...

Một khách hàng có thể tạo ra:

hàng triệu đồng doanh thu trong suốt vòng đời.

Đó mới là lý do tại sao khách hàng cũ rất có giá trị.

🧮 LTV — Giá trị vòng đời khách hàng

Một cách đơn giản để hình dung:

LTV ≈
Giá trị mỗi đơn
×
Số lần mua
×
Thời gian duy trì

Ví dụ:

Mỗi đơn:        300K
Mua trung bình: 5 lần

Doanh thu vòng đời:
300K × 5
= 1.500K

Nếu chi phí để có khách ban đầu là:

CAC = 100K

thì bức tranh kinh doanh hoàn toàn khác so với việc nhìn riêng đơn hàng đầu tiên.

⚠️ Nhưng doanh thu ≠ lợi nhuận

Đây là điểm cực kỳ quan trọng.

Không được nghĩ:

"Khách này đem lại 1,5 triệu doanh thu → quá lời."

Phải tính:

Doanh thu
− Giá vốn
− Phí vận hành
− Phí nền tảng
− Chi phí giao hàng
− Khuyến mãi
− Chi phí chăm sóc
− Chi phí quảng cáo
=
LỢI NHUẬN

Mục tiêu cuối cùng không phải:

có thật nhiều khách.

Mà là:

có những khách hàng tạo ra lợi nhuận tốt.

🔥 5 cách kiếm nhiều hơn từ một khách

Có thể nhớ bằng công thức:

              KHÁCH HÀNG
                   │
       ┌───────────┼───────────┐
       ↓           ↓           ↓
     MUA LẠI     MUA THÊM    GIỚI THIỆU
       │           │           │
       ↓           ↓           ↓
    Repeat       Cross/       Referral
                 Upsell

Và tất cả được xây trên:

              NIỀM TIN
                 ↓
              SẢN PHẨM TỐT
                 ↓
              TRẢI NGHIỆM TỐT
                 ↓
            KHÁCH QUAY LẠI

Không có sản phẩm tốt và trải nghiệm tốt thì những kỹ thuật này rất khó bền vững.

🏗️ BÀI TẬP THỰC HÀNH

Chọn một sản phẩm thật bạn đang bán hoặc dự định bán.

Viết ra:

🛒 SẢN PHẨM:
Giá: ....................

🔄 KHÁCH CÓ THỂ MUA LẠI:
Sau bao lâu? ............

➕ SẢN PHẨM BÁN THÊM:
1. ......................
2. ......................
3. ......................

⬆️ SẢN PHẨM CAO CẤP HƠN:
..........................

📦 COMBO:
..........................

📣 CHƯƠNG TRÌNH GIỚI THIỆU:
..........................

🧲 CÁCH LƯU KHÁCH HÀNG:
..........................

Sau đó tính:

AOV = Doanh thu / Số đơn

CAC = Chi phí có khách / Số khách mới

LTV = Giá trị khách hàng tạo ra trong vòng đời

Khi bắt đầu theo dõi được CAC + AOV + LTV, bạn sẽ nhìn việc bán hàng rất khác.

🏆 KẾT THÚC PHẦN 3

Ba phần đầu tạo thành một hệ thống:

PHẦN 1
Không quảng cáo
      ↓
Tìm khách tự nhiên
      ↓
Có đơn

PHẦN 2
Dùng tiền
      ↓
Mua khách
      ↓
Có thêm đơn

PHẦN 3
Chăm sóc khách
      ↓
Mua lại
      ↓
Mua thêm
      ↓
Giới thiệu
      ↓
Tăng LTV

Và lúc này chúng ta có một thay đổi rất lớn:

Không còn chỉ đi tìm khách hàng.

Chúng ta bắt đầu xây một tài sản khách hàng.

Nhưng vẫn còn một nguồn khách cực kỳ mạnh mà chúng ta chưa khai thác:

Người đang chủ động lên Google và tìm đúng sản phẩm mình bán.

Nếu có thể xuất hiện đúng lúc họ đang tìm kiếm, bạn có thể nhận được khách mà không nhất thiết phải trả tiền cho từng lượt xem quảng cáo.

Đó là lúc bước sang:

🌐 PHẦN 4 — GOOGLE & WEBSITE

19. 🔎 Đưa sản phẩm lên Google
20. 🏪 Làm trang bán hàng có khả năng chốt đơn
21. 📍 Kéo khách quanh khu vực cửa hàng
22. 🛍️ Bán hàng từ Google Search

quay về MỤC LỤC

Ở Phần 1, chúng ta học cách kiếm đơn mà không cần bỏ tiền mua quảng cáo.

Đó là giai đoạn rất quan trọng.

Bạn đăng video → có người xem → có người nhắn tin → tư vấn → chốt đơn.

Nhưng có một vấn đề:

Khách hàng tự nhiên không phải lúc nào cũng đến đủ nhanh.

Một video có thể đạt 100.000 lượt xem, nhưng video tiếp theo chỉ có 500 lượt. Một ngày có 20 người hỏi, hôm sau chẳng có ai.

Khi đã có một sản phẩm bán được, chúng ta có thể chuyển sang bước tiếp theo:

Dùng tiền để đưa sản phẩm đến trước mắt nhiều khách hàng hơn.

Đó chính là quảng cáo.

🎯 8. Chọn sản phẩm để chạy quảng cáo

Sai lầm phổ biến nhất của người mới là:

"Có sản phẩm → chạy quảng cáo."

Không nên làm như vậy.

Quảng cáo không biến một sản phẩm tệ thành sản phẩm tốt.

Nó chỉ giúp sản phẩm được nhiều người nhìn thấy hơn.

Nếu sản phẩm chưa có người mua, hình ảnh chưa tốt, giá chưa hợp lý, nội dung chưa thuyết phục... thì chạy quảng cáo có thể khiến bạn mất tiền nhanh hơn.

🧠 Công thức đơn giản

Trước khi quảng cáo, hãy hỏi:

SẢN PHẨM
   ↓
Có người cần?
   ↓
Có người mua?
   ↓
Có lợi nhuận?
   ↓
Có thể làm nội dung?
   ↓
  CÓ
   ↓
CHẠY QUẢNG CÁO

🔥 Ưu tiên sản phẩm đã có tín hiệu

Ví dụ bạn bán:

Bình giữ nhiệt 299.000đ

Bạn đăng video tự nhiên và nhận được:

10.000 lượt xem
       ↓
80 tin nhắn
       ↓
20 đơn hàng

Đây là một tín hiệu rất đáng chú ý.

Bạn đã biết rằng:

• Có người quan tâm.

• Có người hỏi.

• Có người chịu mua.

• Nội dung có khả năng tạo hành động.

Lúc này quảng cáo có ý nghĩa hơn nhiều.

💵 9. Chạy quảng cáo với ngân sách nhỏ

Người mới thường mắc một lỗi:

"Muốn bán nhiều thì phải quảng cáo thật nhiều."

Không.

Ở giai đoạn đầu, mục tiêu không phải là kiếm thật nhiều tiền.

Mục tiêu là:

Mua dữ liệu với chi phí thấp.

Ví dụ:

Ngân sách:
100.000đ/ngày

        ↓

Quảng cáo

        ↓

Có bao nhiêu người xem?
Có bao nhiêu người click?
Có bao nhiêu người nhắn?
Có bao nhiêu người mua?

        ↓

ĐÁNH GIÁ

100.000đ bỏ ra để thử nghiệm có thể giúp bạn biết quảng cáo có tiềm năng hay không.

Nếu tốt → tăng dần.

Nếu xấu → dừng.

⚠️ Đừng nghĩ 100.000đ phải tạo ra ngay 1.000.000đ

Quảng cáo giống như 01 phòng thí nghiệm.

Bạn đưa vào:

💵 tiền

và nhận lại:

📊 dữ liệu.

Sau nhiều lần thử, bạn mới tìm ra công thức có lợi nhuận.

🧪 10. Test quảng cáo

Đây là kỹ năng quan trọng nhất trong phần quảng cáo.

Đừng tạo một quảng cáo duy nhất rồi ngồi chờ.

Hãy tạo nhiều phiên bản.

Ví dụ cùng một sản phẩm:

🎬 Video A — Đánh vào vấn đề

"Đi làm cả ngày mà nước trong bình cứ nóng lên?"

🎬 Video B — Đánh vào lợi ích

"Bình giữ nhiệt này giữ nước lạnh nhiều giờ..."

🎬 Video C — Đánh vào tình huống

"3 giờ chiều ở văn phòng, mở bình ra vẫn còn lạnh."

🎬 Video D — Đánh vào giá

"Một chiếc bình giữ nhiệt chưa tới 300K..."

Cùng một sản phẩm nhưng:

        SẢN PHẨM
            │
    ┌───────┼────────┐
    ↓       ↓        ↓
 Video A  Video B  Video C
    ↓       ↓        ↓
    └───────┼────────┘
            ↓
       SO SÁNH KẾT QUẢ

Bạn không cần đoán.

Hãy để dữ liệu trả lời.

📊 Test cái gì?

Có thể test từng yếu tố:

1. 🎬 Video

Hai video khác nhau.

2. 🖼️ Hình ảnh

Hai ảnh quảng cáo khác nhau.

3. ✍️ Nội dung

Hai cách viết khác nhau.

4. 🎯 Đối tượng

Hai nhóm khách hàng khác nhau.

5. 💰 Ưu đãi

Ví dụ:

299.000đ

vs

299.000đ
+ miễn phí vận chuyển

Hoặc:

Mua 1: 299K

Mua 2: 499K

Mỗi lần test nên có một giả thuyết rõ ràng.

📊 11. Biết quảng cáo nào đang có lời

Đây là lúc bạn phải ngừng nhìn vào:

❤️ lượt thích

👁️ lượt xem

💬 bình luận

và bắt đầu nhìn vào:

💰 TIỀN

Ví dụ:

Nhìn qua có thể thấy quảng cáo D rất hấp dẫn.

Nhưng doanh thu chưa phải lợi nhuận.

🧮 Phải tính lợi nhuận

Giả sử một sản phẩm bán:

Giá bán             300.000đ
Giá vốn              150.000đ
Phí vận chuyển        20.000đ
Phí nền tảng          15.000đ
Chi phí khác          15.000đ
--------------------------------
Còn lại trước QC     100.000đ

Nếu bạn bỏ:

100.000đ quảng cáo

để có một đơn hàng:

Lợi nhuận ≈ 0đ

Như vậy quảng cáo không thực sự có lời.

🎯 Chỉ số cực kỳ quan trọng

CAC — Customer Acquisition Cost

Tức là:

Chi phí để có được một khách hàng.

Ví dụ:

Chi quảng cáo: 1.000.000đ

Có:
20 khách mua

CAC = 1.000.000 / 20
    = 50.000đ/khách

Nếu mỗi khách mang lại lợi nhuận 120.000đ trước chi phí quảng cáo:

120K - 50K
= 70K

→ Có khả năng mở rộng.

🛑 12. Cắt quảng cáo đang đốt tiền

Đây là kỹ năng mà người mới thường không muốn làm.

Họ nghĩ:

"Chắc thêm vài ngày nữa sẽ tốt."

Rồi:

100K
 ↓
100K
 ↓
100K
 ↓
100K
 ↓
100K

Tiền cứ thế biến mất.

🔥 Quảng cáo không có nhiệm vụ làm bạn vui

Nó phải tạo ra kết quả kinh doanh.

Nếu một quảng cáo:

Chi tiền
  ↓
Có người xem
  ↓
Có click
  ↓
Có người hỏi
  ↓
Không ai mua

thì phải tìm nguyên nhân.

Có thể vấn đề nằm ở:

• Video.

• Sản phẩm.

• Giá.

• Trang bán hàng.

• Cách tư vấn.

• Ưu đãi.

• Đối tượng khách hàng.

Không phải lúc nào quảng cáo cũng là thủ phạm.

🚦 Một hệ thống quyết định đơn giản

              QUẢNG CÁO
                   ↓
              Có dữ liệu?
              /        \
            CÓ          CHƯA
            ↓             ↓
         Đánh giá       Chờ thêm
            ↓
       Có khả năng lời?
         /        \
       CÓ          KHÔNG
       ↓             ↓
    GIỮ / TEST     DỪNG

Điều quan trọng là:

Đừng yêu một quảng cáo.

Nếu nó không hiệu quả, hãy bỏ nó.

📈 13. Tăng tiền cho quảng cáo có lời

Khi tìm được quảng cáo tốt, bạn bắt đầu bước tiếp theo:

Scale — mở rộng.

Ví dụ:

100K/ngày
    ↓
Quảng cáo có lời
    ↓
200K/ngày
    ↓
300K/ngày
    ↓
500K/ngày

Nhưng không nên tăng ngân sách một cách mù quáng.

Bởi vì:

Một quảng cáo có lời ở 100K/ngày chưa chắc có lời ở 10 triệu/ngày.

Khi ngân sách tăng, quảng cáo có thể tiếp cận những nhóm khách hàng kém phù hợp hơn.

🧠 Tư duy quan trọng: Đừng "đốt tiền để bán hàng"

Hãy nghĩ theo mô hình:

             TIỀN
              ↓
         QUẢNG CÁO
              ↓
           KHÁCH
              ↓
           ĐƠN HÀNG
              ↓
          LỢI NHUẬN
              ↓
        TÁI ĐẦU TƯ
              ↓
         QUẢNG CÁO
              ↓
           KHÁCH
              ↓
             ...

Đây mới là vòng lặp kinh doanh.

Nếu vòng lặp này hoạt động:

1đ quảng cáo
     ↓
tạo ra
     ↓
> 1đ lợi nhuận có thể tái đầu tư

thì bạn bắt đầu có một cỗ máy tăng trưởng.

🏁 BÀI TẬP THỰC HÀNH

Hãy chọn một sản phẩm thật.

Không cần sản phẩm hoàn hảo.

Ghi ra:

Tên sản phẩm:
Giá bán:
Giá vốn:
Lợi nhuận trước quảng cáo:

Quảng cáo A:
Quảng cáo B:
Quảng cáo C:

Sau đó chuẩn bị 3 nội dung quảng cáo khác nhau.

Bắt đầu với ngân sách nhỏ.

Ghi lại:

💵 Chi phí quảng cáo
👁️ Lượt tiếp cận
👆 Lượt click
💬 Tin nhắn
🛒 Đơn hàng
💰 Doanh thu
📈 Lợi nhuận

Sau một thời gian, bạn sẽ không còn nói:

"Tôi cảm giác quảng cáo này tốt."

Mà có thể nói:

"Quảng cáo B tạo ra khách hàng với chi phí 47.000đ, trong khi quảng cáo A là 93.000đ."

Đó chính là lúc bạn bắt đầu làm marketing bằng dữ liệu thay vì cảm tính.

🔥 KẾT THÚC PHẦN 2

Phần 1 dạy chúng ta:

Kiếm khách mà không cần trả tiền.

Phần 2 dạy:

Dùng tiền để mua thêm khách.

Nhưng một doanh nghiệp thật sự không thể chỉ kiếm một đơn hàng từ một khách hàng.

Nếu mỗi lần bán hàng bạn đều phải bỏ tiền tìm một khách mới, chi phí sẽ ngày càng cao.

Bước tiếp theo là câu hỏi quan trọng hơn:

Làm thế nào để một khách hàng mua nhiều lần và tạo ra nhiều tiền hơn theo thời gian?

Đó chính là PHẦN 3 — KIẾM NHIỀU HƠN TỪ MỘT KHÁCH.

quay về MỤC LỤC

Trong các bài trước, chúng ta đã đi qua:

• Observer

• Event & Listener

• Queue

Đến Bài 36, chúng ta bắt đầu một chức năng rất quan trọng trong các ứng dụng web thực tế:

📧 Gửi Email bằng Laravel

Email có thể được sử dụng cho:

• ✉️ Xác nhận đăng ký tài khoản

• 🔐 Đặt lại mật khẩu

• 📩 Thông báo khi có bài viết mới

• 🛒 Xác nhận đơn hàng

• 💳 Thông báo thanh toán

• 👤 Thông báo tài khoản

• 📢 Gửi thông báo hệ thống

• 📎 Gửi email kèm file

• ⚙️ Kết hợp Email + Queue để gửi email ở background

Laravel cung cấp một API gửi mail thống nhất dựa trên Symfony Mailer, hỗ trợ nhiều mail transport như SMTP, Mailgun, Postmark, Amazon SES và sendmail. (Laravel)

📚 NỘI DUNG BÀI 36

Trong bài này chúng ta sẽ xây dựng hệ thống email theo mô hình:

Laravel
   │
   ├── Mailable
   │
   ├── Blade Email
   │
   ├── Mail Configuration
   │
   ├── SMTP
   │
   ├── Send Email
   │
   ├── Attachment
   │
   ├── Markdown Email
   │
   ├── Preview Email
   │
   └── Queue Email

1. 📧 Mail trong Laravel là gì?

Trong Laravel, mỗi loại email thường được biểu diễn bởi một class gọi là Mailable.

Ví dụ:

app/
└── Mail/
    ├── WelcomeUser.php
    ├── OrderShipped.php
    └── ResetPassword.php

Mỗi Mailable chịu trách nhiệm mô tả một loại email.

Ví dụ:

WelcomeUser
      ↓
Email chào mừng

OrderShipped
      ↓
Email thông báo giao hàng

InvoicePaid
      ↓
Email thông báo thanh toán

Laravel tạo Mailable bằng Artisan:

php artisan make:mail WelcomeUser

Sau khi chạy lệnh, Laravel tạo class trong:

app/Mail/WelcomeUser.php

Đây là cách chính thức Laravel sử dụng để tạo Mailable. (Laravel)

2. ⚙️ Cấu hình Mail

Thông tin mail của ứng dụng thường được cấu hình thông qua:

.env

và:

config/mail.php

Ví dụ .env:

MAIL_MAILER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME="your@gmail.com"
MAIL_PASSWORD="your_app_password"
MAIL_ENCRYPTION=tls

MAIL_FROM_ADDRESS="your@gmail.com"
MAIL_FROM_NAME="${APP_NAME}"

Không nên viết trực tiếp username/password vào source code (file mail.php).

Chú ý:

password mail là App Password

(vào Gmail mục Xác minh 02 bước-Mật khẩu ứng dụng-Gõ tên 'Laravel'-xóa hết khoảng trắng)

php artisan config:clear
php artisan tinker --execute="Mail::raw('test', function($m){ $m->to('nguyenminhk2000@gmail.com')->subject('Test'); }); echo 'sent';"

Thay vào đó:

.env
   ↓
config/mail.php
   ↓
Laravel Mail
   ↓
SMTP Server

3. 📨 Tạo Mailable

Tạo email:

php artisan make:mail WelcomeUser

Laravel sẽ tạo:

app/Mail/WelcomeUser.php

Một Mailable hiện đại có thể sử dụng:

envelope()
content()
attachments()

Ví dụ:

<?php

namespace App\Mail;

use Illuminate\Mail\Mailable;
use Illuminate\Mail\Mailables\Content;
use Illuminate\Mail\Mailables\Envelope;

class WelcomeUser extends Mailable
{
    public function envelope(): Envelope
    {
        return new Envelope(
            subject: 'Chào mừng bạn đến với website',
        );
    }

    public function content(): Content
    {
        return new Content(
            view: 'emails.welcome',
        );
    }
}

Trong đó:

envelope()

dùng để cấu hình thông tin email.

content()

dùng để xác định nội dung email.

Laravel hiện sử dụng Envelope và Content trong cấu trúc Mailable hiện đại. (Laravel)

4. 🎨 Tạo giao diện Email bằng Blade

Tạo file:

resources/views/emails/welcome.blade.php

Ví dụ:

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">

    <title>Chào mừng</title>
</head>

<body>

    <h1>Chào mừng bạn!</h1>

    <p>
        Cảm ơn bạn đã đăng ký tài khoản.
    </p>

</body>
</html>

Laravel sử dụng Blade để render HTML email giống như các View thông thường. (Laravel)

5. 👤 Truyền dữ liệu vào Email

Giả sử chúng ta muốn gửi tên người dùng.

Mailable:

<?php

namespace App\Mail;

use Illuminate\Mail\Mailable;
use Illuminate\Mail\Mailables\Content;
use Illuminate\Mail\Mailables\Envelope;

class WelcomeUser extends Mailable
{
    public function __construct(
        public string $name
    ) {}

    public function envelope(): Envelope
    {
        return new Envelope(
            subject: 'Chào mừng bạn!',
        );
    }

    public function content(): Content
    {
        return new Content(
            view: 'emails.welcome',
        );
    }
}

Blade:

<h1>
    Xin chào {{ $name }}
</h1>

<p>
    Chào mừng bạn đến với website.
</p>

Khi Laravel render View:

$name
   ↓
Blade
   ↓
HTML Email

6. 🚀 Gửi Email

Laravel cung cấp Mail facade.

use Illuminate\Support\Facades\Mail;
use App\Mail\WelcomeUser;

Sau đó:

Mail::to($user->email)
    ->send(new WelcomeUser($user->name));

Ví dụ trong RegisteredUserController

namespace App\Http\Controllers\Auth;

use App\Http\Controllers\Controller;
use App\Mail\WelcomeUser; // Import Mailable
use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\Mail; // Import Mail Facade

class RegisteredUserController extends Controller
{
    public function store(Request $request)
    {
        // 1. Validate dữ liệu
        $request->validate([
            'name' => ['required', 'string', 'max:255'],
            'email' => ['required', 'string', 'email', 'max:255', 'unique:users'],
            'password' => ['required', 'confirmed'],
        ]);

        // 2. Tạo User mới
        $user = User::create([
            'name' => $request->name,
            'email' => $request->email,
            'password' => Hash::make($request->password),
        ]);

        // 3. GỬI MAIL WELCOME
        Mail::to($user->email)->send(new WelcomeUser($user));

        // 4. Cho đăng nhập hoặc chuyển hướng
        auth()->login($user);

        return redirect('/dashboard')->with('status', 'Đăng ký thành công!');
    }
}

Luồng hoạt động:

Controller
    ↓
Mail::to()
    ↓
WelcomeUser
    ↓
Blade
    ↓
SMTP
    ↓
Email người nhận

7. 📮 Gửi cho nhiều người

Có thể gửi email tới nhiều địa chỉ.

Ví dụ:

Mail::to([
    'user1@example.com',
    'user2@example.com',
])
->send(new WelcomeUser('Các bạn'));

Ngoài to(), hệ thống email còn có thể sử dụng các địa chỉ như:

->cc()

và:

->bcc()

Ví dụ:

Mail::to($user->email)
    ->cc('admin@example.com')
    ->send(
        new WelcomeUser($user->name)
    );

8. 📎 Gửi Email kèm File

Một email thực tế đôi khi cần gửi:

• PDF

• Hóa đơn

• Báo giá

• Báo cáo

• Hình ảnh

• File Excel

Trong Mailable có thể định nghĩa:

public function attachments(): array
{
    return [
        Attachment::fromPath(
            storage_path('app/invoices/invoice.pdf')
        ),
    ];
}

Import:

use Illuminate\Mail\Mailables\Attachment;

Laravel hỗ trợ cấu hình attachment trực tiếp trong Mailable. (Laravel)

9. 📝 Markdown Email

Laravel còn hỗ trợ Markdown Mailables.

Thay vì tự viết toàn bộ HTML:

<table>
<tr>
<td>
...

chúng ta có thể sử dụng Markdown.

Tạo Mailable:

php artisan make:mail OrderShipped --markdown=emails.orders.shipped

Laravel sẽ tạo template tương ứng.

Ví dụ:

resources/views/emails/orders/shipped.blade.php

Nội dung:

<x-mail::message>

# Đơn hàng đã được giao

Xin chào {{ $user->name }},

Đơn hàng của bạn đã được giao thành công.

<x-mail::button :url="$url">
Xem đơn hàng
</x-mail::button>

Cảm ơn,<br>
{{ config('app.name') }}

</x-mail::message>

Markdown Mailables rất phù hợp với:

Thông báo
Xác nhận đơn hàng
Reset Password
Thông báo hệ thống

10. 👀 Preview Email

Một tính năng rất hữu ích khi thiết kế email là preview trực tiếp trên trình duyệt.

Có thể tạo Route:

use App\Mail\WelcomeUser;
use Illuminate\Support\Facades\Route;

Route::get('/preview-mail', function () {

    return new WelcomeUser(
        'Nguyễn Văn A'
    );

});

Sau đó truy cập:

/preview-mail

Laravel sẽ render Mailable thành HTML để xem trước mà không cần gửi email thật. (Laravel)

Đây là cách rất tiện để thiết kế email.

Blade Email
     ↓
Mailable
     ↓
Browser Preview

11. 🧪 Test Email

Khi test ứng dụng, chúng ta không muốn gửi email thật.

Laravel cung cấp:

Mail::fake();

Ví dụ:

use Illuminate\Support\Facades\Mail;

Mail::fake();

Sau đó thực hiện hành động gửi email.

Có thể kiểm tra:

Mail::assertSent(
    WelcomeUser::class
);

Hoặc kiểm tra email không được gửi:

Mail::assertNotSent(
    WelcomeUser::class
);

Laravel cũng hỗ trợ kiểm tra số lượng Mailable đã gửi. (Laravel)

12. ⚡ Kết hợp Mail với Queue

Đây là phần rất quan trọng.

Giả sử người dùng đăng ký:

Register
   ↓
Tạo User
   ↓
Gửi Email
   ↓
SMTP
   ↓
Chờ...
   ↓
Response

Nếu SMTP phản hồi chậm, người dùng có thể phải chờ.

Thay vào đó:

Register
   ↓
Tạo User
   ↓
Đưa Email vào Queue
   ↓
Response ngay
   ↓
Queue Worker
   ↓
Gửi Email

Mục tiêu là:

Không bắt HTTP request phải chờ việc gửi email hoàn thành.

Mailable có thể được queue để Laravel xử lý việc gửi email ở background.

Ví dụ:

Mail::to($user->email)
    ->queue(
        new WelcomeUser($user->name)
    );

Đây chính là lúc kiến thức Bài 35 — Queue được kết nối với Bài 36 — Mail.

13. 🔄 Mail + Queue trong dự án Blog CMS

Trong dự án Blog CMS của chúng ta, có thể xây dựng:

User đăng ký
     │
     ▼
Register
     │
     ▼
Create User
     │
     ▼
WelcomeUser Mail
     │
     ▼
Queue
     │
     ▼
Queue Worker
     │
     ▼
SMTP
     │
     ▼
Email

Hoặc:

Admin xuất bản bài viết
        │
        ▼
PostPublished Event
        │
        ▼
Listener
        │
        ▼
SendNewPostMail
        │
        ▼
Queue
        │
        ▼
Subscribers

Đây là cách các thành phần Laravel bắt đầu kết nối với nhau thành một hệ thống thực tế.

14. 🏠 Mail khi Development

Khi lập trình local, chúng ta không nên liên tục gửi email thật.

Một giải pháp rất tiện là sử dụng Mailpit để bắt email và xem chúng trên trình duyệt. Tài liệu Laravel/Sail hiện mô tả Mailpit cho môi trường development; giao diện mặc định có thể truy cập qua cổng 8025. (Laravel)

Mô hình:

Laravel
   │
   ▼
Mailpit
   │
   ▼
Browser

Thay vì:

Laravel
   │
   ▼
Email thật
   │
   ▼
Khách hàng

Development nên dùng:

Local
  ↓
Mailpit
  ↓
Preview

Production mới cấu hình:

Production
    ↓
SMTP / Mail Provider
    ↓
User

15. 🧩 Mail trong kiến trúc Laravel

Sau bài này, chúng ta có thể hình dung Laravel Mail như sau:

                    ┌───────────────┐
                    │   Controller  │
                    └───────┬───────┘
                            │
                            ▼
                    ┌───────────────┐
                    │     Mail      │
                    └───────┬───────┘
                            │
                            ▼
                    ┌───────────────┐
                    │    Mailable   │
                    └───────┬───────┘
                            │
                   ┌────────┴────────┐
                   ▼                 ▼
               Blade View        Attachment
                   │
                   ▼
                HTML Mail
                   │
                   ▼
             SMTP / Mailer
                   │
                   ▼
                Người nhận

Nếu kết hợp Queue:

Mailable
   │
   ▼
Queue
   │
   ▼
Worker
   │
   ▼
Mailer
   │
   ▼
Email

16. 🎯 Bài tập thực hành

Tạo hệ thống gửi email chào mừng người dùng.

Bước 1

Tạo Mailable:

php artisan make:mail WelcomeUser

Bước 2

Tạo View:

resources/views/emails/welcome.blade.php

Bước 3

Truyền:

$user

vào Mailable.

Bước 4

Thiết kế email:

Xin chào Nguyễn Văn A!

Chào mừng bạn đến với Blog CMS.

[Truy cập website]

Bước 5

Tạo route preview:

/preview-mail

Bước 6

Test email bằng:

Mail::fake();

Bước 7

Cuối cùng chuyển sang Queue:

Mail::to($user->email)
    ->queue(
        new WelcomeUser($user)
    );

17. 🧠 Những kiến thức cần nhớ

18. 🔥 Tổng kết Bài 36

Sau bài này, chúng ta đã biết cách:

                    📧 MAIL
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
    Mailable          Blade        SMTP
        │              │              │
        ▼              ▼              ▼
    Envelope        Template       Delivery
        │
        ▼
    Attachment
        │
        ▼
      Queue
        │
        ▼
   Background Mail

Điểm quan trọng nhất cần nhớ:

Mailable là lớp đại diện cho email.

Blade là nơi xây dựng nội dung email.

Mail facade là nơi gửi email.

Queue giúp việc gửi email không làm chậm request của người dùng.

Và từ đây, chúng ta đã bắt đầu kết nối các kiến thức:

Event
   ↓
Listener
   ↓
Queue
   ↓
Mail
   ↓
User

Đây chính là kiểu kiến trúc thường gặp trong một ứng dụng Laravel thực tế.

📌 Liên hệ với các bài tiếp theo

Sau Bài 36 — Mail, bài tiếp theo sẽ là:

📘 Bài 37 — Notification

Trong bài đó chúng ta sẽ phân biệt:

Mail
Notification
Event
Listener
Queue

và tìm hiểu tại sao Notification có thể gửi thông báo qua nhiều kênh khác nhau thay vì chỉ gửi email.

Tài liệu Laravel 13 cũng tiếp tục hỗ trợ việc kết hợp Notification với Mailable khi cần các email phức tạp hơn. (Laravel)

Lưu ý: Danh sách ban đầu của bạn ghi Laravel 12 LTS, nhưng nếu mục tiêu là khóa học Laravel 2026, mình khuyên đổi toàn bộ tiêu đề thành Laravel 13. Laravel 13 hiện là phiên bản chính thức mới, còn Laravel 12 đã hết thời hạn bug fixes vào 13/08/2026 nhưng vẫn nhận security fixes đến 24/02/2027. (Laravel)

x1
quay về MỤC LỤC

1. 🔎 Tìm sản phẩm có người mua

Đừng bắt đầu bằng câu:

“Tôi thích bán gì?”

Hãy bắt đầu bằng:

“Người ta đang bỏ tiền mua gì?”

Có thể tìm ngay từ:

• TikTok Shop

• Shopee

• Facebook

• Google

• Các group mua bán

• Cửa hàng đối thủ

Quan sát 3 thứ:

① Có người mua thật không?
② Giá bán khoảng bao nhiêu?
③ Người bán đang dùng cách gì để bán?

Bài tập

Chọn 3 sản phẩm.

Ghi:

Sản phẩm:
Giá bán:
Có nhiều người bán không?
Có nhiều người hỏi/mua không?
Tôi có thể bán khác họ ở điểm nào?

Không tìm được sản phẩm → chưa chạy quảng cáo.

2. 👥 Tìm nơi có khách

Có sản phẩm rồi, việc tiếp theo không phải là đăng bài ngay.

Phải tìm:

Khách đang tụ tập ở đâu?

Ví dụ bán đồ câu cá:

Facebook Group
        ↓
TikTok
        ↓
YouTube
        ↓
Google
        ↓
Forum / cộng đồng câu cá

Bán đồ ăn:

Facebook địa phương
        ↓
TikTok địa phương
        ↓
Google Maps
        ↓
Group khu dân cư

Bán đồ cho mẹ và bé:

TikTok
Facebook Group
YouTube
Cộng đồng phụ huynh

Quy tắc

Đừng cố kéo khách về chỗ mình trước.

Hãy:

Đi tìm nơi khách đã có sẵn.

3. 📱 Biến Facebook/TikTok thành nơi kéo khách

Sai lầm phổ biến:

“Hôm nay shop có áo mới, giá 199K, inbox shop nhé.”

Ngày nào cũng đăng như vậy.

Khách sẽ lướt qua.

Thay vào đó, hãy đăng thứ khách đang quan tâm.

Ví dụ bán áo:

❌ Áo mới về 199K.

✅ Nam 65kg, cao 1m70 nên mặc size gì?

✅ 3 lỗi khiến áo thun mặc lên bị xấu.

✅ Cùng một chiếc áo nhưng 3 cách phối đồ.

✅ Áo 150K và áo 500K khác nhau ở đâu?

Sau đó mới đưa sản phẩm vào.

Mục tiêu của nội dung không nhất thiết là:

“Mua ngay!”

Mà là:

“Người này đang nói đúng thứ mình cần.”

4. 🎬 Làm video bán hàng bằng điện thoại

Không cần máy quay.

Không cần studio.

Không cần biết dựng phim chuyên nghiệp.

Một video bán hàng cơ bản:

0–3 giây
↓
Nói vấn đề

3–15 giây
↓
Cho thấy sản phẩm giải quyết vấn đề

15–30 giây
↓
Demo / kết quả

Cuối video
↓
Cách mua

Ví dụ bán máy hút bụi:

“Nhà có trẻ nhỏ mà sàn cứ đầy tóc? Đây là lý do tôi dùng loại máy này…”

Sau đó quay thật:

• Máy hoạt động.

• Hút tóc.

• Hút bụi.

• Đổ hộp bụi.

Cuối cùng:

“Link sản phẩm ở phần mô tả.”

Không cần nói hay. Sản phẩm thật + vấn đề thật + cách giải quyết thật.

5. ✍️ Viết nội dung khiến khách hỏi mua

Một bài bán hàng đơn giản có thể dùng công thức:

VẤN ĐỀ
↓
GIẢI PHÁP
↓
SẢN PHẨM
↓
BẰNG CHỨNG
↓
GIÁ
↓
CÁCH MUA

Ví dụ:

Áo trắng mặc vài lần là xuống màu?

Shop vừa về mẫu áo cotton mới, chất vải dày hơn và ít nhăn.

Đây là ảnh chụp thực tế sau khi giặt.

Giá: 199.000đ.

Có size M–XL.

Muốn xem bảng size → comment SIZE.

Điểm quan trọng:

Đừng cố bán cho tất cả mọi người.

Hãy viết cho một người đang có nhu cầu.

6. 💬 Biến lượt xem thành tin nhắn

Có người xem video nhưng không mua.

Có người xem bài nhưng không hỏi.

Có người vào trang rồi đi.

Ta cần cho họ một lý do để hành động.

Ví dụ:

Xem video
   ↓
“Muốn biết size?”
   ↓
Comment SIZE
   ↓
Shop trả lời
   ↓
Inbox
   ↓
Tư vấn
   ↓
Đơn hàng

Hoặc:

Video
 ↓
“Link sản phẩm ở bio”
 ↓
Trang sản phẩm
 ↓
Đặt hàng

Đừng chỉ nói:

“Hãy ủng hộ shop.”

Hãy nói rõ:

“Muốn mua thì làm gì?”

7. 🛒 Biến tin nhắn thành đơn hàng

Đây là chỗ nhiều shop mất tiền nhất.

Có khách hỏi:

“Bao nhiêu vậy shop?”

Shop trả lời:

“199k.”

Hết.

Khách biến mất.

Thay vì vậy:

“Dạ mẫu này 199k ạ. Anh/chị đang tìm size nào để em tư vấn đúng size cho mình? Anh/chị cao và nặng khoảng bao nhiêu ạ?”

Khách trả lời.

Cuộc trò chuyện bắt đầu.

Khách hỏi
   ↓
Tư vấn
   ↓
Giải quyết lo lắng
   ↓
Đề xuất sản phẩm
   ↓
Chốt đơn

Marketing đưa khách tới cửa.

Bán hàng mới là bước lấy tiền.

🎯 KẾT QUẢ CỦA PHẦN 1

Học xong phần này, người học không cần thuộc một đống thuật ngữ.

Phải có được:

01 sản phẩm
     ↓
01 nhóm khách
     ↓
01 nơi tìm thấy khách
     ↓
10 nội dung
     ↓
5 video
     ↓
các cuộc trò chuyện
     ↓
🛒 ĐƠN HÀNG ĐẦU TIÊN

Và đây mới là điểm bắt đầu của khóa.

Nếu đăng 20 bài mà không có ai hỏi → tìm nguyên nhân.

Nếu có người hỏi nhưng không mua → sửa cách chốt.

Nếu có đơn nhưng không có lời → sửa sản phẩm/giá/chi phí.

Nếu có lời → lúc đó mới đáng để học phần 2: dùng tiền để mua thêm khách.

Không có đơn → chưa cần học cách scale.
Có đơn nhưng lỗ → chưa được scale.
Có đơn và có lời → bắt đầu nghĩ đến quảng cáo.

quay về MỤC LỤC

🛒 PHẦN 1 — KIẾM ĐƠN KHÔNG CẦN QUẢNG CÁO

1. 🔎 Tìm sản phẩm có người mua

2. 👥 Tìm nơi có khách

3. 📱 Biến Facebook/TikTok thành nơi kéo khách

4. 🎬 Làm video bán hàng bằng điện thoại

5. ✍️ Viết nội dung khiến khách hỏi mua

6. 💬 Biến lượt xem thành tin nhắn

7. 🛒 Biến tin nhắn thành đơn hàng

💰 PHẦN 2 — DÙNG TIỀN ĐỂ MUA KHÁCH

8. 🎯 Chọn sản phẩm để chạy quảng cáo

9. 💵 Chạy quảng cáo với ngân sách nhỏ

10. 🧪 Test quảng cáo

11. 📊 Biết quảng cáo nào đang có lời

12. 🛑 Cắt quảng cáo đang đốt tiền

13. 📈 Tăng tiền cho quảng cáo có lời

🔥 PHẦN 3 — KIẾM NHIỀU HƠN TỪ MỘT KHÁCH

14. 🔄 Bán lại cho khách cũ

15. 🎁 Tạo chương trình khiến khách mua thêm

16. 📣 Biến khách hàng thành người giới thiệu

17. 💎 Tăng giá trị mỗi đơn hàng

18. 🧲 Xây danh sách khách hàng riêng

🌐 PHẦN 4 — GOOGLE & WEBSITE

19. 🔎 Đưa sản phẩm lên Google

20. 🏪 Làm trang bán hàng có khả năng chốt đơn

21. 📍 Kéo khách quanh khu vực cửa hàng

22. 🛍️ Bán hàng từ Google Search

🤖 PHẦN 5 — AI GIÚP BÁN HÀNG

23. 🤖 Dùng AI tìm ý tưởng sản phẩm

24. ✍️ Dùng AI sản xuất nội dung

25. 🎬 Dùng AI làm video

26. 📊 Dùng AI phân tích quảng cáo

27. ⚙️ Tự động hóa những việc lặp lại

🏆 PHẦN 6 — LÀM RA TIỀN THẬT

28. 🧪 Chọn một sản phẩm thật

29. 📱 Dựng kênh bán hàng thật

30. 💰 Chạy chiến dịch thật

31. 📊 Đo tiền vào — tiền ra

32. 🚀 Tối ưu để có lợi nhuận

33. 🏆 Xây hệ thống bán hàng có thể chạy mỗi ngày

📚 Mục lục

1. ⚡ Vite là gì?

2. 🧩 Tại sao Laravel sử dụng Vite?

3. 📦 Vite đứng ở đâu trong một dự án Laravel?

4. 🗂️ Cấu trúc thư mục khi sử dụng Vite

5. 📄 File vite.config.js

6. 📦 File package.json

7. 🎨 Quản lý CSS với Vite

8. ⚙️ Quản lý JavaScript với Vite

9. 🔗 @vite() trong Blade

10. 🏗️ Development và Production Build

11. 🔥 Vite Dev Server và Hot Module Replacement

12. 📦 Vite xử lý Module JavaScript như thế nào?

13. 🖼️ Vite xử lý hình ảnh, Font và Asset

14. 🔐 Biến môi trường .env trong Vite

15. 🛠️ Cấu hình Vite cho Laravel

16. 🧱 Sử dụng Vite với PHP thuần

17. 🚀 Sử dụng Vite với CodeIgniter 3.x

18. 🔌 Kết nối Vite với View của CodeIgniter

19. 📁 Xây dựng cấu trúc Frontend riêng cho CI3

20. 🏭 Build Vite để Deploy lên Hosting

21. ⚠️ Những lỗi thường gặp khi dùng Vite

22. 🧠 Laravel Mix khác Vite như thế nào?

23. 🎯 Khi nào nên dùng Vite?

24. 🏆 Kiến trúc Frontend hiện đại cho dự án PHP

1. ⚡ Vite là gì?

Vite là một công cụ dành cho frontend, có nhiệm vụ chính là:

Source Code
    ↓
Vite
    ↓
Development Server
    ↓
Browser

và khi đưa website lên production:

CSS / JS / Images
        ↓
      Vite
        ↓
     Build
        ↓
dist / build assets

Vite không phải PHP framework.

Nó cũng không thay thế Laravel, CodeIgniter hay PHP.

Có thể hiểu đơn giản:

Laravel / CodeIgniter / PHP
        │
        │ Backend
        ▼
     PHP Server
        │
        │ HTML
        ▼
     Browser
        ▲
        │ CSS / JavaScript
        │
       Vite

Vite phụ trách phần frontend asset.

2. 🧩 Tại sao Laravel sử dụng Vite?

Một dự án Laravel hiện đại thường có rất nhiều frontend asset:

resources/
├── css/
│   └── app.css
│
└── js/
    └── app.js

Nếu chỉ có một file CSS và một file JS nhỏ thì không vấn đề.

Nhưng dự án lớn có thể có:

JavaScript
├── app.js
├── admin.js
├── dashboard.js
├── modal.js
├── editor.js
└── components/
    ├── table.js
    ├── chart.js
    └── notification.js

Vite giúp quản lý toàn bộ hệ thống này.

Đặc biệt nó hỗ trợ:

• ES Modules

• CSS

• JavaScript

• TypeScript

• asset processing

• development server

• HMR

• production build

• bundling

• tối ưu frontend

3. 📦 Vite đứng ở đâu trong Laravel?

Một dự án Laravel có thể hình dung:

Laravel
│
├── PHP
│   ├── Route
│   ├── Controller
│   ├── Model
│   └── Middleware
│
├── Blade
│   └── HTML
│
└── Vite
    ├── CSS
    ├── JavaScript
    ├── Images
    └── Frontend modules

Hai phần này có nhiệm vụ khác nhau.

Laravel

Request
   ↓
Route
   ↓
Controller
   ↓
Model
   ↓
Database
   ↓
Blade
   ↓
HTML

Vite

CSS
JS
Images
Modules
   ↓
 Vite
   ↓
Browser

Do đó:

Laravel xử lý application. Vite xử lý frontend assets.

4. 🗂️ Cấu trúc thư mục

Ví dụ Laravel:

my-project/
│
├── app/
├── routes/
├── resources/
│   ├── css/
│   │   └── app.css
│   │
│   └── js/
│       └── app.js
│
├── public/
│
├── package.json
├── vite.config.js
└── .env

Thông thường source frontend nằm trong:

resources/

Trong khi file sau build sẽ được Vite đưa vào vùng public/build.

5. 📄 vite.config.js

Ví dụ cấu hình cơ bản của Laravel:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/css/app.css',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
    ],
});

Điểm quan trọng là:

input

xác định những file frontend mà Vite cần xử lý.

Ví dụ:

input: [
    'resources/css/app.css',
    'resources/js/app.js',
    'resources/css/admin.css',
    'resources/js/admin.js',
]

6. 📦 package.json

Vite hoạt động thông qua Node.js và npm.

Ví dụ:

{
    "scripts": {
        "dev": "vite",
        "build": "vite build"
    }
}

Chạy:

npm run dev

để phát triển.

Còn:

npm run build

để build production.

7. 🎨 CSS với Vite

Ví dụ:

resources/css/app.css

body {
    font-family: Arial, sans-serif;
}

.card {
    border-radius: 10px;
}

Trong JavaScript:

import '../css/app.css';

Vite sẽ hiểu dependency này.

app.js
   │
   └── app.css

Đây là một điểm rất quan trọng của Vite:

Frontend asset có thể được quản lý như module.

8. ⚙️ JavaScript với Vite

Ví dụ:

resources/js/app.js

import './bootstrap';

console.log('Laravel + Vite');

Có thể chia module:

resources/js/
├── app.js
├── modal.js
├── table.js
└── chart.js

Sau đó:

import './modal';
import './table';
import './chart';

Thay vì nhét toàn bộ JavaScript vào một file khổng lồ.

9. 🔗 @vite() trong Blade

Trong Blade:

@vite([
    'resources/css/app.css',
    'resources/js/app.js'
])

Laravel sẽ kết nối Blade với Vite.

Ở development:

Blade
 ↓
Vite Dev Server
 ↓
CSS / JS

Ở production:

Blade
 ↓
Manifest
 ↓
Built Assets

Đây chính là cầu nối giữa Laravel và Vite.

10. 🏗️ Development và Production

Đây là phần cần hiểu thật kỹ.

Development

Chạy:

npm run dev

Vite mở development server.

Ví dụ:

Browser
   ↓
Laravel
   ↓
Vite
   ↓
resources/js/app.js

Production

Chạy:

npm run build

Vite sẽ xử lý:

resources/
   ↓
Vite
   ↓
build
   ↓
optimized CSS / JS

Ví dụ:

public/build/
├── assets/
│   ├── app-ABC123.js
│   └── app-XYZ456.css
└── manifest.json

Tên file được hash để hỗ trợ cache.

11. 🔥 Hot Module Replacement

Một trong những tính năng rất hay của Vite là HMR.

Bạn sửa:

console.log('Hello');

thành:

console.log('Hello Vite');

Vite có thể cập nhật module trên browser mà không cần refresh toàn bộ trang theo cách truyền thống.

Quy trình:

Edit JS
  ↓
Vite phát hiện thay đổi
  ↓
HMR
  ↓
Browser cập nhật

Đây là lý do Vite tạo cảm giác phát triển frontend rất nhanh.

12. 📦 Module JavaScript

Không dùng Vite, nhiều dự án PHP cũ thường có:

<script src="/js/jquery.js"></script>
<script src="/js/bootstrap.js"></script>
<script src="/js/app.js"></script>
<script src="/js/admin.js"></script>

Với Vite:

import './bootstrap';
import './admin';

Vite xây dựng dependency graph:

app.js
 │
 ├── bootstrap.js
 │
 ├── modal.js
 │
 └── admin.js

Sau đó build thành asset phù hợp.

13. 🖼️ Images, Font và Asset

Ví dụ:

resources/
├── js/
├── css/
└── images/
    └── logo.png

CSS:

.logo {
    background-image: url('../images/logo.png');
}

Vite có thể xử lý asset dependency này trong quá trình build.

14. 🔐 .env và Vite

Vite cũng hỗ trợ biến môi trường.

Ví dụ:

VITE_APP_NAME="My Laravel App"

JavaScript:

console.log(import.meta.env.VITE_APP_NAME);

Có một nguyên tắc quan trọng:

Những biến bắt đầu bằng VITE_ có thể được expose ra frontend.

Vì vậy không được đưa secret/private key vào VITE_*.

15. 🛠️ Vite trong Laravel

Laravel cung cấp integration khá chặt với Vite.

Có thể xem kiến trúc:

Laravel
   │
   ├── Blade
   │
   ├── laravel-vite-plugin
   │
   └── Vite
          │
          ├── CSS
          ├── JS
          ├── Images
          └── Build

Nhưng điều thú vị là:

Vite không hề phụ thuộc Laravel.

Đây chính là chỗ mở rộng kiến thức sang PHP thuần và CI3.

16. 🧱 Sử dụng Vite với PHP thuần

Giả sử dự án:

my-php/
│
├── index.php
├── login.php
│
├── resources/
│   ├── css/
│   │   └── app.css
│   │
│   └── js/
│       └── app.js
│
├── public/
│
├── package.json
└── vite.config.js

Không cần Laravel.

Vite chỉ cần Node.js.

Ví dụ:

npm install vite

package.json:

{
    "scripts": {
        "dev": "vite",
        "build": "vite build"
    }
}

Sau đó:

npm run dev

PHP vẫn chạy bằng Apache/Nginx/Laragon.

Hai server có thể hoạt động song song:

PHP
127.0.0.1:8000

Vite
localhost:5173

17. 🚀 Vite với CodeIgniter 3.x

Đây mới là phần rất đáng học.

CodeIgniter 3 vốn được xây dựng trong thời kỳ frontend tooling chưa phổ biến như hiện nay.

Một dự án CI3 truyền thống thường có:

application/
system/
public/
assets/

và:

<link rel="stylesheet" href="<?= base_url('assets/css/app.css') ?>">
<script src="<?= base_url('assets/js/app.js') ?>"></script>

Không có nghĩa là CI3 không dùng được Vite.

Hoàn toàn có thể.

18. 🔌 Kiến trúc CI3 + Vite

Có thể thiết kế:

CI3
│
├── application/
│   ├── controllers/
│   ├── models/
│   └── views/
│
├── system/
│
├── resources/
│   ├── css/
│   └── js/
│
├── public/
│
├── package.json
└── vite.config.js

Sau khi build:

resources/
      ↓
     Vite
      ↓
public/build/

CI3 chỉ cần load file build.

Ví dụ:

<script type="module"
        src="<?= base_url('build/assets/app.js') ?>">
</script>

19. 📁 Một cấu trúc CI3 hiện đại

Nếu mình xây một project CI3 mới theo hướng hiện đại, có thể tổ chức:

my-ci3/
│
├── application/
│   ├── controllers/
│   ├── models/
│   ├── views/
│   │   ├── layouts/
│   │   ├── admin/
│   │   └── frontend/
│   │
│   └── config/
│
├── resources/
│   ├── css/
│   │   ├── app.css
│   │   └── admin.css
│   │
│   ├── js/
│   │   ├── app.js
│   │   └── admin.js
│   │
│   └── images/
│
├── public/
│   └── build/
│
├── package.json
└── vite.config.js

Backend:

CodeIgniter 3

Frontend:

Vite

Hai hệ thống độc lập nhưng phối hợp với nhau.

20. 🏭 Build CI3 để Deploy

Ở máy development:

npm run dev

Khi deploy:

npm run build

Sau đó server PHP không cần chạy Vite.

Chỉ cần các file đã build:

public/build/

Đây là điểm rất quan trọng.

Production có thể chạy:

Apache/Nginx
      │
      ├── PHP
      │     ↓
      │    CI3
      │
      └── Static Assets
            ↓
           Vite build

Vite không phải backend server production của CI3.

21. ⚠️ Những lỗi thường gặp

Lỗi 1 — Nghĩ Vite là PHP framework

Sai:

Vite = Framework PHP

Đúng:

Vite = Frontend build tool / development server

Lỗi 2 — Đưa API key vào VITE_

Không nên:

VITE_SECRET_KEY=abc123

vì biến này có thể xuất hiện phía frontend.

Lỗi 3 — Production vẫn chạy npm run dev

Không cần.

Production nên:

npm run build

sau đó server phục vụ file build.

Lỗi 4 — CI3 không có @vite()

Đúng.

@vite() là integration của Laravel.

Với CI3 bạn phải tự xây cách load asset:

<script type="module"
        src="<?= base_url('build/assets/app.js') ?>">
</script>

22. 🧠 Laravel Mix và Vite

Có thể hình dung:

Laravel cũ
     ↓
Laravel Mix
     ↓
Webpack

Laravel hiện đại:

Laravel
   ↓
Vite
   ↓
esbuild / Rollup ecosystem

Vite có workflow frontend hiện đại hơn và development server nhanh hơn.

23. 🎯 Khi nào nên dùng Vite?

Không nhất thiết dự án PHP nào cũng cần Vite.

Website cực đơn giản

PHP
├── HTML
├── CSS
└── vài dòng JS

Có thể không cần.

Dashboard lớn

PHP
+
Bootstrap
+
Chart.js
+
DataTables
+
Modules JS
+
SCSS

Vite bắt đầu rất hữu ích.

SPA / frontend phức tạp

Laravel / CI3 / PHP API
          +
React / Vue
          +
Vite

thì Vite càng phù hợp.

24. 🏆 Kiến trúc PHP hiện đại

Điểm quan trọng nhất của bài này không phải là:

“Laravel dùng Vite như thế nào?”

mà là hiểu rằng Vite có thể đứng độc lập với PHP framework.

Ta có thể xây:

                 FRONTEND
                    │
                  Vite
                    │
        ┌───────────┼───────────┐
        │           │           │
       CSS         JS        Images
        │           │
        └───────────┼───────────┘
                    │
                  Build
                    │
                    ▼
              Browser
                    ▲
                    │
                  HTML
                    │
        ┌───────────┼───────────┐
        │           │           │
     Laravel       CI3       PHP thuần
        │           │           │
        └───────────┼───────────┘
                    │
                 Database

Đây là tư duy rất đáng học:

Vite không thuộc riêng Laravel. Laravel chỉ cung cấp một integration thuận tiện với Vite.

Vì vậy sau khi học Vite trong Laravel, ta hoàn toàn có thể lấy kiến thức đó áp dụng cho CodeIgniter 3.x, PHP thuần, Symfony hoặc bất kỳ backend PHP nào.

🎯 Mục tiêu bài học

Trong các bài trước, chúng ta đã làm việc trực tiếp với:

• Controller

• Model

• Event

• Listener

• Observer

• Notification

• Mail

Tuy nhiên, có một vấn đề:

Nếu một công việc mất nhiều thời gian, chúng ta có muốn người dùng phải chờ cho đến khi công việc hoàn thành hay không?

Ví dụ:

Người dùng tạo bài viết
        ↓
Laravel lưu bài viết
        ↓
Gửi email
        ↓
Tạo thumbnail
        ↓
Tạo thông báo
        ↓
Ghi log
        ↓
Trả Response

Nếu tất cả đều chạy ngay trong HTTP Request, người dùng có thể phải chờ rất lâu.

Laravel Queue giải quyết vấn đề này bằng cách đưa những công việc cần xử lý sau vào hàng đợi.

Mô hình:

HTTP Request
     │
     ▼
Lưu dữ liệu
     │
     ▼
Dispatch Job
     │
     ├──────────────► Response
     │
     ▼
   Queue
     │
     ▼
   Worker
     │
     ▼
Xử lý công việc

📑 MỤC LỤC

1. 🚀 Queue là gì?

2. ⚙️ Laravel Queue hoạt động như thế nào?

3. 🧩 Ba thành phần: Job — Queue — Worker

4. 🗄️ Queue Driver là gì?

5. 🔄 Các Queue Driver phổ biến

6. 🔧 Cấu hình Queue

7. 🛠️ Tạo bảng Queue

8. 📦 Tạo Job

9. 🎯 handle() là gì?

10. 📥 Truyền dữ liệu vào Job

11. 🚀 Dispatch Job

12. 🌐 Request hoạt động như thế nào khi dùng Queue?

13. 👷 Chạy Queue Worker

14. 🔁 Worker chạy liên tục

15. ⏳ Delay Job

16. 📚 Xử lý nhiều loại Job

17. 🔗 Queue kết hợp Event & Listener

18. 📝 Ứng dụng Queue trong Blog CMS

19. ❌ Failed Jobs

20. 🔍 Kiểm tra Failed Jobs

21. 🔄 Retry Job

22. 💥 Xử lý Job thất bại với failed()

23. ⭐ Queue Priority

24. 🧭 Queue Routing trong Laravel 13

25. 🖥️ Queue Worker trong Production

26. ⚡ Queue có thực sự chạy Background không?

27. 🔀 So sánh sync và database

28. 🧪 Ví dụ Queue hoàn chỉnh

29. 🏗️ Queue trong kiến trúc Laravel

30. 💡 Khi nào nên sử dụng Queue?

31. 🚫 Khi nào không nên dùng Queue?

32. 🐛 Các lỗi Queue thường gặp

33. 🧠 Tư duy quan trọng khi học Queue

34. 📌 Tóm tắt kiến thức & Bài tập thực hành