Co sądzicie o Node.js? Ma szanse przebicia?
0
0
ScaleStack jest szybszy i jest napisany w C++, a nie jakimś Java Szicie. Inną fają alternatywą są serwery w Pythonie Twisted i Eventlet. Z resztą poważne firmy z branży od dawna mają wyskrobane własne serwery asynchroniczne. W Pythonie prosty serwer asynchroniczny piszesz w 5 minut.
0
jaroslaw patrzy napisał(a)
ScaleStack jest szybszy i jest napisany w C++, a nie jakimś Java Szicie. Inną fają alternatywą są serwery w Pythonie Twisted i Eventlet. Z resztą poważne firmy z branży od dawna mają wyskrobane własne serwery asynchroniczne. W Pythonie prosty serwer asynchroniczny piszesz w 5 minut.
No co ty powiesz? https://github.com/joyent/node
Najgłośniej krzycząca na temat niesłusznych banów osoba cierpi na rozdwojenie jaźni i co rusz bawi się w multikonta, cóż za ironia...
0
Używam dość mocno - w jednym z projektów świetnie się sprawdził jako API-server, za nim stoi Mongo i Redis.
0
Nie używam, ale raczej wybrałbym Netty lub Jetty, ze względu na znacznie lepszą wydajność i integrację z Liftem, który ma chyba najbardziej zaawansowane wsparcie dla odwrotnego Ajaxa (tj. Comet).
http://praxx.is/post/486034949/comet-with-bayeux-node-js-vs-jetty-and-cometd
0
nic nie zaznaczam, bo nie ma tutaj takiej opcji:
bawiłem się. uważam, że jest to fajna zabawka do napisania na szybko prowizorki serwera
7
Zdecydowanie ma szansę. Hype jest duży, a możliwości też. Atrakcyjność NodeJS-a jest logiczną konsekwencją zaledwie kilku jego cech.
Dwie, być może najważniejsze: szybka wielowątkowość i jednocześnie prostota.
Programowanie wielowątkowe jest bardzo, bardzo trudne. Debugowanie tego jest niedorzecznie trudne. Jeśli ktoś twierdzi, że pisanie wielowątkowych programów -- takich serio, serio wielowątkowych -- jest dla niego łatwe, to najprawdopodobniej ta osoba jest po prostu jeszcze cienka i ograniczona i nie napotkała jeszcze (przynajmniej świadomie) na wyzwania i problemy, które są niemal nieuniknione. Szczególnie w popularnych językach programowania.
Spróbujcie zarządzać wielowątkowością np. w Javie. Możliwości jest tyle, co mających nam pomóc klas -- dużo. Pule wątków, różne blokady, bezpieczne kontenery... A i tak są wyścigi, nieoczekiwane linie wykonania i w konsekwencji pady aplikacji, które ekstremalnie trudno zreplikować i zdebugować.
Wielowątkowość umożliwia sporą wydajność, ale ma też swoje ograniczenia. Spamowanie wątkami, np. dodawanie ich przy każdym połączeniu, potrafi samo w sobie zrobić taki narzut, że serwer i tak jest ubity. Tutaj pomagają różne ograniczenia i pule reużywalnych wątków, ale gdy trzeba o tym wszystkim pamiętać i konfigurować to ręcznie, to mamy i tak sporą złożoność.
W NodeJS-ie jest inaczej.
NodeJS czerpie z JavaScriptu. Siłą JavaScriptu jest pętla zdarzeń. Brak wątków. Znaczy się: brak widocznych dla użytkownika wątków (pomijam rzeczy typu WebWorkery, które zresztą NIE dzielą danych z innymi wątkami i są bezpieczne).
W NodeJS-ie mówimy: odczytaj dane z dysku funkcją f(), gdy dane będą gotowe to wywołaj funkcję x(), a póki co wywołaj jeszcze a(), g() i b(), przy czym g() też czeka na jakieś dane, więc gdy przyjdą, wywołaj y(). Teoretycznie, nie operujemy tu na żadnych wątkach. Mamy tylko normalny ciąg instrukcji synchronicznych (np. wywołań synchronicznych funkcji), poprzeplatany wywołaniami asynchronicznymi. Wywołania asynchroniczne to te, które robią coś synchronicznie, ale w tle zrobią coś jeszcze i nie wiadomo kiedy to się skończy -- gdy się jednak skończy, to mamy możliwość wywołania jakiejś funkcji, tj. wykonania jakiegoś kodu.
Asynchroniczne funkcje -- w powyższym przykładzie f() oraz g() -- wykonują lwią część swojej pracy "kiedyś tam" i "nie wiadomo kiedy skończą" (choć mamy możliwość wykonania kodu, kiedy ten koniec nastąpi). Ta praca dzieje się "w tle", może zostać -- i zostaje -- wykonana w innych wątkach.
Wątkami zarządza jednak Node, nie programista. Programista operuje sobie radośnie na callbackach. W samym JavaScripcie wątków nie ma i ciąg instrukcji wewnątrz funkcji NIGDY nie zostanie NICZYM przerwany. Z tego się zresztą bierze wada Node'a: jeśli wykonujemy ciąg synchronicznych obliczeń np. przez kilka sekund, to cały serwer wisi, bo obliczenia nigdy nie zostaną przerwane :-). Można je jednak podzielić na kilka mniejszych części i wykonywać asynchronicznie -- pomiędzy częściami serwer może odpowiedzieć na inne żądania.
Ogromnym uproszczeniem jest to, że całe zarządzanie wątkami spada na barki Node'a. Programiści aplikacji niczego więc nie mogą już skaszanić i (prawie) o nic nie muszą się martwić. No, może na początku wkurza ich ta cała asynchroniczność -- odrobinę niewygodna -- i konieczność "zagnieżdżania funkcji anonimowych". Ale konieczności takiej wcale nie ma! Da się pisać kod tak, by nigdy nie zagnieżdżać więcej niż dwóch wywołań funkcji anonimowych. W ostateczności, można pisać w JS-ie podobnie jak w Javie, tyle że z ukrytą wielowątkowością.
Funkcyjność JavaScriptu po prostu nam tutaj pomaga i możemy z niej skorzystać lub nie.
Są jednak języki, które z funkcyjnością i ukrytą wielowątkowością (lub współbieżnością -- przepraszam, ale tutaj używam tych terminów wymiennie) wymiatają lepiej niż JavaScript. Np. Erlang.
Ale Erlang ma potężną wadę. Nie jest JavaScriptem.
JavaScript to stosunkowo prosty język. Trudny jest dla kogoś raczej jedynie wtedy, gdy ta osoba próbuje używać go dokładnie jak Javy lub gdy używa kilku najsłabszych/najdziwniejszych stron JS-a. Reszta jest prosta i całkiem elegancka.
JavaScript ma tę zaletę, że jest mega-turbo-popularny. Istnieje od cholery koderów w JS-ie. Fakt, w większości żałośnie słabych, ale -- hej! -- w Nodzie współbieżność jest łatwa ;-).
Tak czy siak, istnieje bardzo duża społecznośc JS-owców. Oni w Nodzie poczują się jak ryba w wodzie. I będą pisali proste, wydajne serwery.
Z pomniejszych plusów mamy choćby to, że wreszcie istnieje popularna, wspierana przez społeczność platforma do pisania JavaScriptu po stronie serwera. Teraz można mieć np. ten sam kod walidacji formularzy po stronie serwera jak i klienta. Zauważcie, że aplikacje klienckie są coraz lepsze. Reużywając kod, można łatwo tworzyć rozwiązania, które domyślnie są praktycznie grubymi klientami, a jeśli użytkownik ma wyłączony JS (jak np. część użytkowników mobilnych), to możemy uciec się do... tego samego kodu hulającego po stronie serwera.
To całkiem spore plusy, ale najważniejsza jest ta współbieżna wydajność i JS-wa prostota.