NTM Solutions

Bài đăng nổi bật

🚀 Laravel 12 (2026) — Từ PHP Core đến Full Stack📘

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

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

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.

Ghi chú:

Khi deploy lên host (production), bạn nên tắt Debugbar để tránh lộ thông tin debug và giảm tải hệ thống.

01. Cấu hình môi trường

Debugbar mặc định chỉ nên chạy ở môi trường local. Bạn có thể ép tắt bằng biến môi trường.

  • Trong file .env trên host, thêm dòng: APP_ENV=production
  • Đảm bảo không có cấu hình override nào cho Debugbar

02. Xóa Service Provider

Debugbar được đăng ký trong config/app.php hoặc thông qua auto-discovery.

  • Mở file config/app.php
  • Xóa hoặc comment đoạn đăng ký Barryvdh\Debugbar\ServiceProvider::class
  • Deploy lại code lên host

03. Cấu hình trong config

Trong file config/debugbar.php, bạn có thể tắt bằng cách:

  • Đặt 'enabled' => env('APP_DEBUG', false)
  • Trên host, đảm bảo APP_DEBUG=false trong .env

04. Gỡ hẳn package (tuỳ chọn)

Nếu không cần Debugbar nữa, bạn có thể gỡ bỏ khỏi project.

  • Chạy lệnh: composer remove barryvdh/laravel-debugbar
  • Xóa migrations hoặc config liên quan nếu muốn dọn sạch

Tóm lại, cách đơn giản nhất là đặt APP_ENV=production và APP_DEBUG=false trong .env trên host, Debugbar sẽ tự động không hiển thị. 

Nếu muốn triệt để, bạn có thể xóa Service Provider hoặc gỡ package.


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ú:

Khi đưa ứng dụng Laravel lên host (production), bạn nên tắt Telescope để tránh lộ dữ liệu debug và giảm tải hệ thống. Có vài cách phổ biến:

01. Xóa Service Provider

Telescope được đăng ký trong AppServiceProvider hoặc bootstrap/providers.php.

  • Mở file App\Providers\AppServiceProvider
  • Xóa hoặc comment đoạn đăng ký TelescopeServiceProvider
  • Deploy lại code lên host

02. Cấu hình môi trường

Telescope mặc định chỉ chạy ở môi trường local. Bạn có thể ép tắt bằng biến môi trường.

Trong file .env trên host:

  • Thêm dòng: APP_ENV=production
  • Đảm bảo không có cấu hình override nào cho Telescope

03. Xóa route Telescope

Nếu vẫn còn route /telescope, bạn có thể xóa hẳn.

  • Xóa file TelescopeServiceProvider
  • Hoặc comment toàn bộ nội dung trong đó
  • Chạy lại composer dump-autoload

04. Gỡ hẳn package (tuỳ chọn)

Nếu không cần Telescope nữa, bạn có thể gỡ bỏ khỏi project.

  • Chạy lệnh: composer remove laravel/telescope
  • Xóa migrations liên quan nếu muốn dọn sạch database

Tóm lại, cách đơn giản nhất là đặt APP_ENV=production trong .env trên host, Telescope sẽ tự động không hiển thị. 

Nếu muốn triệt để, bạn có thể xóa Service Provider hoặc gỡ package.


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

Công cụMục đích
LogGhi thông tin ứng dụng
dd()Kiểm tra dữ liệu nhanh
dump()Kiểm tra dữ liệu nhưng tiếp tục chạy
DebugbarQuan sát request hiện tại
TelescopeQuan sát hoạt động của Laravel

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

Không có nhận xét nào:

Đăng nhận xét

Facebook Youtube RSS