Node.js: na czym polega sterowanie zdarzeniami w serwerze WWW?

Coraz popularniejszy framework I/O Node.js – implementacja engine'u V8 JavaScriptu po stronie serwera – może służyć do zbudowania serwera WWW sterowanego zdarzeniami. To coś zupełnie innego od tradycyjnych serwerów, takich jak Apache, które działają w oparciu o wątki.

Uruchamiając Apache deklarujemy ile wątków ma obsługiwać zapytania. Dany wątek jest zablokowany do czasu, aż obsłuży zapytanie i zwróci wynik.

Dodatkowo każdy wątek ma swoją kolejkę zapytań, które po kolei realizuje. Rodzi to pewne konsekwencje. Na przykład jeżeli jedno z zapytań będzie trwało 10 minut, cała kolejka zapytań do tego wątku będzie musiała czekać przynajmniej 10 minut.

Jest to skrajna nieefektywność, ponieważ w czasie gdy np. baza danych pobiera dane potrzebne do obsłużenia zapytania, wątek serwera mógłby obsługiwać kolejne zapytania i poinformować autora zapytania 10-minutowego, kiedy zostanie ono zrealizowane.

Tim Caswell w 102. odcinku podcastu Herding Code wyjaśnił przystępnie tę różnicę, stosując metaforę recepcji i jadłodajni.

Tradycyjny model na bazie wątków to recepcja: recepcjonista obsługuje pacjenta tak długo, aż zakończy jego obsługę. Ujmując to inaczej: jeżeli pacjent musi wypełnić formularz – robi to przy recepcjoniście. Jest on przez cały ten czas zablokowany przez pacjenta.

Również osoby ustawiające się w kolejce muszą czekać, aż pacjent skończy wypełniać dokumenty.

Aby skalować taki system, trzeba zwiększyć przestrzeń recepcji i dodać kolejne okienka.

W modelu sterowanym zdarzeniami sytuacja wyglądałaby zupełnie inaczej. Kiedy pacjent musi wypełnić formularze, dostaje je i opuszcza kolejkę. Siada w poczekalni i uzupełnia informacje. Kiedy jest gotowy wraca do recepcjonisty, aby złożyć je, albo zadać dodatkowe pytania.

Brak marnotrawstwa czasu recepcjonisty i oczekiwania pozostałych pacjentów sprawia, że taki system lepiej się skaluje.

Analogicznie wygląda sytuacja w wypadku jadłodajni. W tradycyjnych jadłodajniach podchodzi się do lady, zamawia obiad i stoi tam tak długo, aż zostanie on wydany. Gdy jadłodajnia jest zarządzana zdarzeniami, po zamówieniu i opłaceniu zamówienia, klient może usiąść przy stole i zostanie poinformowany, że może swoje danie już odebrać przez wywołanie jego nazwiska. W wielu językach takie wywołanie nazywa się wywołaniem zwrotnym (ang. callback function).

Najważniejsze jest to, że klient nie blokuje osoby przyjmującej zamówienia.

Node.js działa właśnie w ten sposób:

1. Wpisujesz w przeglądarkę adres pliku /about.html znajdującego sie na serwerze Node.js,

2. Serwer akceptuje zapytanie i wywołuje funkcję służącą do pobrania pliku z dysku,

3. Kiedy serwer czeka na plik, obsługuje następne zapytanie,

4. Kiedy serwer otrzyma plik, dodaje wywołanie zwrotne do kolejki zadań,

5. Serwer wywołuje funkcję, która spowoduje wyrenderowanie pliku about.html i wysłanie go do przeglądarki.

Tim zwraca uwagę również, że w przypadku wysoko skalowalnych serwerów liczą się nawet mikrosekundy, nawet jeżeli wczytanie pliku może wydawać się szybką operacją.

źródło: code.danyork.com

Podoba Ci się ten tekst? Powiedz o tym innym na Fb: lub na G+:

publikuj:

wydrukuj

21 skomentuj »

Komentarze

#1 Magik 2011-01-26 13:56:57 0
Serwer Lighttpd jest akurat sterowany zdarzeniami, nginx zresztą również, więc Node.js to znowu nie jest taka nowość.
IP: 157.25.200.[...] Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 ThunderBrowse/3.3.4
#2 vincent 2011-01-26 14:07:27 0
2. Serwer akceptuje zapytanie i wywołuje funkcję służącą do pobrania pliku z dysku,

- ta czynność odbywa się w przestrzeni kosmicznej

3. Kiedy serwer czeka na plik, obsługuje następne zapytanie,

- przenosi się do innego wymiaru

4. Kiedy serwer otrzyma plik, dodaje wywołanie zwrotne do kolejki zadań,

- wraca do tradycyjnej jadłodajni
IP: 87.207.249.[...] Mozilla/5.0 (X11; U; Linux x86_64; pl-PL; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13
#3 Wszerad 2011-01-26 14:31:22 0
Od paru dni piszę stronę pod node.js i bardzo mi się podoba, wszystko działa bardzo szybko, czasem jak muszę coś przepisać z kodu strony na serwer (np. weryfikacja danych) to mam uproszczone zadanie i najważniejsze, że cała aplikacja internetowa jest pisana w JS. Nie wiem jak to się sprawdzi w warunkach bojowych ale jestem dobrej myśli.
IP: 213.17.128.[...] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110125 Firefox/4.0b10pre
#4 Magik 2011-01-26 15:34:32 0
No ładnie, najpierw piszą: "To coś zupełnie innego od tradycyjnych serwerów, takich jak Apache czy Lighttpd", a jak pokazać błąd w artykule, to poprawiają to po cichu i to wtedy ja wychodzę na piszącego komentarz od czapy.
IP: 157.25.200.[...] Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 ThunderBrowse/3.3.4
#5 mapi 2011-01-28 16:56:27 0
Lighttpd, Ngix, asynchroniczność w Servlet 3.0, a autorowi wydaje się że odkrył Amerykę...
IP: 194.149.230.[...] Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
#6 baglad10r aligato01r 2011-03-10 20:12:45 0
czytam sobie źródła node.js do kolacji i widze wiele pożytecznych sztuczek, wczesniej czytałem źródła Apache 1.x, Apache 2.x, Lighttpd, Nginx i podtrzymuję dalej hipotezę, że dobrze napisane jest w node.js I/O, lepiej nizeli w pozostalych, w kazdym badz razie widac magiczny dotyk googla w kodzie i to lubie ... cieszcie sie i radujcie a JavaScript wam w tym pomoze. EHLO
IP: 95.108.81.[...] Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
#7 Jacek Olszak 2012-01-11 22:52:56 1
Myślę, że główną zaletą node.js jest to, że tak szybko powstają dla tej technologii kolejne biblioteki do robienia wszelkiego typu operacji w sposób nieblokujący. Dzięki temu można pisać kod, który rzeczywiście na nic nie czeka. Weźmy np. taką Javę (defacto mój ulubiony język) - owszem - mamy tu od dawna NIO, mamy frameworki do pisania serwerów/klientów sterowanych zdarzeniami jak Mina lub Netty, a jednak ilość bibliotek/narzędzi nie robiących blokowania jest naprawdę mało (chociażby brak jest jakiegoś stabilnego asynchronicznego sterownika do relacyjnej bazy danych). Myślę, że akurat jeśli chodzi Javę to niestety klasy anonimowe stosowane w tym języku nie są aż tak "sexy" jak funkcje z JavaScript :) Dlatego wykorzystywanie callbacków na taką skalę jak w Node może skutecznie obrzydzić życie programistom :)
IP: 85.222.32.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#8 slawek22 2012-01-12 02:51:41 0
>Lighttpd, Ngix, asynchroniczność w Servlet 3.0, a autorowi wydaje się że

>odkrył Amerykę...

Bo być może odkrył. Model OOP JavaScript (można by na to zacząć mówić Ecma, żeby ludzie nie mylili z Java) został przygotowany typowo pod programowanie oparte na event'ach. Na dzień dzisiejszy ani Java, ani C++ ani praktycznie nic innego się do tego nie nadaje.

Można powiedzieć że w założeniach to coś podobnego do Erlang.

Wątki i procesy to coś co się może sprawdzać na desktopie, jeśli chodzi o sieć to są zbyt niewydajne, bardzo trudne w implementacji i przestarzałe. Podobnie jak wszystkie języki oparte na C (w tym Java, Python, PHP i inne wynalazki).

Z tym, że są 2 problemy bo rozwiązania przestarzałe mają jakieś 15-40 lat rozwoju za sobą, a jak ktoś używa rozwiązanie nowoczesnego to i tak w większości przypadków wydaje mu się, że pisze w przestarzałej Javie. W takim wypadku to lepiej zostać przy sprawdzonych rozwiązaniach i sobie darować bo powstanie spagetti które i tak będzie trzeba wyrzucić (tak jak ostatnio kiedy wszyscy mi chcieli udowodnić jaki JS to zły język bo kod i założenia wyglądające jak żywcem przeniesione z Javy powodowały jedynie problemy albo nie działały wcale).

No i w czasach kiedy serwer z 64GB ram można mieć za pareset euro/miesiąc to nie wiadomo czy cała ta asynchroniczność jest tak na prawdę potrzebna. I tak główny problem to bazy SQL które nie nadążają przy praktycznie każdym większym ruchu, nie można nawet bez zastopowania aplikacji wykonać kopii bezpieczeństwa a kilkusekundowe lock-i które się zdarzają położą każdą aplikację niezależnie od backendu web.

Na pewno robienie z node.js serwera plików to totalna głupota bo nawet apache można skonfigurować tak, żeby w takim wypadku działał wydajnie. Tak na prawdę całe dane powinny dodatkowo znajdować się w jakimś storage K/V O(1) i co jakiś czas być zapisywane w backendzie SQL, przy takiej separacji można już i obsługiwać duży ruch i robić backupy.

Kiedy się zmieni ślamazarny SQL na coś nieblokującego - dopiero wtedy można zauważyć że backend web jest zbyt wolny, inaczej to do kilku maszyn bazodanowych można podczepić jednego lighty albo nawet apache na prefork i nie będzie problemu.

Oczywiście przy nowoczesnym podejściu na jakikolwiek ACID w ogóle nie ma szans. No ale na pewno możnaby postawić coś co przy apache/mysql wymagałoby kilkudziesięciu serwerów - na jednej maszynie.

>chociażby brak jest jakiegoś stabilnego asynchronicznego sterownika do

>relacyjnej bazy danych

Pliki można czytać asynchronicznie bo ich odczyt nie powoduje stworzenia wątku/procesu przez OS. Z założenia relacyjne bazy danych są blokujące i synchroniczne (ACID), do tego każda operacja jest wykonywana w oddzielnym procesie/wątku... więc pisanie asynchronicznego drivera nie ma raczej zbyt dużo sensu. Albo bardzo szybkie storage K/V + zapominasz o jakiejkolwiek spójności danych ale można takie coś oprogramować tak, żeby działało asynchronicznie (i na pewno nie mongo, które zawiera wady i mysql i rozwiązania K/V przy braku zalet + jest koszmarnie wolne)... albo SQL którego skalować się nie da, ale się nie martwisz o dane.
IP: 83.27.69.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#9 Jacek Olszak^® 2012-01-12 20:02:26 0
@slawek22

> Z założenia relacyjne bazy danych są blokujące i synchroniczne (ACID), do

> tego każda operacja jest wykonywana w oddzielnym procesie/wątku... więc

> pisanie asynchronicznego drivera nie ma raczej zbyt dużo sensu.

Sławek - to prawda, że baza danych sama tworzy procesy/wątki dla każdego połączenia (sesji). Jednak to nie znaczy, że klient (w tym wypadku serwer w node.js) musi czekać i zajmować pamięć RAM (np. na stos wątku) oraz spowalniać niepotrzebnie maszynę (co przy liczbie wątków/procesów >10k może mieć spory wpływ na czas przełączania kontekstu). Jest to szczególnie przydatne gdyby wykorzystać architekturę Master-Slave. Slave'y są kopiami mastera i służą tylko do odczytu więc nie potrzebujesz tutaj całej maszynerii transakcji w swoim kodzie.
IP: 85.222.32.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#10 Jacek Olszak^® 2012-01-12 20:11:37 0
@slawek22: Ponadto nikt nie broni stworzyć komuś bazy relacyjnej, która będzie lepiej wykorzystywać wątki np. czekając na dysk baza może oddawać wątek do puli. Literka I z ACID nie musi oznaczać, że każdy użytkownik jest obsługiwany przez dedykowany dla niego wątek (proces). Sposób implementacji może być dowolny, byle zapewnił izolację.
IP: 85.222.32.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#11 slawek22 2012-01-12 20:46:05 0
Wiesz ale to chodzi trochę o coś innego...

przypuśćmy, że rozwiązano to w ten sposób i do obsługi bazy przeznaczono 100 wątków + zaimplementowano kolejkę. Prędzej czy później wszystkie te wątki zostaną zawłaszczone przez długotrwałe operacje, i coś co w teorii powinno trwać kilka milisekund będzie czekać w kolejce w nieskończoność. Plus to już nie będzie ACID. Po UPDATE będziesz dalej dostawał "przeterminowane" dane bo operacje będą czekać w kolejce na wykonanie.

No dobra można zrobić typową bazę ACID bez wątków, z callbackami, lecz i tak będziesz musiał czekać na odczyt bo w środku będzie pełna blokujących operacji. Zapuścisz update i od tej chwili na callback każdego odczytu będziesz musiał poczekać na przykład 15 minut. Tzn. to nie ma sensu.

W rozwiązaniu typowo asynchronicznym jedną z głównych zalet jest to, że możesz wykonywać w tle bardzo duże ilości długotrwałych operacji a operacje krótkotrwałe są wykonywane natychmiast. Przy asynchronicznym ACID każda operacja będzie czekała tak długo jak wszystkie operacje zapisu obecnie wykonywane + X.

Nie tylko literka I ale wszystkie odpadają. Taki scenariusz.

Dodaj +1 do każdego wiersza w bazie

Pobierz wartość wiersza X

Pomnóż wiersz X*2

Musisz zablokować wszystkie wiersze w tabeli na czas wykonywania pierwszej operacji. Jak tego nie zrobisz to będziesz miał losowe dane w tabeli i wszystkie literki z ACID polecą jeśli zrobisz - masz bazę tak samo kiepską jak rozwiązanie synchroniczne. Nie zrobisz asynchronicznego ACID, znaczy zrobisz, ale nie ma sensu bo lepiej niż synchroniczne nie będzie to działać.
IP: 83.27.69.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#12 slawek22 2012-01-12 20:51:34 0
Jeszcze co do SQL Master/Slave? Korzystałeś? Jak dla mnie to zbyt skomplikowane... a problemów zbyt wiele nie rozwiązuje... i tak musisz czekać na zapis do Slave + dostosowywać kwerendy. Bazy się lubią rozsynchronizować przez co możesz mieć wiele trudnych do wykrycia błędów (możesz mieć wiele problemów z Order By, limit, rand, offset, etc.)
IP: 83.4.102.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#13 Jacek Olszak^® 2012-01-12 22:20:04 0
Sławku, chyba nie do końca rozumiem co masz na myśli. Pisząc o blokujących operacjach masz na myśli implicit locki, muteksy i inne ustrojstwa ? Bo przecież współczesne relacyjne bazy danych już ich nie używają korzystając np. z MVCC, tzn. odczyt nie blokuje zapisu, podobnie jak zapis nie blokuje odczytu. Dlatego nawet jak zapuścisz długotrwałą operację modyfikującą dane to zapytania czytające rekordy z tej tabeli i tak się uruchomią równolegle (każda transakcja widzi tylko te dane z momentu jej rozpoczęcia).

Piszesz również o tym, że nie blokując wszystkich wierszy tabeli można utracić ACID. Owszem - mogą pojawić się problemy, ale blokowanie wierszy explicite jest tylko jednym ze sposobów. Można przecież użyć optimistic locking przy użyciu kolumny wersji na przykład. Nie jest to rozwiązanie idealne, ale w sam raz do użycia w aplikacji www. Z tym ACID to myśle, że ociutenkę przesadzasz - obecnie rozwijam oprogramowanie dla banków służące do obsługi transakcji i my właśnie używamy optymistycznego blokowania.

Swego czasu pracowałem przy serwisie z dużym obciążeniem. Nie mieliśmy w ani jednym miejscu kodu robiącego blokady za pomocą polecenia Lock lub select for update. Wykorzystywaliśmy też architekturę Master-Slave. Owszem, jest to utrudnienie dla programisty (trzeba jawnie wskazywać, który kod uruchamia się na masterze, a który na slejwach). Są niekiedy duże lagi replikacyjne, przez co dane są mocno przestarzałe na slejwach itp. Ale suma sumarum klient i tak jest zadowolony bo strona ciągle działa (jakoś :)).
IP: 85.222.32.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#14 slawek22 2012-01-12 22:35:15 0
Jaka baza danych? Ogólnie to tak, mysql przy inno (podobno MVCC) masz lock na wszystkie rekordy jeśli robisz backup albo je uaktualniasz. To już zależy read albo write lock.

Nie mogę włączyć czegoś co będzie korzystało z starej "wersji" tabeli dopóki dane będą uaktualniane... nie mogę nawet zrobić backupu który nie będzie spójny (dzięki czemu uniknąłbym blokowania). Czy może się mylę?

>kodu robiącego blokady za pomocą polecenia Lock

My też nie mamy.

> i my właśnie używamy optymistycznego blokowania

Jeśli tak to dane mogą być niespójne. Akurat w papierach Oracle'a piszą, żeby tego nie używać SZCZEGÓLNIE do operacji finansowych :)

http://orafaq.com/papers/locking.pdf
IP: 83.4.102.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#15 Jacek Olszak^® 2012-01-12 23:18:54 0
Używam Oracle i PostgreSQL. W obu przypadkach można wyciągać dane z bazy gdy te zostały zmodyfikowane przez inną transakcję ale transakcja modyfikująca dane jeszcze trwa (czyli modyfikacja przez inną transakcję nie ustawia read locka).

Mówisz, że optymistyczne blokowanie z użyciem kolumny wersji powoduje, że dane są niespójne ? Udowodnij :)
IP: 85.222.32.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#16 slawek22 2012-01-13 03:15:24 0
To bardzo proste. 2 transakcje wykonują się w tym samym czasie, nie masz LOCKs:

TA: odczyt wartości pola

TB: odczyt wartości pola

TA: pole+5

TB: pole+3

TB: zapis

TA: zapis

Przy MVCC transakcje są izolowane, ale bez lock obie zobaczą tą samą wartość, więc będziesz miał błąd przy dodawaniu.

Zamiast +8 dostajesz +5, albo +3. Zapuść sobie 10000 razy

UPDATE x SET y=y+5

w pętli i się przekonasz, że y nie zwiększy się o 100000 tylko trochę mniej przy MVCC :)

Żeby to działało jedna transakcja musi zaczekać na koniec drugiej, zanim zacznie czytać. Oczywiście pojedyncze transakcje będą poprawne (i atomowe), jeśli wykonasz więcej niż jedną w jednym momencie to dalej będą atomowe, dane dalej będą spójne, ale poprawne już nie.

Słyszałeś o shared exclusive?

http://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock
IP: 83.4.102.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#17 Jacek Olszak^® 2012-01-13 10:12:47 0
Sławek, ale chyba się ze nie zrozumieliśmy :) Optymistyczne blokowanie z użyciem kolumny wersji polega zupełnie na czym innym. Po pierwsze musisz mieć pole wersji (tudzież daty modyfikacji). Po drugie przy uruchamianiu UPDATE musisz dodać warunek gdzie umieścisz "version=wersja, ktora odczytales z transakcji". W Twoim przykładzie:

UPDATE x SET y = y + 5 WHERE version=z

W sytuacji gdy inna transakcja zmodyfikuje ten rekord to UPDATE zwroci zero wierszy zmodyfikowanych. To sygnal dla aplikacji ze inna transakcja zmodyfikowala rekord i nalezy na przykład cala transakcje wykonac od nowa.
IP: 62.181.161.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#18 slawek22 2012-01-13 15:45:49 0
Jeśli version masz na poziomie zapytania SQL a nie na poziomie bazy danych - to dalej nic nie daje... będziesz narażony na ten sam oryginalnie występujący problem. Jeśli oczywiście kwerenda będzie nieblokująca.
IP: 83.4.102.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#19 Jacek Olszak^® 2012-01-13 16:30:45 0
Blokowanie owszem nastąpi ale tylko w momencie uruchomienia drugiej operacji modyfikacji (tzn UPDATE drugiej transakcji będzie czekał na zakończenie pierwszej transakcji także wykonującej UPDATE na tym samym rekordzie). Nie będzie to jednak blokować wszelkich transakcji robiących tylko odczyt tego rekordu.

P.S. Już chyba trochę zboczyliśmy z tematu. Może lepiej będzie zakończyć tą dyskusję albo przenieść ją w inne miejsce ;)
IP: 62.181.161.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#20 slawek22 2012-01-13 19:35:38 0
Czy ja wiem, to bardzo ważna kwestia dla użytkowników node.js którzy będą chcieli w swoich projektach używać bazy SQL-owej co będzie w niektórych przypadkach całkowitym błędem ponieważ zniweluje wszystkie profity wynikające z użycia node.

Co do blokowania to fakt, teraz rozumiem koncepcję :) Po prostu odczyt przy UPDATE, które jest blokujące będzie potraktowany jako część operacji zapisu co zapobiegnie uszkodzeniu danych. Czyli precyzyjnie - odczyty przy SELECT są nieblokujące a przy UPDATE tak.

Poza tym na pewno każdy tutaj chce poznać trochę informacji o blokowaniu skoro mowa o rozwiązaniach asynchronicznych :)
IP: 83.4.102.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
#21 Jigga 2012-02-23 00:52:39 0
Cały ten node.js to totalny nonsens. Nie ma żadnej przewagi nad ASP.NET (MVC) a idiotyczny język i brak środowkiska IDE z prawdziwego zdarzenia. Ktoś na zagranicznym blogu ładnie podsumował node.js.
IP: 46.151.136.[...] Opera/9.80 (Windows NT 6.1; U; pl) Presto/2.10.229 Version/11.61

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.