Đã bao giờ bạn tự hỏi khi đi phỏng vấn cho vị trí Junior-Developer, liệu bạn sẽ bị hỏi những câu hỏi gì chưa? Cùng tìm hiểu và tự kiểm tra xem bạn đã có câu trả lời cho những câu hỏi đó hay chưa.
Hỏi số 1: Event và Listener là gì? Khi nào và tại sao chúng được sử dụng? Có ví dụ nào không?
Trả lời:
Event và Listener đều là các khái niệm quan trọng trong Laravel. Event là sự kiện, và Listener là đối tượng lắng nghe sự kiện đó. Khi sự kiện xảy ra, Listener sẽ đáp ứng theo cách được định nghĩa trước.
Một ví dụ để giúp bạn hiểu rõ hơn: Giả sử bạn đang buồn vì chuyện của crush. Vậy Event sẽ là bạn đang buồn, còn Listener sẽ là cách bạn đáp ứng với tình trạng buồn đó. Hai khái niệm này luôn liên quan chặt chẽ với nhau và chắc chắn sẽ là một phần không thể thiếu trong phỏng vấn.
Lý do chúng ta sử dụng Event thay vì việc gọi trực tiếp trong Controller là để chúng ta có thể cập nhật dữ liệu của các bảng khác mà không cần phải gọi chúng lặp lại trong Controller. Đồng thời, việc xử lý theo từng Event sẽ khác nhau, và có thể rất phức tạp.
Ví dụ, khi bạn viết một bài post, bạn muốn bài viết của mình nhanh chóng trở thành bài hot. Thay vì xét bài viết là bài hot trong hàm xử lý của Controller, bạn có thể tách riêng thành một Event gọi là "SetHotPost" và một Listener để xử lý Event này. Sau đó, bạn chỉ cần gọi Event này từ Controller.
Nếu bạn là người quản lý, bạn muốn có một chức năng "one click" để đặt bài viết là Hot mà không cần phải chỉnh sửa. Bạn có thể viết một hàm xử lý khác và gọi Event "SetHotPost" ở đó. Điều này giúp tiện lợi hơn rất nhiều. Nếu bạn có 2 Controller gọi cùng Event này, bạn sẽ không cần phải lặp lại 100 dòng code mà Event đó thực hiện. Điều này giúp tránh việc lặp code - theo nguyên tắc DRY (Don't Repeat Yourself).
Hỏi số 2: Queue là gì? Tại sao cần sử dụng Queue? Có những loại Queue nào? Đưa ra một ví dụ về việc sử dụng Queue.
Trả lời:
Trong cuộc sống hàng ngày, chúng ta thường phải thực hiện nhiều công việc một cách đồng thời. Và như câu tục ngữ nói: "Việc dễ thì làm trước, việc khó thì làm sau". Laravel Queue được thiết kế để xử lý các tác vụ này một cách tuần tự.
Tại sao chúng ta cần sử dụng Queue? Queue giúp phân phối các tác vụ và làm chúng cân bằng, đảm bảo rằng chúng không gây trì trệ cho các tác vụ sắp tới. Có hai loại Queue là Queue đồng bộ và Queue bất đồng bộ.
Laravel Queue hỗ trợ nhiều kết nối khác nhau. Bạn có thể xem các kết nối này trong file queue.php trong thư mục config.
Ví dụ về việc sử dụng Queue: Tiếp tục câu chuyện trên về Event và Listener, bạn đang buồn vì chuyện tình yêu của mình. Tuy nhiên, sau đó bạn nhận ra rằng bạn nên từ bỏ. Bạn đăng một status trên Facebook như sau:
Giả sử bạn có 1000 người theo dõi và sẽ nhận được thông báo khi bạn đăng bài. Queue sẽ thực hiện tuần tự việc gửi mail, không phải gửi tất cả cùng một lúc.
Bên cạnh đó, khi gửi mail, chúng ta thường không gửi trực tiếp từ Laravel mà thông qua một bên thứ ba. Có một số dịch vụ gửi mail được sử dụng phổ biến như sendgrid, mailtrap... Tuy nhiên, các dịch vụ này có giới hạn số lượt request theo thời gian. Ví dụ, sendgrid cho phép tối đa 10000 request/giây. Mỗi email có thể có tối đa 1000 người nhận. Ngoài ra, việc gửi mail mà không sử dụng Queue có thể gây tắc nghẽn cho phần cứng của bạn. Vì vậy, luôn luôn sử dụng Queue khi gửi mail hoặc các nhiệm vụ liên quan đến thông báo.
Hỏi số 3: CSRF Token là gì? Tại sao cần phải sử dụng? Có bắt buộc phải có không? Nếu không muốn sử dụng CSRF Token thì có được không?
Trả lời:
CSRF Token là một đoạn mã được gửi kèm lên server để kiểm tra xem yêu cầu có được thực thi hay không. Ví dụ, bạn có API http://domain/api/post/{id}/delete để xóa một bài post. Bạn tạo một thẻ img có nội dung như sau:
<img src="http://domain/api/post/1/delete" height=0 width=0 />
Bạn gửi link hoặc email kèm theo đoạn mã này. Sau khi ảnh được tải, dữ liệu của bạn sẽ bị xóa. Đây là một trường hợp đơn giản để hiểu cần tìm hiểu về CSRF Token.
Ngoài thẻ img, còn có các thẻ khác như iframe, script... và những thẻ có thể chèn thông tin xấu khi được tải.
Laravel tự động tạo một CSRF Token cho mỗi phiên người dùng, và token này được sử dụng để xác minh người dùng đã được chứng thực hay không. Tuy nhiên, điều này chỉ giúp bạn tránh một phần những rủi ro, không phải một biện pháp phòng chống tuyệt đối.
Vì vậy, bạn nên tránh nhấn vào các link, ảnh không rõ nguồn gốc. Nếu bạn thấy trên Facebook có các liên kết nhạy cảm và sau đó bạn bị đổi tên thành "Messenger Thông Báo", bạn cũng nên sử dụng các method trong Laravel đúng cách, ví dụ method GET chỉ dùng để truy vấn dữ liệu, còn POST, PUT, PATCH, DELETE dùng để thay đổi dữ liệu trong hệ thống.
CSRF Token không bắt buộc. Mặc định, nếu bạn gửi yêu cầu mà không có CSRF Token, server sẽ trả về lỗi 419 (Token Miss Match). Vì tất cả các yêu cầu được gửi lên đều được chạy qua middleware VerifyCsrfToken, bạn cần kèm theo token này. Bạn có thể chỉ định các URL mà bạn muốn từ chối xác minh CSRF Token bằng cách mở file VerifyCsrfToken.php trong thư mục Middleware và thêm các URL đó vào danh sách ngoại lệ.
Hỏi số 4: Mô tả luồng dữ liệu từ khi người dùng nhập URL cho đến khi hoàn thành. (Request Lifecycle)
Trả lời:
Khi người dùng nhập URL, file public/index.php sẽ là file được chạy trước tiên. Sau đó, quá trình autoload, tạo Kernel, tạo Application, bootstrapping, base Service Provider, register base Middleware, register base path, environment... được thực hiện, và cuối cùng là dispatch request lên Router. Sau khi đi qua Router, request tiếp tục được đẩy vào Controller, trong đó sẽ xảy ra quá trình kiểm tra xem người dùng có được cho phép thực hiện hay không, và cuối cùng là response/redirect.
Điều này chỉ mô tả cách Laravel xử lý yêu cầu, còn các bước khác không liên quan đến Laravel sẽ không được đề cập.
Hỏi số 5: Service Provider và Service Container là gì?
Trả lời:
Service Provider là trung tâm của việc khởi tạo tất cả ứng dụng trong Laravel. Tất cả các service trong Laravel core sẽ được khởi tạo bởi Service Provider. Đây là một phần rất quan trọng trong Laravel.
Để đăng kí một Service Provider mới, bạn cần tạo một file Provider và sử dụng method register (phần lớn các Provider cũng có method boot). Trong method này, bạn sẽ sử dụng kĩ thuật binding trong Service Container.
Ví dụ:
namespace App\Providers;
use Chatwork;
use Illuminate\Support\ServiceProvider;
class ChatworkServiceProvider extends ServiceProvider
{
/**
* Register bindings in the container.
*
* @return void
*/
public function register()
{
$this->app->singleton('chatwork', function ($app) {
return new Chatwork($apiKey, $room);
});
}
}Sau đó, bạn sẽ thêm Service Provider này vào file config/app.php, nơi chứa danh sách tất cả các Provider của bạn.
Service Container là một công cụ mạnh mẽ để thực hiện binding và resolve các dependency. Ví dụ trên, chúng ta đã tự binding một class Redis với cái "redis". Sau khi binding, Service Provider sẽ tiến hành đăng kí. Sau đó, chúng ta chỉ cần gọi class Redis bằng cách sử dụng redis() hoặc app('redis').
Tóm lại, Service Container và Dependency Injection (DI) là hai khái niệm tương đối khác nhau. Service Container là một công cụ để thực hiện binding và resolve, trong khi DI là một kỹ thuật, một design pattern giúp loại bỏ sự phụ thuộc hard-code và làm cho ứng dụng dễ mở rộng và dễ bảo trì hơn.
Đây chỉ là một số câu hỏi mà nhà tuyển dụng thường hỏi trong phỏng vấn với vị trí Junior-Developer và đây cũng là quan điểm cá nhân của tôi. Còn nhiều phần khác như Notifications, Eloquent, Task Scheduling, Observe, Testing... bạn có thể tìm hiểu thêm trên tài liệu của Laravel.
Ở một mức độ cao hơn về kỹ thuật với Laravel, bạn sẽ tìm hiểu về các kỹ thuật như Design Pattern, Architecture, tối ưu hóa... và các câu hỏi "tại sao" thay vì chỉ là khái niệm và ví dụ đơn giản. Trong trường hợp đó, bạn sẽ phải tìm hiểu và tự mò mẫm.
Hy vọng rằng bạn đã tìm hiểu được nhiều điều thú vị về Laravel! Hãy để lại nhận xét nếu bạn có bất kỳ câu hỏi nào. Chúc bạn tìm hiểu thành công và hẹn gặp lại!
