Czy istnieje dobry powód, aby unikać pliku node.js w aplikacjach internetowych innych niż działające w czasie rzeczywistym?

29

Wiele razy mówiłem o tym, jak niesamowite jest Node.js dla aplikacji internetowych w czasie rzeczywistym - rzeczy, które wymagają gniazd, komety, komunikacji z AJAX i tak dalej. Wiem, że jego oparty na zdarzeniach, asynchroniczny, oparty na wątkach model nadaje się również do współbieżności przy niskim obciążeniu.

Widziałem także samouczki Node.js dotyczące prostszych, „tradycyjnych” aplikacji, nie działających w czasie rzeczywistym (np. Standardowy przykład blogu, który wydaje się być standardowym „Hello World” dla osób uczących się tworzenia aplikacji). Wiem również, że węzeł-statyczny pozwala na obsługę zasobów statycznych.

Moje pytanie brzmi: czy istnieje jakiś dobry powód, aby unikać Node.js w przypadku tradycyjnych aplikacji internetowych, takich jak ogłoszenia, fora, wspomniany przykład blogu lub rodzaj aplikacji CRUD tworzonych dla wewnętrznych aplikacji biznesowych? Tylko dlatego, że wyróżnia się funky w czasie rzeczywistym, czy jest to przeciwwskazane do bardziej zdecydowanych zastosowań?

Jedyną rzeczą, o której mogę pomyśleć, poza batem, jest brak dojrzałych bibliotek (choć to się zmienia).

(Powód, dla którego pytam, jest to, że rozważam porzucenie PHP dla Node.js, głównie w celu przezwyciężenia niedopasowania impedancji podczas przełączania między językami, ale także po to, aby móc ponownie użyć kodu sprawdzania poprawności itp. Moje superego upomina mnie, aby wybrać najlepsze narzędzie do tego zadania , nie mam jednak czasu na naukę piętnastu języków i wszystkich bibliotek użytkownika, żeby mieć kompleksowy arsenał. Zapewniam też, że Node.js może ułatwić mi optymalizację niż PHP / Apache w przyszłości, kiedy muszę zacząć myśleć o dużym natężeniu ruchu).

[EDYCJA] Dzięki za dotychczasowe odpowiedzi, ludzie; Chcę tylko sprawdzić, czy ktokolwiek waży, zanim wybiorę odpowiedź. Odpowiedź z @Raynos trochę potwierdza to, co myślę, a linki od komentujących dostarczyły dobrego myślenia do przemyślenia, ale chcę sprawdzić, czy ktoś inny ma jakieś odpowiedzi specyficzne dla Węzła, na przykład „NIE UŻYWAJ NODE DLA PROBLEMU X „. (Oprócz zadań wymagających dużego procesora; już to wiem :-)

web-development web-applications node.js

— Paul d'Aoust
źródło

1

@ default.kramer: Dzięki za link, bardzo mi się podobało!

— Zach.

1

łał! Raczej grzeczny facet, co? W kolejnym artykule wydaje się mówić, że w przypadku aplikacji o wysokim I / O i niskim CPU procesory i systemy wątkowe są mniej więcej na tym samym poziomie, a problem leży po stronie początkujących programistów, którzy nie wiedzą, kiedy poddawaj się wydarzeniom i odradzaj nowy wątek. Ale ignorancja programisty nie oznacza, że narzędzie jest złe, prawda? Zgadzam się, że korzystanie ze środowiska, którego forté to pętle zdarzeń do zadań wymagających dużej mocy procesora, jest nieco dziwne, ale czy jest złe?

— Paul d'Aoust,

1

Jego nienawiść do JavaScript wydaje się być również ważną kwestią, która, jak obawiam się, może być częściowo odpowiedzialna za energię stojącą za jego argumentem.

— Paul d'Aoust

@Paul - Prawdopodobnie powinieneś wziąć to z odrobiną soli. Nie wiem dużo o Node.js; Pomyślałem, że to było zabawne. (jak większość jego tekstów)

— default.kramer

@ default.kramer dzięki za przypomnienie; Zwykle traktuję opinie ludzi jako ewangelię. Jego poważną krytyką wydaje się być to, że nie powinieneś używać Node.js do zadań intensywnie wykorzystujących procesor. Jestem zdezorientowany jego krytyką procesów pracowniczych; czy jest jakiś duży problem z tworzeniem osobnych pracowników dla określonych zadań?

— Paul d'Aoust,

13

czy jest jakiś dobry powód, aby unikać Node.js w przypadku tradycyjnych aplikacji internetowych?

Tak, jeśli masz N lat na platformie internetowej X, to oczywiście możesz szybciej opracować aplikację na platformie X.

Jeśli chcesz zrobić Y, a platforma X ma gotowe rozwiązanie Y, które robi X, zrób to.

Wszystkie ogólne powody, dla których warto korzystać z jednej platformy nad drugą.

rodzaj aplikacji CRUD, które budujesz dla wewnętrznych aplikacji biznesowych?

Tak, istnieją inne platformy, które pozwalają szybciej pisać ogólne aplikacje, przychodzi na myśl rubin na szynach.

Jednak to powiedział. Mam doświadczenie z węzłem i nie mogę twierdzić, że wybrałbym inną platformę niż węzeł, chyba że zrobi to dla mnie ogromna ilość funkcji.

Zasadniczo jest to proste pytanie

Czy istnieje narzędzie, które robi to wszystko dla mnie? Nie, a następnie wybierz najwygodniejszą platformę do napisania narzędzia.

Nie ma solidnych powodów, dla których node.js jest niewygodną platformą (inną niż „i hate javascript”)

— Raynos
źródło

Uważasz więc, że pragmatyczne zasady, takie jak znajomość, dostępność bibliotek itp., Są silnymi argumentami przemawiającymi za pewną platformą, prawda? To dobre myśli i zdecydowanie rozważam to. (Dziwię się, że opowiadasz się za gotowymi rozwiązaniami; myślałem, że jesteś dobrym facetem!)

— Paul d'Aoust,

@ Pauld'Aoust Jestem typowym facetem. Jednak nic nie robię i nie mam terminów.

— Raynos

heh, dzięki za zastrzeżenie. Pamiętam twoje komentarze na czacie node.js na temat korzystania z bibliotek modelowych innych osób (Backbone.js itp.) I uświadomienia sobie, że spędzam zbyt dużo czasu na uczeniu się Backbone.js, a za mało czasu po prostu wykorzystuję (i uczę się) skryptów JavaScript prototypowy mechanizm dziedziczenia. Dobra rada; Czuję się teraz znacznie bardziej zrelaksowany.

— Paul d'Aoust,

4

-1 niejasne. 1) To, że masz N-letnie doświadczenie w X - nie oznacza, że powinieneś unikać Node.JS. Czy proponujesz rozmyślną ignorancję opartą na doświadczeniu? A jakie są „ogólne przyczyny”? 2) „inne aplikacje, które umożliwiają szybsze pisanie aplikacji ogólnej” - jest czysto subiektywne. 3) „inny * niż” * Nienawidzę * JavaScript ”- jest również subiektywny i nie jest ważnym powodem, aby unikać kwitnącej technologii. * Ortografii.

— Jack Stone

@ClintNash niektóre z twoich powodów nie różnią się od jego. „Zasoby ludzkie” vs. „N-letnie doświadczenie” są dokładnie takie same. „NodeJS nie jest tak dojrzały jak tradycyjne frameworki” vs „Tak, istnieją inne platformy, które pozwalają szybciej pisać ogólne aplikacje, przychodzi mi na myśl rubin na szynach”. są również takie same. Nie tylko są takie same, ale twoje nie są bardziej wymierne (obiektywne) niż jego.

— aaaaaa

6

Po kilku tygodniach pracy z węzłem powiedziałbym, że tak, jest bardzo fajny. Ale niekoniecznie coś, czego chcesz użyć do zastąpienia swoich popularnych aplikacji internetowych ... ani, imo, nie jest to przeznaczone.

Pamiętaj, że węzeł jest własnym serwerem. Wprowadza to złożoność, jeśli chcesz uruchomić więcej niż tylko jedną aplikację node.js. tzn. jeśli masz więcej niż jedną witrynę / domenę hostowaną na komputerze. Nie przypomina stosu LAMP, w którym można mieć tuzin aplikacji PHP dla kilkudziesięciu różnych domen działających na tym samym serwerze (przynajmniej na porcie 80). Istnieją struktury dla węzła, które prawdopodobnie umożliwiają, ale to dodaje złożoności, której po prostu nie potrzebujesz, jeśli trzymasz się tradycyjnych platform internetowych. (Oczywiście można również skonfigurować serwery proxy, umieszczając serwer WWW przed węzłem, ale tego rodzaju korzyści nie przynoszą korzyści z używania węzła).

imo, Node jest idealny do pracy w połączeniu z tradycyjnym serwerem WWW. Sposób, w jaki mam teraz zorganizowane rzeczy, to podawanie statycznego html / js / images przez apache i obsługa potrzeb danych w czasie rzeczywistym przez długie odpytywanie aplikacji węzła.

— Grandmaster B.
źródło

Zdecydowanie warto rozważyć łatwość użycia +1 przy konfigurowaniu wielu hostów.

— Paul d'Aoust

Całkiem proste jest umieszczenie aplikacji węzła za serwerem httpd lub nginx Apache i żądanie routingu z sygnaturą URI tej aplikacji do portu (portów) węzła.

— TomG

+1 - pojęcie node.js jako serwera proxy po stronie serwera („w połączeniu z tradycyjnym serwerem internetowym”) zyskało popularność na początku tego roku i warto przyjrzeć się temu - szczególnie jeśli masz do zarządzania dużą tradycyjną architekturę. Jest to wzorzec projektowy, który wydaje się mieć sens dla przedsiębiorstwa. Warto jednak zauważyć - nie jest to powód do UNIKNIĘCIA Node.js, ale powód do użycia go do określonego celu.

— Jack Stone

4

-1 - Umieszczenie proxy (takiego jak nginx) przed węzłem jest doskonałym przypadkiem użycia i jest w rzeczywistości o wiele bardziej bezpieczne i wydajne w niektórych przypadkach niż brak takiego. Nie pokonuje żadnych zalet węzła. Zazwyczaj uruchamiam aplikacje węzłów na gniazdach domeny unix, a następnie nginx działa jako strażnik.

— Scott Anderson

3

Dobry powód do zastanowienia się nad węzłem nie jest techniczny - jest świetny i niesamowity w tym, co robi.

Są to biznes, a zwłaszcza kapitał ludzki, tj. Programiści, którzy go znają, ile kosztują i jak są dostępni. Nie jest to trudne do nauczenia się, ale jak w przypadku każdej nowszej technologii liczba osób, które ją dobrze znają (lub chcą), jest podporządkowana większej grupie pracowników.

— Michael Durrant
źródło

więc myślisz, że tak naprawdę nie ma wiele przeciwko używaniu Węzła zamiast bardziej tradycyjnych stosów aplikacji; problemy dotyczą bardziej rzeczywistych problemów?

— Paul d'Aoust

+1. Zasoby ludzkie - i niechęć niektórych do nauki JavaScript - jest niewygodną prawdą. Ta odpowiedź stwierdza to dobrze. Ale unikanie Węzła „ponieważ ludzie nienawidzą JavaScript” nie jest logicznym postępem. Gdzie bylibyśmy technicznie, gdybyśmy unikali wszelkich innowacji - których ktoś nienawidził? Nigdzie. Wyzwanie związane z węzłem to: A) Zdobycie nowego talentu lub B) Wychowanie tradycyjnego talentu w nowy talent. Do tego momentu - od czasu, gdy John Resig przewidywał założenie Khan Academy, wszędzie pojawiają się szkoły kodów JavaScript. Krótko mówiąc, tak to wygląda. +1. Dobrze powiedziane.

— Jack Stone

3

To bardzo dobre pytanie, które musimy zadać, aby posunąć naprzód stan techniki.

Byłem bardzo ciekawy (jak Paul d'Aoust), gdzie istnieją ograniczenia Node.JS. Niestety, wiele odpowiedzi jest PEŁNYCH subiektywnych uprzedzeń i tymczasowo istotnych uzasadnień.

Zadałem sobie pytanie: Czy możemy odfiltrować subiektywne błędy i zejść na stałe odpowiedzi na to istotne pytanie?

Pozostałe punkty wydają się:

1. NodeJS nie jest tak dojrzały jak tradycyjne frameworki. Jak sugeruje Paul d'Aoust, jest to tylko tymczasowo istotny powód, nie do pełnego unikania, ale do przeglądu i należytej staranności. Odrabianie zadań domowych jako profesjonalistów internetowych jest naszym zadaniem, a naszym zadaniem jest określenie najlepszego dopasowania technologii do organizacji, ich potrzeb, ich przyszłości, zespołu (a nie nas). Dojrzałość to potrzeba wyjaśnienia i oceny apetytu na ryzyko, ale nie unikanie.

2. NodeJS jako serwer proxy. Mądra sugestia wcześniejszej dyskusji, którą warto przeanalizować i rozważyć. Jest to pojęcie używania Węzła w korelacji z istniejącymi technologiami jako wzorzec projektowy interfejsu proxy interfejsu użytkownika. Ale nie jest to również powód do UNIKANIA używania węzła, ale powód, aby unikać używania go jako pełnej zamiany. Zamiast tego zdecydował się na takie podejście.

3. Węzeł debugowania. W rozmowie z deweloperami Core Node w Joyent istnieje wiele komplikacji związanych z debuggowaniem i wykrywaniem pierwotnej przyczyny problemów wynikających z rdzenia (w oparciu o wykonanie pojedynczego wątku i niemożność przejrzenia poprzednich wątków). Jest to warte rozważenia i oceny - ale (ponownie) prawdopodobnie nie jest to awersja do powszechnego użytku, tylko przypadki na krawędziach, które mogą przesunąć kopertę. Być może twoje szczególne potrzeby należą do tej kategorii, a może nie.

4. Zasoby ludzkie. To najlepszy powód, aby UNIKAĆ używania JS na tej stronie, i moim skromnym zdaniem jest to surowa i niewygodna prawda. Nasuwa się pytanie: czy Twoja firma ma odpowiednich utalentowanych specjalistów pod ręką, aby zobaczyć projekt przez cały cykl życia? Jeśli nie, nie ma wątpliwości, że należy unikać NodeJS. Lub zamiast tego rozważ A) zlokalizowanie odpowiedniego talentu lub B) Kształcenie istniejącego talentu.

Skargi: moja obserwacja skarg dotyczących JavaScript jest taka, że wiele z nich wynika bardziej z błędu użytkownika niż z konsekwentnych błędów języka. Obaliliśmy wiele roszczeń przeciwko „The Hate JavaScript Diatribe” i nadal będziemy obalać wiele innych. Problemy takie jak - dokumentacja nie jest wystarczająco dobra, nie jest wystarczająco seksowna, ale ludzie jej nie lubią, to rak, to diabeł lub zbyt „podatny na typografię” (-CRichardson), są subiektywne i stronnicze skargi, które należy odrzucić, aby móc podejmować trafne decyzje korporacyjne.

Ostatecznie prawidłowa odpowiedź może być - nie ma dobrych powodów, by UNIKAĆ NodeJS . Być może dlatego doświadcza szybkiego wzrostu, adopcji i wkładu. Ale być może dla nas wszystkich odpowiedzią jest kontynuacja oceny, badań i lepszego zrozumienia NodeJS - i poszukiwanie konkretnych awersji. W dążeniu do otwartości na zrozumienie, gdzie Node.JS jest niedojrzały - znajdujemy dokładnie to, gdzie musimy go ulepszyć. I to jest błogosławieństwo.

Dobre pytanie. Z jednej strony jestem ciekawy, czy ktoś wymyśli lepszy powód do uniknięcia NodeJS - niż te.

— Jack Stone
źródło

-1

Czy jest jakaś korzyść z używania węzła nad X do aplikacji nie działających w czasie rzeczywistym:

Skalowanie : Węzeł ma dobrą wydajność, ale inne platformy też. Skale PHP, Ruby, Python i Java. Możesz znaleźć DUŻE nazwy, z których korzystają miliony użytkowników.
Jeden język dla frontendu i backendu : to żart, tak jak w Javie „Napisz raz uruchom gdziekolwiek”
Gorące i seksowne : jedyny ważny punkt. Ale nikogo to nie obchodzi, że twoja strona używa ostrych technologii!

Korzyści z używania X over Node w aplikacjach nie działających w czasie rzeczywistym:

Najlepsza praktyka : ponieważ Node jest nowy, ma mniej dobrych praktyk niż inne platformy, szczególnie w aplikacjach internetowych CRUD.
Język Javascript : ludzie nie lubią Javascript. Podczas gdy Node.js jest gorący, JavaScript nie. Dlatego ludzie stworzyli Coffeescript, aby uniknąć pisania Javascript, nawet po stronie klienta.
Szybkość rozwoju : stare i nudne frameworki, w tym między innymi Railsy i Django, są dobrze testowane i ulepszane przez wiele lat dla stron CRUD. Chociaż możesz implementować podobne aplikacje w Węźle, po prostu łatwiej to zrobić w ramach twojego dziadka.
Stabilność : Frameworki sieciowe Node stają się coraz lepsze w szybszym tempie. Oznacza to, że się zmieniają i będą mieć większą niekompatybilność API w najbliższej przyszłości.
Biblioteki i narzędzia : starsze technologie z większą liczbą użytkowników mają więcej bibliotek i narzędzi.

Moja odpowiedź zdecydowanie nie będzie poprawna w 2015 r. W 2014 r. Pomiń Węzeł w przypadku aplikacji internetowych, które nie działają w czasie rzeczywistym, ale miej je na oku.

Każda platforma internetowa ma mocną stronę. Będziesz szczęśliwy, gdy będziesz go używać do tego momentu. Aplikacje internetowe działające w czasie rzeczywistym nie są mocną stroną środowisk Node.

— Hossein
źródło

2

-1. Zgadzam się, że ta odpowiedź nie będzie ważna w 2015 r. Ale to również uzasadnia opinię negatywną. Zasadniczo - dzisiejsze decyzje są decyzjami na jutro. Unieważnia 8 punktorów powyżej - jeśli widzimy, że są one tylko tymczasowo istotne. 1) Skalowanie - wagi mobilne Walmart, nie powód do unikania Węzła. 2) Isomorphic JS to nie żart. To nie powód. 3) Seksapilność serwera? Większość użytkowników zna tylko UX. 4) Najlepsza praktyka jest subiektywna, 5) Nie gorąca? -podmiot 6) Łatwiej? -subiektywny. 7) Stabilność jest chwilowo istotna. 8) Przewiduje się, że NPM przejdzie przez Maven w 2014 roku. Tutaj nie ma powodów. Głosuj

— Jack Stone

-1

Node.js jest bardzo popularną platformą i ma wiele interesujących funkcji bla bla bla bla, ale użycie narzędzia jest osobistą preferencją. Dałem Node.js cztery razy i nie byłem z tego zadowolony. Oto moje powody. Należy pamiętać, że niektóre z tych przyczyn są nieaktualne lub po prostu osobiste: P

Wolałem inny język / składnię (lubię Python, Scala, moim ulubionym językiem jest Prolog, więc tak).
Jakość dokumentacji dla frameworków i bibliotek, z których korzystałem, nie jest tak dobra dla bibliotek Java, Scala, Python.
Projektanci nodejów mają obsesję na punkcie wywołań zwrotnych zamiast modelu zdarzeń, obserwatora lub przyszłości.
Gotowe są rozwiązania dla tego, co chcę robić w Ruby, Python, Java opracowanych w 2005 roku, po prostu muszę edytować plik konfiguracyjny.

— David Sergey
źródło

2

-1 - Punkty subiektywne. „Preferowana składnia”, „Dokumentacja nie tak dobra”, „Obsessive Callbacks” i „Alone Done in my language” - są niejasne i subiektywne. Słyszeliśmy to wcześniej. Są obaleni. Nie ma powodu, aby unikać Node.JS tutaj. Głosuj

— Jack Stone

1

Wszystkie punkty są moimi osobistymi preferencjami, które otwarcie wyraziłem. Jak w ten sposób obalić osobiste preferencje?

— David Sergey

-9

HTTP jest bezstanowy, więc w rzeczywistości nie ma czegoś takiego jak aplikacja internetowa działająca w czasie rzeczywistym, a zatem nie ma powodu, dla którego nie można używać węzła do wszystkiego.

To powiedziawszy, węzeł lepiej nadaje się do określonego typu architektury aplikacji. PHP to pliki HTML zawierające trochę kodu. Węzeł to kod opcjonalnie zawierający odrobinę html.

Oznacza to, że jeśli Twoja aplikacja jest standardowym formularzem HTML bez żadnego skryptu po stronie klienta, PHP będzie łatwiejsze. Węzeł ma narzędzia do tworzenia szablonów, ale oczywiście nie jest tak dojrzały jak PHP.

Jeśli masz dużo skryptów po stronie klienta i zapisujesz dane za pomocą ajax, kończysz na statycznych funkcjach wywoływania klienta HTML na serwerze. Właśnie w tym węźle jest dobry. Chociaż nie jest to sposób, w jaki zwykle buduje się aplikacje CRUD, możesz stworzyć coś całkiem ładnego przy użyciu odpowiedniego frameworka.

— Tom Clarkson
źródło

Chodzi o to, że HTTP jest bezstanowy i działa w czasie rzeczywistym; bardziej jednak interesują mnie pragmatyczne obawy związane z typową definicją czasu rzeczywistego: dużą liczbą niewielkich zamówień. Wydaje się nieco przesadne, aby podkręcić nową instancję PHP, aby czasami wyrzucić trzy lub cztery linie JSON. Czy mam rację, czy tylko cierpię na zespół papugi?

— Paul d'Aoust,

Jeśli nie ładujesz PHP, ładujesz javascript, a do tego dochodzi wiele rodzajów buforowania, więc różnica nie będzie wystarczająca. Dużą różnicą jest styl kodowania, a zatem łatwość konserwacji - obie platformy mogą wyświetlać HTML lub JSON, ale PHP został zaprojektowany dla osób przyzwyczajonych do edycji statycznych plików HTML, a węzeł został zaprojektowany dla osób przyzwyczajonych do nowoczesnego programowania javascript.

— Tom Clarkson,

Wiem, że muszę przez jakiś czas ładować tłumacza, ale widzę zaletę ciągłego działania jednego wystąpienia interpretera (oczywiście w aplikacjach o niskim procesorze), jak w Node.js, zamiast używania tłumacza i kończy się przy każdym żądaniu, jak w PHP.

— Paul d'Aoust,

Tak, i spodziewam się również, że js będzie miał lepszą wydajność na poziomie pojedynczego żądania, biorąc pod uwagę ostatnio konkurencję w tej przestrzeni. Myślę jednak, że jest to stosunkowo niewielka część różnicy - w przypadku węzła masz bezpośrednią kontrolę i dokładnie ilość kodu potrzebną do obsługi żądania, podczas gdy każdy system oparty na szablonach, który zakłada, że wyświetlasz strony, zwiększy niepotrzebne koszty i złożoność inne scenariusze.

— Tom Clarkson