NTM Solutions

Chủ Nhật, 20 tháng 9, 2026

🔐BÀI 44 — API AUTHENTICATION

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.

Thứ Bảy, 19 tháng 9, 2026

🔐LARAVEL 13 — BÀI 43: SANCTUM

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.

Thứ Sáu, 18 tháng 9, 2026

🚀LARAVEL 13 — BÀI 42: API RESOURCE

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:

API Resource

xuất hiện.

Thứ Năm, 17 tháng 9, 2026

✨📚 Cách dùng các thư viện cũ trong Laravel 13 🛠️

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.jsresources/css/adminlte.css.

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

🚀LARAVEL 13 — BÀI 41: REST API

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.

Thứ Tư, 16 tháng 9, 2026

📘LARAVEL 13 — BÀI 40 — LOGGING & DEBUG

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

Thứ Ba, 15 tháng 9, 2026

📘 LARAVEL 13 — BÀI 39 — STORAGE

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 📝.

🎨 Laravel 13: Hướng Dẫn Sắp Xếp & Quản Lý Assets 📂

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'])
Thứ Hai, 14 tháng 9, 2026

📘 LARAVEL 13 — BÀI 38 — CACHE

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.

Chủ Nhật, 13 tháng 9, 2026

🏆 PHẦN 6 — LÀM RA TIỀN THẬT

Đâ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?"

📘 LARAVEL 13 — BÀI 37 — NOTIFICATION

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.


Thứ Bảy, 12 tháng 9, 2026

🤖 PHẦN 5 — AI GIÚP BÁN HÀNG

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.

Thứ Sáu, 11 tháng 9, 2026

🌐 PHẦN 4 — GOOGLE & WEBSITE

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.

Thứ Năm, 10 tháng 9, 2026

🔥 PHẦN 3 — KIẾM NHIỀU HƠN TỪ MỘT KHÁCH

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.

Thứ Tư, 9 tháng 9, 2026

💰 PHẦN 2 — DÙNG TIỀN ĐỂ MUA KHÁCH

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.

Thứ Ba, 8 tháng 9, 2026

📘LARAVEL 13 — BÀI 36 — MAIL

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)

💰 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

Đừ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.

Thứ Hai, 7 tháng 9, 2026

💰 DIGITAL MARKETING — HỌC ĐỂ RA TIỀN

🛒 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

Thứ Bảy, 5 tháng 9, 2026

📘 LARAVEL 12 LTS (2026) — BÀI 35: QUEUE

🎯 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

Facebook Youtube RSS