Electron là một framework mã nguồn mở cho phép bạn xây dựng ứng dụng desktop đa nền tảng (Windows, macOS, Linux) chỉ với JavaScript, HTML và CSS, bằng cách kết hợp Chromium và Node.js trong cùng một môi trường.
Nó giúp lập trình viên web dễ dàng tạo ứng dụng desktop mà không cần học thêm ngôn ngữ native như C++ hay Swift.
Trong các bài trước của khóa Laravel 13, chúng ta đã làm việc chủ yếu với:
PHP
Laravel
Blade
Database
Eloquent
REST API
Laravel Sanctum
Những thành phần này chủ yếu xử lý phía Server.
Nhưng một ứng dụng web hiện đại không chỉ có Server.
Khi người dùng:
bấm nút,
mở Modal,
gửi Form,
tìm kiếm,
lọc dữ liệu,
upload ảnh,
tải dữ liệu không cần reload trang,
cập nhật giao diện ngay lập tức,
thì chúng ta cần đến JavaScript.
Vì vậy, trước khi học Vue, React hoặc các Frontend Framework khác, chúng ta cần nắm được JavaScript hiện đại.
Nếu cập nhật theo Laravel 12 LTS (2026) thì mình sẽ chia thành các phần như sau để người học đi từ PHP Core → Laravel → Triển khai dự án thực tế.
Sau 49 bài, chúng ta đã đi từ những khái niệm đầu tiên của Laravel đến việc xây dựng một Blog CMS hoàn chỉnh.
Trong bài cuối cùng này, chúng ta sẽ không học thêm một tính năng mới.
Thay vào đó, chúng ta sẽ nhìn lại toàn bộ dự án:
Đã học những gì?
Các thành phần kết nối với nhau như thế nào?
Source code cần tối ưu ra sao?
Cần kiểm tra gì trước khi đưa website lên Internet?
Một dự án Laravel 13 hoàn chỉnh cần có những thành phần nào?
Đây cũng là bước chuyển từ:
"Học Laravel"
sang:
"Có thể tự xây dựng và triển khai một ứng dụng Laravel thực tế."
Trong 50 bài chính, chúng ta đã hoàn thành một Blog CMS với:
Authentication
CRUD
Database
Eloquent
Relationship
Validation
Upload
Search
Pagination
Soft Delete
Authorization
Queue
Notification
Cache
Storage
Logging
REST API
Sanctum
Deployment
Nhưng có một vấn đề:
Làm sao biết code của chúng ta vẫn hoạt động đúng sau khi sửa hoặc thêm tính năng mới?
Đó là lúc Automated Testing xuất hiện.
Trong bài Bonus này, chúng ta chỉ học những kiến thức PHPUnit cần thiết để bắt đầu kiểm thử một ứng dụng Laravel 13.
p/S: mục 8 trở đi mới chạy được.
Ở các bài trước, chúng ta đã lần lượt xây dựng và triển khai Blog CMS:
Bài 45 → Shared Hosting
Bài 46 → VPS
Bài 47 → Nginx
Bài 48 → Queue Worker & Scheduler
Đến đây ứng dụng đã có thể chạy trên production.
Nhưng:
Chạy được chưa có nghĩa là đã được cấu hình tốt cho production.
Một Laravel application thực tế cần quan tâm thêm:
Performance
Cache
Environment
Debug
Security
Database
Queue
Storage
Logs
Deployment
Configuration
Laravel 13 cung cấp sẵn nhiều công cụ để tối ưu những vấn đề này. Trong tài liệu deployment chính thức, Laravel đặc biệt khuyến nghị cache configuration, events, routes và views khi triển khai production.
Ở Bài 47, chúng ta đã cấu hình:
Internet
↓
Nginx
↓
PHP-FPM
↓
Laravel 13
Nhưng một ứng dụng thực tế thường không chỉ xử lý request ngay lập tức.
Ví dụ Blog CMS của chúng ta có thể cần:
gửi email;
gửi notification;
xử lý ảnh;
tạo báo cáo;
xóa dữ liệu cũ;
đồng bộ dữ liệu;
gửi email hàng loạt;
chạy tác vụ mỗi ngày;
dọn database;
kiểm tra bài viết scheduled.
Nếu bắt người dùng chờ tất cả những việc này hoàn thành trong HTTP request thì website sẽ chậm.
Laravel cung cấp hai cơ chế rất quan trọng:
Queue
Scheduler
Trong bài này chúng ta sẽ đưa cả hai lên VPS production.
Ở Bài 46, chúng ta đã đưa Laravel 13 lên VPS.
Nhưng một Laravel project trên VPS chưa thể tự nhiên hoạt động như một website production chỉ bằng việc upload source code.
Chúng ta cần một Web Server.
Một mô hình phổ biến là:
Internet
│
▼
Nginx
│
▼
PHP-FPM
│
▼
Laravel 13
│
├── MySQL
├── Storage
└── Cache
Trong bài này chúng ta sẽ học cách cấu hình Nginx cho Laravel 13.
Ở Bài 45, chúng ta đã đưa Laravel 13 lên Shared Hosting.
Trong bài này, chúng ta tiến thêm một bước:
Shared Hosting
↓
VPS
VPS cho phép chúng ta tự quản lý server ở mức thấp hơn:
VPS
│
├── Ubuntu
├── Nginx
├── PHP
├── PHP-FPM
├── MySQL
├── Composer
├── Git
├── SSL
└── Laravel 13
Đây là mô hình rất quan trọng nếu muốn làm Laravel ở môi trường production thực tế
Sau khi hoàn thành:
Bài 41 — REST API
Bài 42 — API Resource
Bài 43 — Sanctum
Bài 44 — API Authentication
chúng ta đã hoàn thành phần REST API.
Bây giờ bắt đầu:
Và bài đầu tiên là:
Deploy Laravel 13 lên Shared Hosting
Mục tiêu của bài này là đưa project Blog CMS từ:
Máy tính cá nhân
↓
Laragon
↓
127.0.0.1:8000
lên:
Shared Hosting
↓
domain.com
↓
Laravel 13
↓
MySQL
Ở Bài 41, chúng ta đã xây dựng REST API.
Ở Bài 42, chúng ta biết cách dùng API Resource để định dạng JSON.
Ở Bài 43, chúng ta đã học Laravel Sanctum và API Token.
Bây giờ chúng ta sẽ ghép tất cả lại để xây dựng một hệ thống:
Client
│
│ email + password
▼
POST /api/login
│
▼
Laravel kiểm tra tài khoản
│
├── Sai → 422 / 401
│
└── Đúng
│
▼
Sanctum Token
│
▼
Authorization: Bearer TOKEN
│
▼
Protected API
Đây chính là nền tảng authentication thường gặp khi Laravel đóng vai trò API Backend cho:
Website JavaScript
React
Vue
Next.js
Mobile App
Desktop App
ứng dụng bên thứ ba
Laravel 13 có thể sử dụng Sanctum để xác thực API bằng token. Token được gửi trong HTTP header dưới dạng Bearer Token.
Ghi chú: mục 12 trở đi mới dùng Postman test được.
Laravel Sanctum cung cấp cơ chế xác thực nhẹ cho API token, SPA và các ứng dụng mobile.
Ở Bài 41, chúng ta đã xây dựng REST API.
Ở Bài 42, chúng ta dùng API Resource để kiểm soát dữ liệu JSON.
Nhưng API hiện tại có một vấn đề:
GET /api/posts
POST /api/posts
PUT /api/posts/1
DELETE /api/posts/1
Ai cũng có thể gửi request.
Ví dụ:
Anonymous User
↓
POST /api/posts
↓
Tạo bài viết?
Đây rõ ràng không phải điều chúng ta muốn.
Chúng ta cần biết:
Ai đang gọi API?
Và:
Người đó có được phép gọi API này không?
Đó là lúc Laravel Sanctum xuất hiện.
API Resource là lớp trung gian giúp chúng ta kiểm soát dữ liệu từ Eloquent Model trước khi Laravel trả dữ liệu về cho API client dưới dạng JSON.
Ở Bài 41 — REST API, chúng ta đã tạo được:
GET /api/posts
GET /api/posts/{post}
POST /api/posts
PUT /api/posts/{post}
DELETE /api/posts/{post}
Nhưng chúng ta gặp một vấn đề:
return $post;
hoặc:
return Post::all();
Laravel có thể tự chuyển Model thành JSON.
Điều này rất tiện.
Nhưng đối với một API thực tế, chúng ta thường không muốn trả toàn bộ dữ liệu của Model.
Đó chính là lúc:
xuất hiện.
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.
Chạy lệnh Composer:
composer require colorlibhq/adminlte-laravelSau đó 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.).
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:
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.
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.
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
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 📝.
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:
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ếtVì 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'])
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.
Đâ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 + AutomationNhư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?"
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ậnNhư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:
🗃️ 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.
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 + WEBSITENhư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 maiVà đâ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.
Ở 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.
Ở 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.
Ở 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.
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)
Đừ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
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?
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.
🔎 Tìm sản phẩm có người mua
👥 Tìm nơi có khách
📱 Biến Facebook/TikTok thành nơi kéo khách
🎬 Làm video bán hàng bằng điện thoại
✍️ Viết nội dung khiến khách hỏi mua
💬 Biến lượt xem thành tin nhắn
🛒 Biến tin nhắn thành đơn hàng
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
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
