Wyjaśnianie stylu rozwoju nodej programistom PHP w konkretnej sytuacji

Question

Jestem programistą aplikacji PHP, który zbudował kilka dużych projektów w PHP w/CodeIgniter. PHP zawsze wykonało zadanie, ale teraz pracuję nad nowym projektem, który buduję za pomocą javascript extjs4 framework po stronie klienta. Mam też pytania do doświadczonych programistów nodejs.

W moim najnowszym projekcie PHP żądanie logowania użytkownika wymagało mojego serwera do wykonania połączenia API z Facebookiem. Sposób, w jaki sobie z tym poradziłam, w celu poprawy skalowalności, był moim klientem, który składałby początkowe żądanie logowania, serwer przekazywałby żądanie do serwera zadań typu "gearman", a proces roboczy w tle przejmowałby zadanie i wykonywał wywołanie API. W międzyczasie serwer będzie odpowiadał klientowi, a następnie przeglądarka klienta rozpocznie odpytywanie serwera za pomocą AJAX, aby sprawdzić, czy zadanie zostało zakończone. (Och, i przekazałem wyniki wywołania API Facebook od pracownika do serwera aplikacji z memcached). Zrobiłem to, aby zwolnić serwery aplikacji, aby obsługiwać więcej współbieżnych żądań od użytkowników, ponieważ PHP jest blokowane, a wywołanie interfejsu API Facebooka zajmuje kilka sekund.

Moje pytanie brzmi: czy cały model serwerów aplikacji, serwer zadań dla kierowców i pracowników działających w tle ma sens dla rozwoju nodejs, ponieważ nodejs nie jest blokowany? Czy po prostu zaakceptowałbym żądanie ajaxowe od klienta, aby się zalogować, zadzwonić do API facebook'a z serwera aplikacji i czekać na jego odpowiedź (podczas obsługi zgłoszeń innych użytkowników, ponieważ nodejs nie jest blokowany), a następnie odpowiadać użytkownikowi?

Rozważam również wejście w rozwój nodejów, aby móc korzystać z niesamowitego środowiska heroku.

Answer 1

Krótka odpowiedź brzmi: tak, sposób w jaki zwykle to robisz w systemie węzłów jest dokładnie taki, jak to opisujesz.

Ponieważ węzeł nie jest blokowany, pętla zdarzeń nieustannie poszukuje możliwych do zrealizowania żądań. Oto przykład z użyciem node-facebook-client (jeden z wielu npm modułów zbudowanych do użytku z API Facebook)

console.log('start'); 

    client.graphCall(path, params, method)(function(result) { 
    // fires whenever request is completed 
    console.log('facebook returned'); 
    }); 

    console.log('end'); 

Wyjścia

start 
    end 
    facebook returned 

Jak można sobie wyobrazić, jest to w zasadzie co to całe zamieszanie jest o z węzła (plus jest naprawdę bardzo szybki). Powiedział, że jest to również miejsce, w którym krzywa uczenia się jest z węzłem - asynchroniczne wykonanie. If „koniec” musi pochodzić po „zwraca facebook”, wówczas trzeba by umieścić go w zwrotnego

console.log('start'); 

    client.graphCall(path, params, method)(function(result) { 
    // fires whenever request is completed 
    console.log('facebook returned'); 
    console.log('end'); 
    }); 

Dodatkowo, to elementarny zintegrować dynamicznych procesów potomnych do aplikacji, gdy jest to potrzebne, tym dodatkowe procesy węzłowe:. Od official docs dla child_process.fork:

var cp = require('child_process'); 

var n = cp.fork(__dirname + '/sub.js'); 

n.on('message', function(m) { 
    console.log('PARENT got message:', m); 
}); 

n.send({ hello: 'world' }); 

A potem skrypt dziecko, '' sub.js może wyglądać następująco:

process.on('message', function(m) { 
    console.log('CHILD got message:', m); 
}); 

process.send({ foo: 'bar' }); 

w dziecku przedmiot proces będzie miał send() Metoda i proces będą emitować obiekty za każdym razem, gdy otrzyma wiadomość na swoim kanale.