I believe Node.js najlepiej nadaje się do aplikacji w czasie rzeczywistym: Gier online, narzędzi współpracy, czatów lub czegokolwiek, gdzie jeden użytkownik (lub robot? czy czujnik?) sprawia, że aplikacja musi być natychmiast widoczna dla innych użytkowników, bez odświeżania strony.

Powinienem również wspomnieć, że Socket.IO w połączeniu z węzłem.js zmniejszy opóźnienia w czasie rzeczywistym nawet bardziej niż to jest możliwe przy długich sondażach. Socket.IO powróci do długich sondaży jako najgorszy scenariusz, a zamiast tego użyj gniazd sieciowych lub nawet Flasha, jeśli są dostępne.

Ale powinienem również wspomnieć, że prawie każda sytuacja, w której kod może się zablokować z powodu wątków, może być lepiej zaadresowana za pomocą węzła.js. Lub w każdej sytuacji, w której aplikacja musi być sterowana zdarzeniami.

Również Ryan Dahl powiedział w rozmowie, że kiedyś uczestniczyłem w tym węźle.js benchmarki ściśle konkurować Nginx dla regularnych starych żądań HTTP. Więc jeśli zbudujemy z Node.js, możemy służyć naszym normalnym zasobom całkiem skutecznie, a gdy potrzebujemy rzeczy związanych z wydarzeniami, jest gotowy, aby sobie z tym poradzić.

Plus to cały czas JavaScript. Lingua Franca na całym stosie.

Powody używania NodeJS:

• Uruchamia Javascript, więc możesz użyć tego samego języka na serwerze i kliencie, a nawet udostępnić jakiś kod między nimi(np. do walidacji formularza lub do renderowania widoków na obu końcach.)

• Jednowątkowy system sterowany zdarzeniami jest szybko nawet podczas obsługi wielu żądań naraz, a także proste, w porównaniu do tradycyjnego wielowątkowego Java lub ROR ramy.

• Stale rosnąca Pula Pakiety dostępne przez NPM , w tym biblioteki/moduły po stronie klienta i serwera, a także narzędzia wiersza poleceń do tworzenia stron internetowych. Większość z nich jest wygodnie hostowana na GitHubie, gdzie czasami możesz zgłosić problem i znaleźć go naprawionego w ciągu kilku godzin! Miło jest mieć wszystko pod jednym dachem, ze znormalizowanym raportowaniem problemów i łatwym rozwidlaniem.

• Stał się standardem defacto środowisko, w którym można uruchamiać Narzędzia związane z Javascripti inne narzędzia związane z Internetem, w tym biegacze zadań, Minifier, upiększacze, lintery, preprocesory, bundlery i procesory analityczne.

• Wydaje się całkiem odpowiedni do prototypowania, zwinnego rozwoju i szybkiej iteracji produktu .

Powody nie aby używać NodeJS:

• Uruchamia Javascript, który nie ma sprawdzania typu w czasie kompilacji. Dla dużych, złożonych krytyczne dla bezpieczeństwa systemy lub projekty obejmujące współpracę między różnymi organizacjami, język, który zachęca umowne interfejsy i zapewnia statyczne sprawdzanie typu, może zaoszczędzić trochę czasu debugowania (i eksplozje) na dłuższą metę. (Chociaż JVM utknął z null, więc proszę używać Haskell dla swoich reaktorów jądrowych.)

• Dodano do tego wiele pakietów w NPM jest trochę raw i nadal pod rapid rozwój. Niektóre biblioteki dla starszych frameworków przeszły dekadę testowania i poprawiania błędów i są teraz bardzo stabilne . Npmjs.org nie ma mechanizmu oceniania pakietów , co doprowadziło do rozrostu pakietów robiących mniej więcej to samo, z czego duży procent nie jest już utrzymywany.

• Zagnieżdżone callback piekło. (Oczywiście istnieje 20 różnych rozwiązań do tego...)

• Stale rosnąca Pula pakietów może sprawić, że jeden projekt NodeJS pojawi się radykalnie inaczej od następnego. Istnieje duża różnorodność implementacji ze względu na ogromną liczbę dostępnych opcji (np. Express/{82]}Sails.js/Meteor/Derby ). Czasami może to utrudnić nowemu deweloperowi przejście do projektu węzła. W przeciwieństwie do programisty Rails dołączającego do istniejącego projektu: powinien być w stanie dość szybko zapoznać się z aplikacją, ponieważ wszystkie aplikacje Rails są zachęcamy do stosowania podobnej struktury .

• Radzenie sobie z plikami może być trochę bolesne. Rzeczy, które są trywialne w innych językach, takie jak czytanie linii z pliku tekstowego, są wystarczająco dziwne, aby mieć do czynienia z węzłem.js że jest pytanie o StackOverflow z 80 + upvotes. Nie ma prostego sposobu odczytu jednego rekordu na raz z pliku CSV. Itd.

Kocham NodeJS, jest szybki, dziki i zabawny, ale obawiam się, że ma małe zainteresowanie w udowodnionej-poprawności. Miejmy nadzieję, że w końcu połączymy to, co najlepsze z obu światów. Chętnie zobaczę, co zastąpi Node w przyszłości... :)

Żeby było krótko:

Node.js doskonale nadaje się do aplikacji, które mają wiele jednoczesnych połączeń i każde żądanie wymaga tylko kilku cykli procesora, ponieważ pętla zdarzeń (z wszystkimi innymi klientami) jest blokowana podczas wykonywania funkcji.

Dobry artykuł o pętli zdarzeń w węźle.js jest mixu ' s tech blog: zrozumienie węzła.pętla zdarzeń js.

Mam jeden prawdziwy przykład, gdzie użyłem Node.js. Firma, w której pracuję ma jednego klienta, który chciał mieć prostą statyczną stronę HTML. Ta strona jest do sprzedaży jednego przedmiotu za pomocą PayPal{[2] } i klient chciał również mieć licznik, który pokazuje ilość sprzedanych przedmiotów. Klient oczekuje, że będzie miał ogromną liczbę odwiedzających tę stronę. Postanowiłem zrobić licznik za pomocą Node.js i Express.JS framework.

Węzeł.aplikacja js była prosta. Get ilość sprzedanych przedmiotów z bazy danych Redis , zwiększa licznik, gdy przedmiot jest sprzedawany i podaje wartość licznika użytkownikom za pośrednictwem API .

Kilka powodów, dla których zdecydowałem się użyć Node.js w tym przypadku

Jest bardzo lekki i szybki. Było ponad 200000 wizyt na tej stronie w ciągu trzech tygodni i minimalne zasoby serwera były w stanie obsłużyć to wszystko.
1. Licznik jest naprawdę łatwy do wykonania, aby być w czasie rzeczywistym.
2. węzeł.js był łatwa konfiguracja.
3. Istnieje wiele modułów dostępnych za darmo. Na przykład znalazłem węzeł.moduł js dla PayPal.

W tym przypadku Node.js był świetnym wyborem.

Najważniejsze powody, dla których warto rozpocząć kolejny projekt używając Node ...

Wszyscy najfajniejsi kolesie to lubią ... więc to musi być zabawne.
• możesz spędzać czas w chłodni i mieć wiele przygód węzłów, którymi możesz się chwalić.
Jeśli chodzi o koszty hostingu w chmurze, jesteś jednym z najlepszych dostawców hostingu.
• Been there done that with Rails
• nienawidzisz wdrożeń IIS
• twoja stara Praca IT staje się raczej nudna i żałujesz, że nie zaczynasz od nowa W górę.

Czego się spodziewać ...

• Będziesz czuć się bezpiecznie z Express bez wszystkich serwerów bloatware nigdy nie potrzebne.
Działa jak rakieta i dobrze się skaluje. Marzysz o tym. Zainstalowałeś go. The node package repo npmjs.org jest największym ekosystemem bibliotek open source na świecie.
• twój mózg zostanie wypaczony w Krainie zagnieżdżonych wywołań zwrotnych ...
• ... dopóki nie nauczysz się trzymać swojego obietnice .
• Sequelize i Passport to twoi nowi znajomi z API.
• debugowanie głównie kodu asynchronicznego otrzyma umm ... ciekawe .
• Czas, aby wszystkie Nody opanowałymaszynopis .

Kto go używa?

PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones]}
• Oto dlaczego przełączyli się na węzeł.

Nie ma to jak Srebrna kula. Wszystko wiąże się z pewnymi kosztami. To jest tak, jeśli jesz tłuste jedzenie, będziesz narażać swoje zdrowie i zdrowa żywność nie pochodzi z przyprawami, takimi jak tłuste jedzenie. Jest to indywidualny wybór, czy chcą zdrowia lub przypraw jak w ich żywności. Ten sam węzeł.js uważa się za użyte w konkretnym scenariuszu. Jeśli Twoja aplikacja nie pasuje do tego scenariusza, nie powinieneś go brać pod uwagę przy tworzeniu aplikacji. Po prostu kładę swoje myśli na to samo:

Kiedy używać Node.JS

1. Jeśli Twój kod po stronie serwera wymaga bardzo niewielu cykli procesora. W innym świecie robisz operację bez blokowania i nie masz ciężkiego algorytmu/zadania, które zużywa wiele cykli procesora.
2. Jeśli jesteś z zaplecza Javascript i wygodnie piszesz pojedynczy gwintowany kod, tak jak po stronie klienta JS.

Kiedy nie używać Node.JS

1. żądanie serwera zależy od dużego zużycia procesora algorytm/zadanie.

Rozważenie skalowalności z węzłem.JS

1. węzeł.Sam JS nie wykorzystuje całego rdzenia bazowego systemu i jest domyślnie jednowątkowy, musisz napisać logikę samodzielnie, aby wykorzystać procesor wielordzeniowy i uczynić go wielowątkowym.

Węzeł.Js Alternatywy

Istnieją inne opcje do wykorzystania w miejsce węzła.JS jednak Vert.x wydaje się być całkiem obiecujący i ma wiele dodatkowych funkcji jak polygot i lepsza skalowalność.

Kolejna świetna rzecz, o której chyba nikt nie wspomniał o Node.js to niesamowita społeczność, system zarządzania pakietami (npm) i ilość istniejących modułów, które możesz dołączyć, po prostu dołączając je do swojego pakietu.plik json.

Mój kawałek: nodejs jest świetny do tworzenia systemów czasu rzeczywistego, takich jak analityka, chat-apps, API, serwery reklamowe itp. Cholera, zrobiłem swoją pierwszą aplikację do czatu używając nodejs i socket.io poniżej 2 godzin i to również podczas egzaminu tydzień!

Edit

Minęło kilka lat, odkąd zacząłem używać nodejs i używałem go do tworzenia wielu różnych rzeczy, w tym statycznych serwerów plików, prostych analiz, aplikacji do czatu i wielu innych. To jest moje zdanie na temat Kiedy używać nodejs

Kiedy do użyj

Podczas tworzenia systemu, który kładzie nacisk na współbieżność i szybkość.

• Sockets tylko serwery takie jak chat apps, IRC apps, itp.
[15]}sieci społecznościowe, które kładą nacisk na zasoby czasu rzeczywistego, takie jak geolokalizacja, strumień wideo, strumień audio itp.
• obsługa małych fragmentów danych naprawdę szybko, jak analytics webapp.
• jako odsłanianie REST only api.

Kiedy nie używać

Its a very versatile webserver so you można go używać wszędzie tam, gdzie chcesz, ale prawdopodobnie nie w tych miejscach.

• proste blogi i statyczne strony.
• tak jak statyczny serwer plików.

Pamiętaj, że tylko się czepiam. W przypadku statycznych serwerów plików apache jest lepszy głównie dlatego, że jest powszechnie dostępny. Społeczność nodejs z biegiem lat stała się większa i bardziej dojrzała i można śmiało powiedzieć, że nodejs może być używany prawie wszędzie, jeśli masz własny wybór hostingu.

Może być używany gdzie

• aplikacje, które są silnie zależne od zdarzeń i są silnie powiązane we/wy
• aplikacje obsługujące dużą liczbę połączeń z innymi systemami
• aplikacje czasu rzeczywistego (Node.js został zaprojektowany od podstaw w czasie rzeczywistym i ma być łatwy do użycia.)
• aplikacje, które żonglują strumieniami informacji do i z innych źródeł
• aplikacje o dużym natężeniu ruchu
• aplikacje mobilne, które muszą rozmawiać z platform API & bazy danych, bez konieczności robienia dużej ilości danych analytics
• Tworzenie aplikacji sieciowych
• aplikacje, które muszą bardzo często rozmawiać z zapleczem

Na mobilnym froncie firmy prime-time polegały na Node.js dla swoich rozwiązań mobilnych. sprawdź dlaczego?

LinkedIn {[26] } jest wybitnym użytkownikiem. Ich cały stos mobilny jest zbudowany na węźle.js. Od uruchomienia 15 serwerów z 15 instancjami na każdej fizycznej maszynie do zaledwie 4 instancji – to wytrzyma dwa razy więcej!

EBay uruchomiony ql.io, język zapytań internetowych dla API HTTP, który wykorzystuje węzeł.js jako stos runtime. Byli w stanie dostroić zwykłą stację roboczą Ubuntu o jakości deweloperskiej do obsługi ponad 120 000 aktywnych połączeń na węzeł.proces js, przy czym każde połączenie pochłania około 2KB pamięci!

Walmart przeprojektował swoją aplikację mobilną, aby korzystać z Node.js i wypchnął swoje przetwarzanie JavaScript na serwer.

Czytaj więcej na: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

Node best for concurrent request handling -

Ok zgodziłem się, że możesz napisać swoje API w JavaScript, ale co, jeśli jestem ok z powyższym problemem. Czy masz inny powód, aby używać node dla REST API ?

Oto zaczyna się magia. Tak, mam inne powody, aby używać node dla naszych API.

Wróćmy do naszego tradycyjnego systemu rest API, który opiera się na blokowaniu operacji lub wątku. Załóżmy, że występują dwa równoległe żądania (r1 i r2), każde z nich wymaga operacji bazy danych. Więc w tradycyjnym systemie co się stanie:

1. Sposób oczekiwania: nasz serwer zaczyna obsługiwać r1 request i czeka na odpowiedź zapytania. po zakończeniu r1 serwer zaczyna obsługiwać r2 i robi to w ten sam sposób. Więc czekanie nie jest dobrym pomysłem, ponieważ nie mamy tyle czasu.

2. Threading Way: nasz serwer utworzy dwa wątki dla obu żądań r1 i r2 i będzie służył ich celowi po zapytaniu bazy danych, więc cool its fast.Ale jest to zużywające pamięć, ponieważ widać, że uruchomiliśmy dwa wątki również problem wzrasta, gdy oba żądania odpytywają te same dane, to musisz poradzić sobie z problemami typu impasu . Więc to lepsze niż czekanie, ale nadal są problemy.

Oto jak zrobi to node:

3. Nodeway: gdy to samo równoległe żądanie pojawi się w węźle, zarejestruje Zdarzenie z jego wywołaniem zwrotnym i nie będzie czekać na odpowiedź zapytania dla określonego request.So gdy pojawia się żądanie r1, wtedy pętla zdarzeń węzła (tak, w węźle znajduje się pętla zdarzeń, która służy do tego celu.) zarejestrować zdarzenie z jego funkcją callback i przejść do obsługi r2 żądanie i podobnie zarejestrować jego wydarzenie z oddzwanianiem. Za każdym razem, gdy jakiekolwiek zapytanie zakończy się, uruchamia odpowiednie zdarzenie i wykonuje wywołanie zwrotne do zakończenia bez przerwania.

Więc bez czekania, bez wątków , bez zużycia pamięci-tak jest to nodeway do obsługi rest API.

My Jeszcze jeden powód aby wybrać węzeł.js dla nowego projektu to:

BYĆ w stanie wykonać czysty rozwój oparty na chmurze

UżywamCloud9 IDE od jakiegoś czasu i teraz nie wyobrażam sobie bez niego, obejmuje on wszystkie cykle życia programistycznego. Wszystko, czego potrzebujesz, to przeglądarka i możesz kodować w dowolnym miejscu i czasie na dowolnym urządzeniu. Nie musisz sprawdzać kodu na jednym komputerze( jak w domu), a następnie kasować na innym komputerze(jak w miejscu pracy).

Oczywiście, że tam może IDE oparte na chmurze dla innych języków lub platform (cloud 9 IDE dodaje wsparcie dla innych języków, jak również), ale za pomocą Cloud 9 zrobić węzeł.js developement to dla mnie naprawdę wspaniałe doświadczenie.

Jeszcze jedną rzeczą, którą dostarcza node, jest możliwość tworzenia wielu instancji v8 węzła przy użyciu procesu potomnego node (childProcess.fork () każdy wymaga 10mb pamięci w locie, co nie wpływa na główny proces działający na serwerze. Odciążenie zadania w tle, które wymaga ogromnego obciążenia serwera, staje się dziecinnie proste i możemy je łatwo zabić w razie potrzeby.

Używam node dużo i w większości aplikacji, które budujemy, wymagają połączeń z serwerem w w tym samym czasie więc duży ruch sieciowy. Frameworków jak Express.js i Nowy Koajs (który usunął callback hell) sprawiły, że praca nad node jest jeszcze łatwiejsza.

Zakładanie azbestu longjohns...

Wczoraj mój tytuł z publikacjami Packt, Reactive Programming with JavaScript . To nie jest węzeł.js-centric title; wczesne rozdziały są przeznaczone do teorii, a później rozdziały ciężkie kodu obejmują praktykę. Ponieważ nie sądziłem, że byłoby właściwe, aby nie dać czytelnikom serwera www, węzła.JS by far oczywisty wybór. Sprawa została zamknięta, zanim jeszcze została otwarta.

I mogłem dać bardzo różowy widok mojego doświadczenia z węzłem.js. Zamiast tego byłem szczery o dobrych i złych punktach, które napotkałem.

Pozwolę sobie dodać kilka cytatów, które są tutaj istotne:

Uwaga: Węzeł.js i jego ekosystem są gorące -- wystarczająco gorące, aby cię spalić!

Kiedy byłem asystentem nauczyciela matematyki, jedną z nieoczywistych sugestii, które mi powiedziano, było nie mówienie uczniowi, że coś jest " łatwe."Powód był nieco z perspektywy czasu oczywiste: jeśli powiesz ludziom, że coś jest łatwe, ktoś, kto nie widzi rozwiązania, może skończyć się poczuciem (jeszcze bardziej) głupim, ponieważ nie tylko nie rozumie, jak rozwiązać problem, ale problem, który są zbyt głupi, aby zrozumieć, jest łatwy!

Istnieją Gotcha, które nie tylko denerwują ludzi pochodzących z Pythona / Django, które natychmiast przeładowuje źródło, jeśli cokolwiek zmienisz. Z Węzłem.js, domyślnym zachowaniem jest to, że jeśli dokonasz jednej zmiany, stara wersja jest aktywny do końca czasu lub do ręcznego zatrzymania i ponownego uruchomienia serwera. To niewłaściwe zachowanie nie tylko denerwuje Pythonistów, ale także irytuje rodzimy węzeł.użytkownicy js, którzy zapewniają różne obejścia. Pytanie StackOverflow " automatyczne przeładowanie plików w węźle.js " ma, w momencie pisania tego tekstu, ponad 200 upvotes i 19 odpowiedzi; edycja kieruje użytkownika do skryptu niani, node-supervisor, z homepage w {27]} http://tinyurl.com/reactjs-node-supervisor . to problem daje nowym użytkownikom świetną okazję, aby poczuć się głupio, ponieważ myśleli, że naprawili problem, ale stare, wadliwe zachowanie jest całkowicie niezmienione. I łatwo jest zapomnieć o odbiciu serwera; robiłem to wiele razy. A przesłanie, które chciałbym przekazać, brzmi: "Nie, Nie jesteś głupi, ponieważ takie zachowanie węzła.js ukąsił cię w plecy; chodzi tylko o to, że projektanci Node.js nie widział powodu, aby zapewnić odpowiednie zachowanie tutaj. Spróbuj sobie z tym poradzić, może trochę pomoc od node-Supervisora lub innego rozwiązania, ale proszę nie odchodź czując, że jesteś głupi. To nie Ty masz problem, problem jest w Node.domyślne zachowanie js."

Ta sekcja, po jakiejś debacie, została pozostawiona, właśnie dlatego, że nie chcę sprawiać wrażenia "to łatwe."I cut my hands wielokrotnie podczas coraz rzeczy do pracy, i nie chcę łagodzić trudności i ustawić cię, aby uwierzyć, że coraz węzeł.js i jego ekosystem, aby dobrze funkcjonować to prosta sprawa, a jeśli nie jest to dla Ciebie proste, nie wiesz, co robisz. Jeśli nie napotkasz nieprzyjemnych trudności przy użyciu Node.js, to wspaniale. Jeśli to zrobisz, mam nadzieję ,że nie odejdziesz czując: "jestem głupi-musi być ze mną coś nie tak."Nie jesteś głupi, jeśli doświadczasz nieprzyjemnych niespodzianek związanych z Node.js. To nie ty! To Node.js i jego ekosystem!

Wyrostek, którego tak naprawdę nie chciałem po powstaniu crescendo w ostatnich rozdziałach i konkluzjach mówi o tym, co udało mi się znaleźć w ekosystemie i zapewniło obejście dla kretyńskiego literalizmu: {]}

Inną bazą danych, która wydawała się idealnie pasować, a może być jeszcze możliwa do wykorzystania, jest implementacja po stronie serwera HTML5 key-value store. To podejście ma główną zaletę API, które większość dobrych programistów front-end dobrze rozumie. W tym przypadku jest to również API, które najbardziej nie jest tak dobrym front-endem deweloperzy rozumieją wystarczająco dobrze. Ale z pakietem node-localstorage, podczas gdy dostęp do składni słownika nie jest oferowany (chcesz użyć localStorage.setItem (klucz, wartość) lub localStorage.getItem (key), Nie localStorage [key]), zaimplementowana jest pełna semantyka localStorage, w tym domyślny kontyngent 5MB - dlaczego? czy Programiści JavaScript po stronie serwera muszą być chronieni przed sobą?

Dla możliwości bazy danych po stronie klienta, kontyngent 5MB na stronę internetową jest naprawdę hojny i przydatna ilość przestrzeni oddechowej, aby umożliwić programistom pracę z nim. Możesz ustawić znacznie niższy limit i nadal oferować programistom niezmierną poprawę w porównaniu z kulejeniem wraz z zarządzaniem plikami cookie. Limit 5 MB nie nadaje się bardzo szybko do przetwarzania po stronie klienta Big Data, ale istnieje naprawdę dość hojny dodatek, który pomysłowi programiści mogą wykorzystać do zrobienia wiele. Ale z drugiej strony, 5MB nie jest szczególnie dużą częścią większości dysków zakupionych ostatnio, co oznacza, że jeśli a strona nie zgadza się na to, co jest rozsądne wykorzystanie miejsca na dysku, lub jakaś strona jest po prostu hoggish, to naprawdę nie kosztuje dużo i nie grozi zawalonym dyskiem twardym, chyba że dysk twardy był już zbyt pełny. Może lepiej byłoby, gdyby równowaga była trochę mniejsza lub trochę większa, ale ogólnie jest to przyzwoite rozwiązanie, aby rozwiązać wewnętrzne napięcie w kontekście po stronie klienta.

Można jednak delikatnie zauważyć, że gdy piszesz kod dla Twojego serwera nie potrzebujesz żadnej dodatkowej ochrony przed uczynieniem bazy danych o rozmiarze przekraczającym dopuszczalny rozmiar 5MB. Większość programistów nie potrzebuje ani nie chce narzędzi działających jako niania i chroniących ich przed przechowywaniem więcej niż 5MB danych po stronie serwera. A kontyngent 5MB, który jest złotym balansem po stronie klienta, jest raczej trochę głupi na węźle.serwer js. (I, dla bazy danych dla wielu użytkowników, takich jak jest objęte w tym załączniku, można zauważyć, nieco boleśnie, że to nie 5MB na konto użytkownika, chyba że utworzysz oddzielną bazę danych na dysku dla każdego konta użytkownika; to jest 5MB dzielone między wszystkimi kontami użytkowników razem. To może być bolesne, jeśli będziesz wirusowy!) Dokumentacja stwierdza, że kontyngent można dostosować, ale wiadomość e-mail sprzed tygodnia do dewelopera z pytaniem, jak zmienić kontyngent, jest bez odpowiedzi, podobnie jak pytanie StackOverflow z pytaniem o to samo. Jedyna odpowiedź, jaką udało mi się znaleźć, znajduje się w źródle Github CoffeeScript, gdzie jest wymieniona jako opcjonalny drugi argument integer konstruktora. Jest to dość łatwe i można określić limit równy rozmiarowi dysku lub partycji. Ale poza przeniesieniem funkcji, która nie ma sensu, autor narzędzia całkowicie nie zastosował się do bardzo standardowej konwencji interpretowania 0 jako "nieograniczonej" dla zmiennej lub funkcji, gdzie liczba całkowita ma określić maksymalny limit dla niektórych zasobów. Najlepszą rzeczą do zrobienia z tym błędem jest prawdopodobnie określenie, że kontyngent jest Nieskończoność:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Zamiana dwóch komentarzy w kolejności:

Ludzie niepotrzebnie strzelali sobie w stopę, ciągle używając JavaScript jako całości, a część języka JavaScript była szanowanym językiem Douglasa Crockforda mówiąc w istocie: "JavaScript jako język ma naprawdę dobre części, a niektóre naprawdę złe części. Oto dobre części. Zapomnij, że jest tam coś jeszcze."Być może gorący węzeł.js ekosystem będzie rozwijać swoje własne " Douglas Crockford, "kto powie," węzeł.js ecosystem to kodowanie Dzikiego Zachodu, ale istnieje kilka prawdziwych klejnotów do znalezienia. Oto plan działania. Oto obszary, których należy unikać niemal za wszelką cenę. Oto obszary z jednymi z najbogatszych paydirt można znaleźć w dowolnym języku lub środowisku."

Może ktoś inny potraktuje te słowa jako wyzwanie i pójdzie za tropem Crockforda i napisze "dobre części" i / lub "lepsze części" dla Node.js i jego ekosystem. Kupiłbym kopię! Biorąc pod uwagę stopień entuzjazmu i godzin pracy nad wszystkimi projektami, może być uzasadnione w ciągu roku, dwóch lub trzech, Ostro złagodzenie wszelkich uwag na temat niedojrzałego ekosystemu poczynionych w czasie tego pisania. To naprawdę może mieć sens w ciągu pięciu lat, aby powiedzieć, " węzeł 2015.js ekosystem miał kilka pól minowych. Węzeł 2020.js ekosystem ma wiele rajów."

Jeśli Twoja aplikacja głównie łączy interfejsy API lub inne kanały io, daj lub weź interfejs użytkownika, węzeł.js może być uczciwym wyborem dla Ciebie, zwłaszcza jeśli chcesz wycisnąć największą skalowalność, lub jeśli twoim głównym językiem w życiu jest javascript (lub transpilery javascript w rodzaju). Jeśli budujesz mikroserwisy, node.js też jest w porządku. Węzeł.js nadaje się również do każdego projektu, który jest mały lub prosty.

Jego główną zaletą jest to, że pozwala front-endom wziąć odpowiedzialność za back-end rzeczy, a nie typowy podział. Innym uzasadnionym punktem sprzedaży jest to, czy Twoi pracownicy są zorientowani na javascript.

Poza pewnym punktem nie można jednak skalować kodu bez strasznych hacków wymuszających modułowość, czytelność i kontrolę przepływu. Niektórzy ludzie lubią te hacki, zwłaszcza pochodzące z kontekstu javascript sterowanego zdarzeniami, wydają się znajome lub wybaczalne.

W szczególności, gdy aplikacja musi wykonywać przepływy synchroniczne, zaczynasz krwawić z niedokończonych rozwiązań, które znacznie spowalniają twój proces rozwoju. Jeśli w aplikacji znajdują się części wymagające obliczeń, postępuj ostrożnie wybierając (tylko) węzeł.js. Maybe http://koajs.com / lub inne nowościjs lub napisał to.

Mogę podzielić się kilkoma punktami, gdzie i dlaczego używać node js.

1. w przypadku aplikacji w czasie rzeczywistym,takich jak czat, edycja współpracy, lepiej korzystamy z nodejs, ponieważ jest to baza zdarzeń, w której zdarzenia i dane wysyłane są do klientów z serwera.
2. proste i łatwe do zrozumienia, ponieważ jest to baza javascript, gdzie większość ludzi ma pomysł.
3. większość obecnych aplikacji internetowych idzie w kierunku angular js & backbone, z węzłem jest łatwy do interakcji z kodem po stronie klienta, ponieważ oba będą używać danych json.
4. wiele wtyczek dostępnych.

Wady: -

1. Node będzie obsługiwał większość baz danych, ale najlepszy jest mongodb, który nie będzie obsługiwał złożonych złączeń i innych.
2. Błędy Kompilacji...programista powinien obsługiwać każdy wyjątek inny mądry, jeśli jakakolwiek aplikacja accord błędu przestanie działać, gdzie ponownie musimy iść i uruchomić ją ręcznie lub za pomocą dowolnego Narzędzia automatyzacji.

Wniosek:- Nodejs najlepiej używać do prostego i rzeczywistego czasu aplikacje..jeśli masz bardzo dużą logikę biznesową i złożoną funkcjonalność lepiej nie powinieneś używać nodejs. Jeśli chcesz zbudować aplikację wraz z czatem i dowolną funkcją współpracy.. węzeł może być używany w określonych częściach i pozostanie powinien iść z technologią wygody.

1. Node jest świetny do szybkich prototypów, ale nigdy nie użyłbym go ponownie do niczego skomplikowanego. Spędziłem 20 lat rozwijając związek z kompilatorem i na pewno za nim tęsknię.

2. Node jest szczególnie bolesny dla zachowania kodu, którego nie odwiedziłeś przez jakiś czas. Informacje o typie i wykrywanie błędów w czasie kompilacji to dobre rzeczy. Po co to wszystko wyrzucać? Za co? I cholera, kiedy coś idzie na południe ślady stosu dość często całkowicie bezużyteczne.