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

Server Actions cho phép gọi trực tiếp các hàm phía server từ components mà không cần tạo các API endpoints trung gian. Về bảo mật, React 19 tự động tạo ra các secure tokens để ngăn chặn CSRF attacks. Thay vì viết fetch request thủ công, bạn chỉ cần đánh dấu hàm với 'use server'. Ví dụ: async function submitForm(formData) { 'use server'; await db.save(formData); }. Điều này giúp giảm boilerplate code, đảm bảo tính nhất quán giữa client và server, và cho phép thực hiện validation ngay tại server một cách tập trung.

Hook useOptimistic cho phép hiển thị trạng thái dự kiến của giao diện trước khi server phản hồi kết quả. Khi người dùng thực hiện hành động, bạn cập nhật trạng thái optimistic ngay lập tức. Nếu server trả về lỗi, React sẽ tự động revert về trạng thái trước đó. Ví dụ: const [optimisticState, addOptimistic] = useOptimistic(state, (currentState, newValue) => newValue);. Điều này tạo cảm giác ứng dụng phản hồi tức thì (instant feedback), giúp tăng trải nghiệm người dùng trong các hệ thống có độ trễ mạng cao.

Server Components giúp giảm thiểu số lượng component cần hydrate trên client. Khi một phần lớn giao diện được render ở server, trình duyệt không cần tải và thực thi code của các component đó, dẫn đến thời gian Time to Interactive (TTI) nhanh hơn. Ngoài ra, nó loại bỏ hiện tượng waterfall network requests vì các dữ liệu cần thiết đã được fetch trực tiếp tại server trước khi component được render, giúp tối ưu hóa băng thông và tài nguyên CPU trên phía client.

Server Actions nên được ưu tiên khi thực hiện các thao tác thay đổi dữ liệu (mutations) như tạo, cập nhật hoặc xóa dữ liệu trực tiếp từ form. Trong khi React Query/SWR mạnh mẽ trong việc caching và đồng bộ dữ liệu từ API endpoints, Server Actions đơn giản hóa luồng dữ liệu bằng cách loại bỏ nhu cầu quản lý các API route riêng biệt. Nếu ứng dụng của bạn dựa nhiều vào kiến trúc Server-Side Rendering (SSR) hoặc Next.js, Server Actions giúp code gọn gàng hơn và tận dụng được cơ chế revalidation tự động của framework.

Progressive Enhancement là khả năng ứng dụng vẫn hoạt động ngay cả khi JavaScript trên trình duyệt bị tắt hoặc chưa tải xong. Với Server Actions, bạn có thể sử dụng thẻ

Thách thức lớn nhất là việc duy trì kết nối với database hoặc các dịch vụ bên ngoài trong quá trình render. Vì Server Components render trên mỗi request, việc khởi tạo kết nối liên tục có thể gây quá tải. Cần sử dụng các kỹ thuật như connection pooling hoặc singleton pattern để tái sử dụng kết nối. Ngoài ra, cần cẩn trọng với việc truyền dữ liệu quá lớn từ server xuống client thông qua props, vì dữ liệu này sẽ được serialize và làm tăng kích thước payload, ảnh hưởng đến hiệu năng mạng.

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.