Thư Viện Câu Hỏi Phỏng Vấn

Trong React 19, Server Actions có thể trả về các giá trị hoặc throw errors. Để xử lý, bạn nên sử dụng try-catch block bên trong Server Action và trả về một object chứa trạng thái lỗi. Ở phía client, bạn có thể sử dụng hook useActionState để theo dõi trạng thái của action (pending, data, error). Điều này giúp đồng bộ hóa thông báo lỗi từ server trực tiếp lên giao diện người dùng mà không cần thông qua các state management phức tạp.

useTransition dùng để đánh dấu các cập nhật state là không khẩn cấp (non-urgent), giúp giao diện không bị treo khi thực hiện các tác vụ nặng. Trong khi đó, useOptimistic tập trung vào việc hiển thị trạng thái tạm thời cho người dùng trong khi chờ đợi một tác vụ bất đồng bộ hoàn tất. Thông thường, bạn sẽ kết hợp cả hai: sử dụng useTransition để bắt đầu action và useOptimistic để cập nhật giao diện ngay lập tức trước khi action hoàn thành.

Lợi ích: Giảm thiểu sự phụ thuộc vào các thư viện client-side giữa các micro-apps, giúp cải thiện đáng kể tốc độ tải trang ban đầu. Rủi ro: Sự phức tạp trong việc chia sẻ context và state giữa các phần của ứng dụng nếu chúng được render từ các server khác nhau. Việc quản lý các shared components giữa các team cũng trở nên khó khăn hơn do sự khác biệt giữa Server và Client Components. Cần thiết lập một design system thống nhất và các contract chặt chẽ về dữ liệu giữa các micro-services để tránh lỗi runtime.

Khi triển khai Reverb trên môi trường Cluster, thách thức lớn nhất là đồng bộ hóa sự kiện giữa các Server Node. Để giải quyết, cần sử dụng Redis làm Pub/Sub backend cho Reverb. Cơ chế hoạt động: Khi một sự kiện được phát đi từ một Node, nó sẽ được đẩy vào Redis, sau đó Redis sẽ broadcast sự kiện đó đến tất cả các Node khác đang lắng nghe. Cấu hình cần thiết trong file .env: BROADCAST_CONNECTION=reverb và đảm bảo REDIS_CLIENT=phpredis để đạt hiệu suất cao nhất. Lưu ý: Cần cấu hình Load Balancer hỗ trợ Sticky Sessions nếu ứng dụng có sử dụng các tính năng liên quan đến stateful connection.

Laravel Reverb là một giải pháp WebSocket server được xây dựng trực tiếp trên nền tảng PHP (sử dụng Ratchet/ReactPHP), giúp loại bỏ sự phụ thuộc vào các dịch vụ bên thứ ba như Pusher. Ưu điểm: Giảm thiểu chi phí vận hành, độ trễ thấp hơn do không cần qua trung gian API của bên thứ ba, và khả năng tùy biến sâu vào core của ứng dụng. Tuy nhiên, Pusher cung cấp tính sẵn sàng cao (High Availability) và khả năng mở rộng tự động mà không cần quản lý hạ tầng. Trong hệ thống độ trễ thấp, Reverb chiếm ưu thế nhờ việc chạy nội bộ trong hạ tầng của bạn, giúp kiểm soát hoàn toàn luồng dữ liệu.

Với cấu trúc Minimalist, chúng ta nên chuyển dịch sang kiến trúc Domain-Driven Design (DDD) hoặc Modular Monolith. Thay vì để tất cả Service trong thư mục App/Services, hãy tạo các thư mục theo Domain (ví dụ: App/Domains/Order, App/Domains/User). Mỗi Domain sẽ chứa các Service, DTO, và Action riêng biệt. Điều này giúp cô lập logic, dễ dàng bảo trì và khi cần thiết có thể tách các Domain này thành các Microservices độc lập mà không cần thay đổi cấu trúc cốt lõi của ứng dụng.

Để xử lý Race Condition, không nên chỉ dựa vào Database Transaction thông thường. Cần sử dụng Atomic Locks kết hợp với Pessimistic Locking. Ví dụ: Sử dụng Cache::lock('updatebalance' . $userId, 10)->get(function () { ... }) để đảm bảo chỉ một tiến trình được thực thi tại một thời điểm. Kết hợp với câu lệnh SELECT ... FOR UPDATE trong Eloquent để khóa hàng dữ liệu trong Database. Điều này ngăn chặn việc đọc dữ liệu cũ trong khi tiến trình khác đang ghi, đảm bảo tính toàn vẹn dữ liệu tuyệt đối.

Laravel 11 tiếp tục tối ưu hóa Service Container thông qua việc sử dụng cơ chế Lazy Loading cho các Service Provider. Để tối ưu hiệu năng, hãy sử dụng deferred providers bằng cách khai báo thuộc tính $defer = true trong Service Provider. Điều này đảm bảo rằng các Service chỉ được khởi tạo khi thực sự cần thiết, giúp giảm thời gian bootstrap của ứng dụng. Đối với các ứng dụng quy mô lớn, việc sử dụng 'Contextual Binding' giúp giảm bớt sự phức tạp khi giải quyết các dependency trùng lặp.

Tính bảo mật của Private Channel dựa trên cơ chế xác thực thông qua HTTP request. Khi client cố gắng đăng ký vào một kênh private, Reverb sẽ gửi một request đến ứng dụng Laravel của bạn. Tại đây, bạn phải kiểm tra quyền của người dùng trong file routes/channels.php. Kinh nghiệm thực chiến: Luôn sử dụng HTTPS để mã hóa dữ liệu truyền tải. Ngoài ra, cần thiết lập các chính sách Authorization chặt chẽ và giới hạn phạm vi truy cập của Token để tránh việc leo thang đặc quyền trong hệ thống thời gian thực.

Với bảng dữ liệu lớn, cần tránh sử dụng Eloquent ORM cho các truy vấn phức tạp hoặc báo cáo. Thay vào đó, hãy sử dụng Query Builder hoặc Raw SQL để giảm overhead của việc khởi tạo Model. Kỹ thuật quan trọng: Sử dụng 'Chunking' hoặc 'Lazy Collections' khi xử lý dữ liệu lớn để tránh tràn bộ nhớ (Memory Leak). Đồng thời, hãy tận dụng Database Indexing, Eager Loading (with) để tránh N+1 query, và triển khai Database Read/Write Splitting thông qua cấu hình trong file config/database.php.

Trong Laravel 11, file bootstrap/app.php đóng vai trò là trung tâm cấu hình ứng dụng thay vì các Service Provider truyền thống. Bạn có thể tùy chỉnh Middleware thông qua phương thức ->withMiddleware(function (Middleware $middleware) { ... }). Ví dụ: thêm middleware vào nhóm 'web' hoặc 'api', hoặc định nghĩa các alias. Cách tiếp cận này giúp việc cấu hình trở nên tập trung, dễ quản lý và giảm thiểu số lượng file cần chỉnh sửa khi muốn thay đổi luồng xử lý request toàn cục.

Khi Docker container dừng, các Worker đang xử lý job có thể bị ngắt đột ngột gây lỗi dữ liệu. Để giải quyết, cần bắt tín hiệu SIGTERM từ hệ điều hành. Trong Laravel, lệnh 'php artisan queue:work' tự động xử lý tín hiệu này. Tuy nhiên, cần đảm bảo thời gian timeout của Docker (stop_grace_period) lớn hơn thời gian xử lý job dài nhất. Ngoài ra, nên sử dụng các cơ chế như 'Job Batching' hoặc 'Atomic Jobs' để đảm bảo rằng nếu một job bị ngắt giữa chừng, nó có thể được retry an toàn mà không gây ra trạng thái không nhất quán.

Việc đặt logic trong Controller (Fat Controller) vi phạm nguyên lý Single Responsibility Principle (SRP). Action Classes giúp tách biệt logic nghiệp vụ, giúp code dễ dàng Unit Test, tái sử dụng trong các ngữ cảnh khác nhau (như Artisan Command, Job, hoặc API). Trong Laravel 11, việc sử dụng Action Classes kết hợp với Form Requests giúp Controller chỉ đóng vai trò điều phối (orchestration), giúp mã nguồn sạch sẽ, dễ bảo trì và tuân thủ chặt chẽ cấu trúc Minimalist mà framework hướng tới.

Để tối ưu hóa Reverb trong môi trường chịu tải cao, cần tập trung vào các khía cạnh sau:

Cấu trúc Minimalist trong Laravel 11 mặc định loại bỏ các thư mục như Middleware hay Request nếu không cần thiết. Đối với dự án lớn, cần áp dụng tư duy sau: