2016-03-21 18 views
16

Với Guzzle, lời hứa có cung cấp bất kỳ tiện ích thực sự nào không? Có vẻ như bạn phải chờ cuộc gọi(). Các mã sau đây (từ các tài liệu) dường như không làm gì cả bởi chính nó:Điểm mấu chốt của Guzzle async hứa hẹn là gì?

$promise = $client->requestAsync('GET', 'http://httpbin.org/get'); 
$promise->then(
    function (ResponseInterface $res) { 
     echo $res->getStatusCode() . "\n"; 
    }, 
    function (RequestException $e) { 
     echo $e->getMessage() . "\n"; 
     echo $e->getRequest()->getMethod(); 
    } 
); 

Nếu bạn phải gọi $ promise-> chờ() để thực hiện yêu cầu, quan điểm của một lời hứa là gì? Điều này thực sự khác biệt như thế nào:

$request = new Request('GET', 'http://httpbin.org/get'); 
$response = $client->send($request); 

if ($response 

Tốt nhất tôi có thể nói, đó là cách tiếp cận thuận tiện để xác định yêu cầu gọi lại thành công và thất bại. Ngay cả phần doc trên thực hiện nhiều yêu cầu có mã dưới đây, xuất hiện để chặn và thực hiện tất cả các yêu cầu ... có lẽ tại cùng một thời điểm "". Đây có phải là tất cả những gì tôi mong đợi không?

// Wait on all of the requests to complete. 
$results = Promise\unwrap($promises); 
+1

Là async chính xác đồng nghĩa với xử lý trì hoãn? –

+0

Câu hỏi hay và có thể không. Thực sự tôi bối rối hơn bởi phần lời hứa của nó. – originalbryan

+0

Tôi không tin rằng PHP có khả năng xử lý sự kiện thực sự không đồng bộ (chưa), do đó cuộc gọi đến 'wait()'.Vì vậy, có thể có một số sự thật rằng một số lợi ích bạn thấy trong Javascript không hiển nhiên trong phiên bản PHP của nó (chưa), nhưng mục đích của một lời hứa là bạn có thể truyền xung quanh một giao diện "chỉ đọc" vào trong trì hoãn mà không thể được giải quyết thông qua giao diện đó. Có lẽ đây là khả năng tương thích ngược (hiện tại). –

Trả lời

8

tôi sẽ ra ở cánh một ở đây, nhưng từ những gì tôi đã đọc ...

Trong khi PHP không thể làm chế biến không đồng bộ, bạn có thể mở nhiều suối và đối phó với đầu vào của họ mà không bị chặn. Vì vậy, trong ví dụ của bạn với một kết nối duy nhất, có, không có điểm/lợi ích.

Nhưng giả sử bạn muốn tải lên 5 tài nguyên. Sử dụng các phương thức async có thể cho phép các tài nguyên này tải về cơ bản song song - chứ không phải chỉ bắt đầu từ tài nguyên thứ hai khi tải xuống lần đầu tiên.

Và Guzzle cung cấp các cách xử lý các trường hợp sử dụng như "sau khi tất cả đều được nạp đúng ..." hoặc "sau khi tất cả đều được tải hoặc không thành công ...".

Vì vậy, tôi nghĩ rằng nó sẽ cho phép xử lý nhanh hơn khi xử lý nhiều yêu cầu có thể xảy ra đồng thời.

1

Đồng bộ yêu cầu một chút suy nghĩ ngược lại. Đây là một kịch bản có thể phát sinh có thể hữu ích: Với một API (http://ipsum.org/), bạn được yêu cầu lấy lại danh sách dữ liệu (theo id) cho tuyến đường của bạn (hoặc tập lệnh) - Nếu bạn thực hiện nó theo thủ tục , bạn sẽ phải lặp qua từng yêu cầu và chờ cho đến khi tất cả trở lại.

Với lời hứa Guzzle, bạn có thể "chuẩn bị" cho phản hồi và sau đó khi trả lời - bạn có thể xử lý. Ưu điểm của điều này là thay vì N yêu cầu x T thời gian yêu cầu để thực thi kịch bản của bạn, độ trễ giờ là CEIL (thời gian đáp ứng chậm nhất của tất cả các phản hồi nhận được) khi bạn "chờ" cho TẤT CẢ các phản hồi quay lại nhưng chúng được gửi song song thay thế.

Nói cách khác, bạn đang gửi yêu cầu song song thay vì nối tiếp để bạn đợi phản hồi quay lại HOẶC bạn có thể thực hiện cuộc gọi curl trước, sau đó thực hiện thiết lập để "ok trong khi tôi đợi trở lại, hãy để tôi chuẩn bị phản hồi ".

Phần sau sẽ yêu cầu một số chuyển dịch cơ cấu vì chúng tôi đã quen "tìm nạp, đợi, sau đó trả lời lại, chúng tôi có thể hoạt động theo câu trả lời"

Các vấn đề liên quan