Jak zdecydować, kiedy używać Node.js?

Jestem nowy w tego typu rzeczach, ale ostatnio dużo słyszałem o tym, jak dobry jest Node.js. Biorąc pod uwagę, jak bardzo lubię pracować z jQuery i JavaScript w ogóle, nie mogę przestać się zastanawiać, jak zdecydować, kiedy użyć Node.js. Aplikacja internetowa, o której myślę, przypomina Bitly - pobiera trochę zawartości, archiwizuje ją.

Z całej pracy domowej, którą wykonałem w ciągu ostatnich kilku dni, uzyskałem następujące informacje. Node.js

• to narzędzie wiersza polecenia, które może być uruchomione jako zwykły serwer WWW i umożliwia uruchamianie programów JavaScript
• wykorzystuje świetny silnik JavaScript V8
• jest bardzo dobry, gdy musisz zrobić kilka rzeczy jednocześnie
• jest oparty na zdarzeniach, więc wszystkie wspaniałe rzeczy podobne do Ajaxa można wykonać po stronie serwera
• pozwala nam współdzielić kod między przeglądarką a backendem
• pozwala nam rozmawiać z MySQL

Niektóre źródła, z którymi się spotkałem to:

• Nurkowanie w Node.js - wprowadzenie i instalacja
• Zrozumienie NodeJS
• Węzeł według przykładu ( Archive.is )
• Stwórzmy aplikację internetową: NodePad

Biorąc pod uwagę, że Node.js może być uruchamiany niemal natychmiast po wyjęciu z pudełka w instancjach EC2 Amazon , staram się zrozumieć, jakiego rodzaju problemy wymagają Node.js, a nie jakikolwiek z potężnych królów, takich jak PHP , Python i Ruby . Rozumiem, że tak naprawdę zależy to od specjalistycznej znajomości języka, ale moje pytanie należy bardziej do ogólnej kategorii: Kiedy stosować określone ramy i do jakiego rodzaju problemów jest szczególnie odpowiedni?

Świetnie się spisałeś, podsumowując, co jest niesamowite w Node.js. Mam wrażenie, że Node.js jest szczególnie odpowiedni dla aplikacji, w których chcesz utrzymywać stałe połączenie z przeglądarki z powrotem do serwera. Korzystanie z techniki znanej jako „długie odpytywanie” , możesz napisać aplikację, która wysyła aktualizacje do użytkownika w czasie rzeczywistym. Długie sondowanie wielu gigantów internetowych, takich jak Ruby on Rails lub Django , spowodowałoby ogromne obciążenie serwera, ponieważ każdy aktywny klient zjada jeden proces serwera. Ta sytuacja stanowi atak tarpitowy . Gdy używasz czegoś takiego jak Node.js, serwer nie musi utrzymywać osobnych wątków dla każdego otwartego połączenia.

Oznacza to, że w Node.js możesz utworzyć opartą na przeglądarce aplikację czatu, która prawie nie potrzebuje zasobów systemowych do obsługi wielu klientów. Za każdym razem, gdy chcesz przeprowadzić tego rodzaju długie odpytywanie, Node.js jest świetną opcją.

Warto wspomnieć, że zarówno Ruby, jak i Python mają narzędzia do tego typu rzeczy ( eventmachine i twisted ), ale Node.js robi to wyjątkowo dobrze i od podstaw. JavaScript jest wyjątkowo dobrze dostosowany do modelu współbieżności opartego na wywołaniu zwrotnym i wyróżnia się tutaj. Również możliwość serializacji i deserializacji z JSON rodzimym zarówno dla klienta, jak i serwera jest całkiem sprytna.

Z niecierpliwością czekam na przeczytanie innych odpowiedzi tutaj. To fantastyczne pytanie.

Warto zauważyć, że Node.js jest również świetny w sytuacjach, w których będziesz ponownie wykorzystywać dużo kodu w przerwie między klientem a serwerem. Ramy Meteor sprawiają, że jest to naprawdę łatwe, a wielu ludzi sugeruje, że może to być przyszłość tworzenia stron internetowych. Mogę powiedzieć z doświadczenia, że ​​pisanie kodu w Meteor jest świetną zabawą, a duża część tego poświęca mniej czasu na zastanawianie się, jak zrestrukturyzować swoje dane, więc kod działający w przeglądarce może łatwo manipuluj nim i przekaż go z powrotem.

Oto artykuł na temat piramidy i długiego odpytywania, który okazuje się bardzo łatwy do skonfigurowania z niewielką pomocą gevent: Kolko_i_Krzyzyk i Długie odpytywanie z piramidą .

Wierzę, że Node.js najlepiej nadaje się do aplikacji w czasie rzeczywistym: gry online, narzędzia do współpracy, pokoje czatu lub cokolwiek, w czym to, co robi użytkownik (lub robot? Lub czujnik?), Musi być natychmiast zauważony przez innych użytkowników, bez odświeżania strony.

Powinienem również wspomnieć, że Socket.IO w połączeniu z Node.js zmniejszy twoje opóźnienie w czasie rzeczywistym jeszcze bardziej niż jest to możliwe przy długim odpytywaniu. Socket.IO powróci do długiego odpytywania jako najgorszego scenariusza i zamiast tego użyje gniazd sieciowych, a nawet Flasha, jeśli są dostępne.

Ale powinienem również wspomnieć, że prawie każdą sytuację, w której kod może blokować z powodu wątków, można lepiej rozwiązać za pomocą Node.js. Lub każda sytuacja, w której potrzebujesz aplikacji sterowanej zdarzeniami.

Ryan Dahl powiedział także w jednym z wystąpień, że testy porównawcze Node.js ściśle rywalizują z Nginx o regularne stare żądania HTTP. Więc jeśli zbudujemy przy pomocy Node.js, możemy dość skutecznie służyć naszym normalnym zasobom, a kiedy potrzebujemy rzeczy sterowanych zdarzeniami, jesteśmy gotowi to obsłużyć.

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

Powody korzystania z NodeJS:

• Działa w Javascript, więc możesz używać tego samego języka na serwerze i kliencie, a nawet współdzielić między nimi kod (np. W celu weryfikacji formularza lub renderowania widoków na obu końcach).

• System jednowątkowy sterowany zdarzeniami to szybki, nawet przy obsłudze wielu żądań jednocześnie, a także prosty w porównaniu z tradycyjnymi wielowątkowymistrukturami Java lub ROR.

• Ciągle rosnąca pula pakietów dostępnych za pośrednictwem NPM , w tym biblioteki / moduły po stronie klienta i serwera, a także narzędzia wiersza polecenia do tworzenia stron internetowych. Większość z nich jest dogodnie hostowana na github, gdzie czasami możesz zgłosić problem i znaleźć go w ciągu kilku godzin! Miło jest mieć wszystko pod jednym dachem, ze standardowym raportowaniem problemów i łatwym rozwidlaniem.

• Stało się standardowym środowiskiem defacto do uruchamiania defacto, narzędzia związane JavaScript i inne narzędzia internetowe , w tym narzędzia zadań, minizatory, urządzenia upiększające, lintery, preprocesory, programy pakujące i procesory analityczne.

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

Powody nie należy używać NodeJS:

• Uruchamia Javascript, który nie ma sprawdzania typu kompilacji. W przypadku dużych, złożonych systemów lub projektów o kluczowym znaczeniu dla bezpieczeństwa , w tym współpracy między różnymi organizacjami, język, który zachęca do kontraktowych interfejsów i zapewnia statyczne sprawdzanie typu, może na dłuższą metę zaoszczędzić trochę czasu na debugowanie (i wybuchy ). (Chociaż JVM utknęła null, więc proszę użyć Haskell do reaktorów jądrowych.)

• Co więcej, wiele pakietów w NPM jest trochę surowych i wciąż jest w fazie szybkiego rozwoju. Niektóre biblioteki dla starszych frameworków przeszły dekadę testów i naprawiania błędów i są bardzo stabilne . Npmjs.org nie ma mechanizmu oceniania pakietów , co doprowadziło do rozprzestrzeniania się pakietów, które robią mniej więcej to samo, z czego duży procent nie jest już utrzymywany.

• Zagnieżdżone piekło zwrotne. (Oczywiście, że są 20 różnych rozwiązań tego ...)

• Ciągle rosnąca pula pakietów może sprawić, że jeden projekt NodeJS będzie wyglądał zupełnie inaczej niż następny. Ze względu na ogromną liczbę dostępnych opcji (np. Express / Sails.js / Meteor / Derby ) istnieje duża różnorodność wdrożeń . Czasami może to utrudnić nowemu deweloperowi włączenie się do projektu Węzła. Porównaj to z dołączeniem programisty Rails do istniejącego projektu: powinien być w stanie dość szybko zapoznać się z aplikacją, ponieważ wszystkie aplikacje Rails są zachęcane do podobnej struktury .

• Radzenie sobie z plikami może być trochę uciążliwe. Rzeczy, które są trywialne w innych językach, takie jak czytanie wiersza z pliku tekstowego, są na tyle dziwne, że w Node.js jest pytanie StackOverflow na ponad 80 głosów. Nie ma prostego sposobu na odczytanie jednego rekordu na raz z pliku CSV . Itp.

Uwielbiam NodeJS, jest szybki, dziki i zabawny, ale martwię się, że mało interesuje go poprawność. Miejmy nadzieję, że w końcu uda nam się połączyć to, co najlepsze z obu światów. Zależy mi na tym, co w przyszłości zastąpi Węzeł ... :)

Krótko mówiąc:

Node.js jest dobrze dostosowany do aplikacji, które mają wiele równoczesnych połączeń, a 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 node.js jest Mixu za tech blog: Zrozumienie node.js pętlę zdarzeń .

Mam jeden przykład z rzeczywistego świata, w którym użyłem Node.js. Firma, w której pracuję, ma jednego klienta, który chciał mieć prostą statyczną stronę HTML. Ta strona internetowa służy do sprzedaży jednego przedmiotu za pomocą PayPal, a klient chciał również mieć licznik, który pokazuje liczbę sprzedanych przedmiotów. Klient spodziewa się dużej liczby odwiedzających tę stronę. Postanowiłem zrobić licznik za pomocą Node.js i Express.js frameworku .

Aplikacja Node.js była prosta. Uzyskaj kwotę sprzedanych przedmiotów z bazy danych Redis , zwiększ licznik przy sprzedaży przedmiotu i podaj wartość licznika użytkownikom za pośrednictwem interfejsu API .

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

1. Jest bardzo lekki i szybki. Na tej stronie odwiedziło ponad 200 000 wizyt w ciągu trzech tygodni, a minimalne zasoby serwera były w stanie obsłużyć to wszystko.
2. Licznik jest naprawdę łatwy do zrobienia w czasie rzeczywistym.
3. Node.js był łatwy do skonfigurowania.
4. Istnieje wiele modułów dostępnych za darmo. Na przykład znalazłem moduł Node.js dla PayPal.

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

Najważniejsze powody, aby rozpocząć kolejny projekt za pomocą Node ...

• Są w nim wszyscy najfajniejsi kolesie ... więc musi być fajnie.
• Możesz spotkać się w chłodnicy i przeżyć wiele przygód związanych z Węzłem.
• Jesteś pinny pincher, jeśli chodzi o koszty hostingu w chmurze.
• Zostałem tam zrobiony z Railsami
• Nienawidzisz wdrożeń IIS
• Twoja stara praca IT staje się dość nudna i żałujesz, że nie jesteś w nowym, błyszczącym Start Up.

Czego oczekiwać ...

• Poczujesz się bezpiecznie dzięki Express bez całego nadmuchiwanego serwera, którego nigdy nie potrzebowałeś.
• Działa jak rakieta i dobrze się skaluje.
• Marzysz Zainstalowałeś to. Repozytorium pakietu węzłów npmjs.org to największy ekosystem bibliotek open source na świecie.
• Twój mózg będzie się wypaczał w krainie zagnieżdżonych połączeń zwrotnych ...
• ... dopóki nie nauczysz się dotrzymywać obietnic .
• Sekwencjonowanie i paszport to nowi przyjaciele API.
• Debugowanie głównie kodu asynchronicznego stanie się ... interesujące .
• Czas dla wszystkich Noderów na opanowanie maszynopisu .

Kto tego używa?

• PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
• Oto dlaczego przeszli na Węzeł .

Nie ma to jak Silver Bullet. Wszystko wiąże się z pewnymi kosztami. To tak, jakby jeść tłuste potrawy, narażasz swoje zdrowie, a zdrowa żywność nie pochodzi z przyprawami takimi jak tłuste potrawy. To jest indywidualny wybór, czy chcą zdrowia lub przypraw, jak w ich jedzeniu. Taki sam sposób, w jaki Node.js uważa się za używany w konkretnym scenariuszu. Jeśli Twoja aplikacja nie pasuje do tego scenariusza, nie należy jej brać pod uwagę przy tworzeniu aplikacji. Po prostu myślę o tym samym:

Kiedy używać Node.JS

1. Jeśli kod po stronie serwera wymaga bardzo niewielu cykli procesora. W innym świecie wykonujesz operacje nieblokujące i nie ma dużego algorytmu / zadania, które pochłania dużo cykli procesora.
2. Jeśli jesteś z Javascriptem i dobrze piszesz kod jednowątkowy, podobnie jak JS po stronie klienta.

Kiedy NIE należy używać Node.JS

1. Żądanie serwera zależy od algorytmu / zadania intensywnie obciążającego procesor.

Uwzględnienie skalowalności za pomocą Node.JS

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

Node.JS Alternatywy

Istnieją inne opcje do użycia zamiast Node.JS, jednak Vert.x wydaje się dość obiecujący i ma wiele dodatkowych funkcji, takich jak polygot i lepszą skalowalność.

Inną wspaniałą rzeczą, o której myślę, że nikt nie wspominał o Node.js, jest niesamowita społeczność, system zarządzania pakietami (npm) i ilość istniejących modułów, które można dołączyć, po prostu włączając je do pliku package.json.

Mój kawałek: nodejs jest świetny do tworzenia systemów czasu rzeczywistego, takich jak analityka, aplikacje czatowe, api, serwery reklam itp. Do diabła, swoją pierwszą aplikację do czatu zrobiłem używając nodejs i socket.io w czasie krótszym niż 2 godziny, i to także podczas tygodnia egzaminacyjnego!

Edytować

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

Kiedy użyć

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

• Gniazda obsługują tylko serwery, takie jak aplikacje czatu, aplikacje IRC itp.
• Sieci społecznościowe, które kładą nacisk na zasoby w czasie rzeczywistym, takie jak geolokalizacja, strumień wideo, strumień audio itp.
• Obsługa małych porcji danych naprawdę szybko, jak aplikacja internetowa do analizy.
• Odsłaniając interfejs API tylko REST.

Kiedy nie należy używać

Jest to bardzo wszechstronny serwer WWW, więc możesz go używać gdziekolwiek chcesz, ale prawdopodobnie nie w tych miejscach.

• Proste blogi i strony statyczne.
• Podobnie jak statyczny serwer plików.

Pamiętaj, że po prostu robię dupki. W przypadku statycznych serwerów plików apache jest lepszy głównie dlatego, że jest powszechnie dostępny. Społeczność nodejs z biegiem lat powiększyła się i stała się bardziej dojrzała i można śmiało powiedzieć, że z nodejs można korzystać niemal wszędzie, jeśli masz własny wybór hostingu.

Można go użyć gdzie

• Aplikacje, które są silnie sterowane zdarzeniami i są mocno powiązane z I / O
• Aplikacje obsługujące dużą liczbę połączeń z innymi systemami
• Aplikacje w czasie rzeczywistym (Node.js został zaprojektowany od podstaw dla czasu rzeczywistego i łatwy w użyciu).
• Aplikacje, które żonglują fragmentami informacji przesyłanych strumieniowo do iz innych źródeł
• Duży ruch, skalowalne aplikacje
• Aplikacje mobilne, które muszą rozmawiać z interfejsem API i bazą danych platformy, bez konieczności przeprowadzania dużej ilości analiz danych
• Twórz aplikacje sieciowe
• Aplikacje, które często muszą rozmawiać z zapleczem

Na froncie mobilnym firmy działające w czasie największej oglądalności korzystały z Node.js w zakresie rozwiązań mobilnych. Sprawdź dlaczego?

LinkedIn jest wybitnym użytkownikiem. Cały ich stos mobilny jest oparty na Node.js. Przeszli z 15 serwerów z 15 instancjami na każdej maszynie fizycznej do zaledwie 4 instancji - które mogą podwoić ruch!

eBay uruchomił ql.io, język zapytań internetowych dla interfejsów API HTTP, który używa Node.js jako stosu środowiska wykonawczego. Udało im się dostroić zwykłą stację roboczą Ubuntu o jakości deweloperskiej do obsługi ponad 120 000 aktywnych połączeń na proces node.js, przy czym każde połączenie zajmuje około 2kB pamięci!

Walmart przeprojektował swoją aplikację mobilną do korzystania z Node.js i przekazał swoje przetwarzanie JavaScript na serwer.

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

Węzeł najlepszy do równoczesnej obsługi żądań -

Zacznijmy od historii. Od 2 lat pracuję nad JavaScript i rozwijam front-end i bardzo mi się to podoba. Faceci z zaplecza dostarczają nam API napisane w Javie, python (nie dbamy o to) i po prostu piszemy wywołanie AJAX, zdobywamy nasze dane i zgadnijcie co! skończyliśmy. Ale w rzeczywistości nie jest to takie proste. Jeśli dane, które otrzymujemy, są nieprawidłowe lub wystąpił błąd serwera, wówczas utknęliśmy i musimy skontaktować się z naszymi facetami zaplecza za pośrednictwem poczty lub czatu (czasami również za pośrednictwem WhatsApp :).) nie jest fajne. Co jeśli napisaliśmy nasze API w JavaScript i wywołaliśmy te API z naszego interfejsu? Tak, to całkiem fajne, ponieważ jeśli napotkamy jakiś problem w interfejsie API, możemy to sprawdzić. Zgadnij co ! możesz to zrobić teraz, jak? - Węzeł jest dla ciebie.

Ok zgodził się, że możesz napisać swój interfejs API w JavaScript, ale co, jeśli nie przeszkadza mi powyższy problem. Czy masz jakiś inny powód, aby używać węzła do reszty interfejsu API?

więc tutaj zaczyna się magia. Tak, mam inne powody, aby używać węzła dla naszych interfejsów API.

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

1. Waiting Way: Nasz serwer zaczyna obsługiwać r1żądania i czeka na odpowiedź na zapytanie. po zakończeniu r1serwer zaczyna obsługiwać r2i robi to w ten sam sposób. Czekanie nie jest dobrym pomysłem, ponieważ nie mamy zbyt wiele czasu.

2. Sposób wątkowania: Nasz serwer utworzy dwa wątki dla obu żądań r1i spełni r2swoje zadanie po zapytaniu do bazy danych, więc szybko się ochłodzi, ale zajmuje dużo pamięci, ponieważ widzimy, że uruchomiliśmy dwa wątki, a problem rośnie, gdy oba żądania pytają o te same dane wtedy musicie poradzić sobie z problemami zakleszczonymi. To lepsze niż oczekiwanie, ale nadal występują problemy.

Oto, jak zrobi to węzeł:

3. Węzeł: kiedy to samo współbieżne żądanie pojawi się w węźle, wówczas zarejestruje zdarzenie za pomocą wywołania zwrotnego i przejdzie do przodu, nie będzie czekać na odpowiedź zapytania na konkretne r1żądanie, więc gdy nadejdzie żądanie, wówczas pętla zdarzeń węzła (tak, istnieje pętla zdarzeń w węźle, który służy temu celowi.) zarejestrować zdarzenie za pomocą funkcji wywołania zwrotnego i przejść do przodu w celu wyświetlenia r2żądania i podobnie zarejestrować zdarzenie za pomocą wywołania zwrotnego. Za każdym razem, gdy jakiekolwiek zapytanie zakończy się, wyzwala odpowiednie zdarzenie i wykonuje wywołanie zwrotne do zakończenia bez przerywania.

Więc nie czekaj, nie wątkuj, nie zużywaj pamięci - tak, to jest węzeł do obsługi resztowego API.

Jeszcze jednym powodem, dla którego wybrałem Node.js dla nowego projektu, jest:

Być w stanie tworzyć wyłącznie w chmurze

Od jakiegoś czasu korzystam z Cloud9 IDE i teraz nie wyobrażam sobie bez niego, obejmuje wszystkie cykle rozwojowe. Wszystko czego potrzebujesz to przeglądarka i możesz kodować w dowolnym miejscu i na dowolnym urządzeniu. Nie musisz wpisywać kodu do jednego komputera (jak w domu), a następnie do kasy na innym komputerze (jak w miejscu pracy).

Oczywiście może być oparte na chmurze IDE dla innych języków lub platform (Cloud 9 IDE dodaje także obsługę innych języków), ale korzystanie z Cloud 9 do programowania Node.js jest dla mnie naprawdę świetnym doświadczeniem.

Kolejną rzeczą, którą zapewnia węzeł, jest możliwość tworzenia wielu instancji v8 węzła przy użyciu procesu potomnego węzła ( childProcess.fork (), z których każdy wymaga pamięci 10 MB zgodnie z dokumentami) w locie, nie wpływając w ten sposób na główny proces uruchamiania serwera. Odciążanie zadania w tle, które wymaga ogromnego obciążenia serwera, staje się dziecinnie proste i możemy łatwo zabijać je w razie potrzeby.

Często korzystam z węzła i większość tworzonych przez nas aplikacji wymaga jednoczesnych połączeń z serwerem, co powoduje duży ruch sieciowy. Frameworki takie jak Express.js i nowe Koajs (które usunęły piekło zwrotne) jeszcze bardziej ułatwiły pracę na węźle.

Zakładanie legowisk azbestowych ...

Wczoraj mój tytuł w Packt Publications, Reactive Programming with JavaScript . To tak naprawdę nie jest tytuł skoncentrowany na Node.js; wczesne rozdziały mają na celu omówienie teorii, a później obszerne rozdziały kodu obejmują praktykę. Ponieważ tak naprawdę nie uważałem za stosowne nie dać czytelnikom serwera WWW, Node.js wydawał się zdecydowanie oczywistym wyborem. Sprawa została zamknięta, zanim jeszcze została otwarta.

Mógłbym bardzo pozytywnie ocenić moje doświadczenia z Node.js. Zamiast tego byłem szczery, jeśli chodzi o dobre i złe punkty, które napotkałem.

Pozwól mi podać kilka istotnych cytatów:

Ostrzeżenie: Node.js i jego ekosystem są gorące - wystarczająco dużo, aby cię ciężko spalić!

Kiedy byłem asystentem nauczyciela w matematyce, jedną z nieoczywistych sugestii, które mi powiedziano, było nie mówienie uczniowi, że coś jest „łatwe”. Powód był nieco oczywisty z perspektywy czasu: jeśli powiesz ludziom, że coś jest łatwe, ktoś, kto nie widzi rozwiązania, może poczuć się (jeszcze bardziej) głupi, ponieważ nie tylko nie rozumie, jak rozwiązać problem, ale problem są zbyt głupie, aby zrozumieć, że jest to łatwe!

Są gotchas, które nie tylko drażnią ludzi pochodzących z Python / Django, które natychmiast przeładowują źródło, jeśli cokolwiek zmienisz. W przypadku Node.js domyślnym zachowaniem jest to, że jeśli dokonasz jednej zmiany, stara wersja będzie aktywna do końca czasu lub do momentu ręcznego zatrzymania i zrestartowania serwera. To nieodpowiednie zachowanie nie tylko drażni Pythonistów; drażni także rodzimych użytkowników Node.js, którzy udostępniają różne obejścia. Pytanie StackOverflow „Automatyczne ponowne ładowanie plików w Node.js” ma w chwili pisania tego tekstu ponad 200 głosów pozytywnych i 19 odpowiedzi; edycja kieruje użytkownika do skryptu niani, nadzorcy węzłów, ze stroną główną pod adresem adresem http://tinyurl.com/reactjs-node-supervisor. Ten problem daje nowym użytkownikom świetną okazję, aby poczuć się głupio, ponieważ myśleli, że naprawili problem, ale stare, błędne zachowanie jest całkowicie niezmienione. I łatwo zapomnieć o odbiciu serwera; Zrobiłem to wiele razy. A wiadomość, którą chciałbym przekazać, brzmi: „Nie, nie jesteś głupi, ponieważ to zachowanie Node.js ugryzło cię w plecy; po prostu projektanci Node.js nie widzieli powodu, aby zapewnić tutaj odpowiednie zachowanie. Spróbuj sobie z tym poradzić, być może korzystając z pomocy przełożonego węzła lub innego rozwiązania, ale nie odchodź, czując się głupio. Nie ty masz problem; problem tkwi w domyślnym zachowaniu Node.js. ”

Ten rozdział, po krótkiej debacie, został pozostawiony, właśnie dlatego, że nie chcę sprawiać wrażenia „to łatwe”. Wielokrotnie przecinam ręce, starając się, aby rzeczy działały, i nie chcę wygładzać trudności i sprawić, że uwierzysz, że sprawne funkcjonowanie Node.js i jego ekosystemu jest prostą sprawą, a jeśli nie jest 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łupia - coś musi być ze mną nie tak”. Nie jesteś głupi, jeśli doświadczysz paskudnych niespodzianek związanych z Node.js. To nie ty! To Node.js i jego ekosystem!

Dodatek, którego tak naprawdę nie chciałem po rosnącym crescendo w ostatnich rozdziałach i wnioskach, mówi o tym, co udało mi się znaleźć w ekosystemie i dostarczył obejścia dla kretyńskiego dosłowności:

Inną bazą danych, która wydawała się być idealnie dopasowana, a którą można jeszcze wymienić, jest implementacja magazynu kluczy i wartości HTML5 po stronie serwera. Takie podejście ma główną zaletę interfejsu API, który jest zrozumiały dla większości dobrych programistów front-endów. W tym przypadku jest to również interfejs API, który większość niezbyt dobrych programistów front-endów rozumie wystarczająco dobrze. Ale dzięki pakietowi węzła-localstorage, podczas gdy dostęp do słownika nie jest oferowany (chcesz użyć localStorage.setItem (klucz, wartość) lub localStorage.getItem (klucz), a nie localStorage [klucz]), pełna semantyka localStorage jest implementowana , w tym domyślny przydział 5 MB - DLACZEGO? Czy deweloperzy JavaScript po stronie serwera muszą być chronieni przed sobą?

Jeśli chodzi o możliwości baz danych po stronie klienta, przydział 5 MB na witrynę to naprawdę spora i przydatna przestrzeń do oddychania, umożliwiająca programistom pracę z nią. Możesz ustawić znacznie niższy limit, a jednocześnie zaoferować programistom niezmierną poprawę w stosunku do limpowania 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 limit, z którego zaradni programiści mogą zrobić wiele. Ale z drugiej strony 5 MB nie jest szczególnie dużą częścią większości dysków zakupionych w ostatnim czasie, co oznacza, że ​​jeśli ty i strona internetowa nie zgadzacie się co do rozsądnego wykorzystania miejsca na dysku lub niektóre witryny są po prostu zbyt duże, naprawdę nie kosztuje dużo i nie grozi ci zalanie dysku twardego, chyba że twój dysk twardy był już zbyt pełny.

Jednak można delikatnie zauważyć, że gdy jesteś jedynym, który pisze kod dla swojego serwera, nie potrzebujesz żadnej dodatkowej ochrony przed powiększeniem bazy danych o rozmiar przekraczający 5 MB. Większość programistów nie potrzebuje ani nie chce narzędzi działających jako niania i chroniąc je przed przechowywaniem ponad 5 MB danych po stronie serwera. A limit 5 MB, który jest złotym działaniem równoważącym po stronie klienta, jest raczej głupiutki na serwerze Node.js. (A w przypadku bazy danych dla wielu użytkowników, takiej jak ta opisana w niniejszym dodatku, nieco boleśnie można zauważyć, że nie jest to 5 MB na konto użytkownika, chyba że utworzysz osobną bazę danych na dysku dla każdego konta użytkownika; to 5 MB współdzielone między wszystkie konta użytkowników razem bolesnejeśli staniesz się wirusowy!) Dokumentacja mówi, że limit można dostosować, ale tydzień temu e-mail do programisty z pytaniem, jak zmienić limit, jest bez odpowiedzi, podobnie jak pytanie StackOverflow zadające to samo. Jedyną odpowiedzią, jaką udało mi się znaleźć, jest źródło Github CoffeeScript, gdzie jest ono wymienione jako opcjonalny drugi argument liczby całkowitej dla konstruktora. To jest dość łatwe i możesz określić przydział równy rozmiarowi dysku lub partycji. Ale oprócz przeniesienia funkcji, która nie ma sensu, autorowi narzędzia nie udało się całkowicie przestrzegać bardzo standardowej konwencji interpretowania 0 jako oznaczającej „nieograniczony” dla zmiennej lub funkcji, gdzie liczba całkowita ma określać maksymalny limit dla niektórych zasobów. Najlepszą rzeczą związaną z tym błędem jest prawdopodobnie określenie, że limit to 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ę, cały czas używając JavaScript jako całości, a częścią JavaScript, który stał się szanowanym językiem, był Douglas Crockford mówiąc w istocie: „JavaScript jako język ma naprawdę dobre i złe strony. Oto dobre części. Po prostu zapomnij, że coś jeszcze tam jest ”. Być może gorący ekosystem Node.js wyhoduje własnego „Douglasa Crockforda”, który powie: „Ekosystem Node.js to kodujący Dziki Zachód, ale można znaleźć kilka prawdziwych klejnotów. Oto mapa drogowa. Oto obszary, których należy unikać za wszelką cenę. Oto obszary z jedną z najbogatszych wypłat w KAŻDYM języku lub środowisku. ”

Być może ktoś inny podejmie te słowa jako wyzwanie i podąży za przykładem Crockforda i napisze „dobre części” i / lub „lepsze części” dla Node.js i jego ekosystemu. Kupiłbym kopię!

Biorąc pod uwagę stopień entuzjazmu i czystą liczbę godzin pracy nad wszystkimi projektami, może być uzasadnione za rok, dwa lub trzy, aby ostro stłumić wszelkie uwagi na temat niedojrzałego ekosystemu poczynione w czasie pisania tego tekstu. Za pięć lat może mieć sens stwierdzenie: „Ekosystem Node.js 2015 miał kilka pól minowych. Ekosystem Node.js 2020 ma wiele rajów. ”

Jeśli twoja aplikacja głównie tethering api WWW lub innych kanałów io, daje lub bierze interfejs użytkownika, node.js może być dla ciebie dobrym wyborem, szczególnie jeśli chcesz wycisnąć jak najwięcej skalowalności lub, jeśli twój główny język w życiu jest javascript (lub swego rodzaju transpilatory javascript). Jeśli zbudujesz mikrousługi, node.js jest również w porządku. Node.js nadaje się również do każdego małego lub prostego projektu.

Jego główną zaletą jest to, że pozwala front-endom brać odpowiedzialność za zaplecze zamiast typowego podziału. Kolejnym uzasadnionym punktem sprzedaży jest to, że twoja siła robocza jest zorientowana na JavaScript.

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

W szczególności, gdy twoja aplikacja musi wykonywać synchroniczne przepływy, zaczynasz krwawić z częściowo wypalonych rozwiązań, które znacznie spowalniają twój proces rozwoju. Jeśli w aplikacji masz części wymagające intensywnych obliczeń, postępuj ostrożnie, wybierając (tylko) node.js. Może http://koajs.com/ lub inne nowości łagodzą te pierwotnie drażliwe aspekty, w porównaniu do tego, kiedy pierwotnie użyłem node.js lub to napisałem.

Mogę podzielić się kilkoma punktami, gdzie i dlaczego używać węzła js.

1. W przypadku aplikacji w czasie rzeczywistym, takich jak czat, wspólna edycja lepiej współpracujemy z nodejs, ponieważ jest to baza zdarzeń, w której zdarzenie pożarowe i dane są wysyłane do klientów z serwera.
2. Prosta i łatwa do zrozumienia, ponieważ jest to baza JavaScript, w której większość ludzi ma pomysł.
3. Większość obecnych aplikacji internetowych idzie w kierunku kątowego js i szkieletu, dzięki węzłowi łatwo jest wchodzić w interakcje z kodem po stronie klienta, ponieważ oba będą wykorzystywać dane json.
4. Wiele dostępnych wtyczek.

Wady: -

1. Węzeł będzie obsługiwał większość baz danych, ale najlepszy jest mongodb, który nie będzie obsługiwał złożonych połączeń i innych.
2. Błędy kompilacji ... deweloper powinien poradzić sobie z każdym wyjątkiem od innych, jeśli jakakolwiek aplikacja zgodności błędów przestanie działać tam, gdzie znowu musimy iść i uruchomić ją ręcznie lub za pomocą dowolnego narzędzia do automatyzacji.

Wniosek: - Nodejs najlepiej używać do prostych aplikacji w czasie rzeczywistym .. jeśli masz bardzo dużą logikę biznesową i złożoną funkcjonalność lepiej nie należy 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 powinien pozostać zgodny z technologią wygody.

1. Węzeł jest świetny do szybkich prototypów, ale nigdy więcej nie użyję go do niczego skomplikowanego. Spędziłem 20 lat na rozwijaniu relacji z kompilatorem i na pewno mi tego brakuje.

2. Węzeł jest szczególnie bolesny dla utrzymywania kodu, którego nie odwiedziłeś przez jakiś czas. Informacje o typie i wykrywanie błędów czasu kompilacji to DOBRE RZECZY. Po co to wszystko wyrzucać? Po co? I do cholery, kiedy coś idzie na południe, stosy śladów są często zupełnie bezużyteczne.