비 실시간 웹 앱에 node.js를 피해야 할 이유가 있습니까?

소켓, 혜성, AJAX가 많은 통신 등을 필요로하는 실시간 웹 앱의 Node.js가 얼마나 멋진 지에 대해 많은 이야기를 보았습니다. 이벤트 중심의 비동기 스레드 중심 모델도 오버 헤드가 적은 동시성에 적합하다는 것을 알고 있습니다.

또한보다 단순한 '전통적인'비 실시간 앱 (예 : 앱 개발을 배우는 사람들을위한 표준 'Hello World'인 것처럼 보이는 표준 블로그 예제)에 대한 Node.js 자습서도 보았습니다. 또한 node-static을 사용하면 정적 자산을 제공 할 수 있습니다.

내 질문은 : 분류, 포럼, 위에서 언급 한 블로그 예제 또는 내부 비즈니스 응용 프로그램을 위해 구축 한 일종의 CRUD 응용 프로그램과 같은 전통적인 웹 응용 프로그램에서 Node.js 를 피할 만한 이유가 있습니까? 그것이 펑키 한 실시간으로 뛰어 나기 때문에 더 안정된 사용을 금합니까?

내가 생각할 수있는 유일한 것은 성숙한 라이브러리가 부족하다는 것입니다 (변경 되더라도).

(내가 요구하는 이유는 주로 언어 간 전환의 임피던스 불일치를 극복하기 위해 Node.js 용 PHP를 버리는 것을 고려하고 있기 때문에 유효성 검사 코드를 재사용 할 수 있습니다. 작업에 가장 적합한 도구입니다 .하지만 15 개의 언어와 모든 사용자 영역 라이브러리를 종합적으로 익히기 위해 많은 시간을 할애 할 수는 없습니다. 또한 Node.js가 PHP /보다 더 쉬운 최적화 경로를 제공 할 수 있다고 확신합니다 앞으로 트래픽이 많은 것을 생각해야 할 때 아파치.)

[편집] 지금까지 답변 해 주셔서 감사합니다. 나는 대답을 선택하기 전에 다른 사람이 무게를 측정하는지 확인하고 싶습니다. @ Raynos kinda의 대답은 내가 생각하는 것을 확인하고 주석 작성자의 링크가 생각에 좋은 음식을 제공했지만 다른 사람이 '문제 X에 노드를 사용하지 마십시오'와 같은 노드 특정 답변이 있는지 확인하고 싶습니다. '. (높은 CPU 작업 외에도; 이미 알고 있습니다 :-)

전통적인 웹 앱에서 Node.js를 피해야 할 이유가 있습니까?

예, 웹 플랫폼 X에서 N 년을 보유한 경우 플랫폼 X에서 더 빠르게 응용 프로그램을 개발할 수 있습니다.

Y를하고 플랫폼 X에 X를 수행하는 미리 만들어진 솔루션 Y가 있다면 그렇게하십시오.

한 플랫폼을 다른 플랫폼보다 사용해야하는 일반적인 모든 이유.

내부 비즈니스 응용 프로그램을 위해 구축 한 일종의 CRUD 앱?

네, 일반적인 애플리케이션을 더 빨리 작성할 수있는 다른 플랫폼이 있습니다.

그러나 그것은 말했다. 나는 노드에 대한 경험이 있으며 많은 양의 기능을 수행하지 않으면 노드 대신 다른 플랫폼을 선택할 것이라고 주장 할 수 없습니다.

기본적으로 그것은 간단한 질문입니다

나를 위해이 모든 것을 수행하는 도구가 있습니까? 그런 다음 가장 편리한 플랫폼을 선택하여 도구를 작성하십시오.

node.js가 불편한 플랫폼 인 이유는 확실하지 않습니다 (다른 경우 "자바 스크립트를 싫어합니다").

몇 주 동안 노드로 작업 한 후 매우 훌륭합니다. 그러나 방대한 웹 응용 프로그램을 대체하기 위해 사용하고 싶거나 imo로 의도 한 것은 아닙니다.

node는 자체 서버라는 것을 기억하십시오. 이것은 하나의 node.js 애플리케이션을 두 개 이상 실행하려는 경우 복잡성을 유발합니다. 즉, 컴퓨터에서 둘 이상의 사이트 / 도메인이 호스팅 된 경우입니다. LAMP 스택과 같지 않습니다. 여기서는 동일한 서버에서 실행되는 6 가지 도메인 (최소한 포트 80)에 대해 12 개의 PHP 응용 프로그램을 가질 수 있습니다. 아마도 가능하게하는 노드를위한 프레임 워크가 있지만, 전통적인 웹 플랫폼에 집착 할 때 필요하지 않은 복잡성을 추가합니다. (물론, 웹 서버를 노드 앞에 두어 프록시를 설정할 수도 있지만 노드 사용의 이점을 상실합니다.)

imo, Node는 전통적인 웹 서버 와 함께 사용 하기에 적합합니다. 내가 지금 구성하는 방법은 아파치를 통해 정적 html / js / image를 제공하고 노드 응용 프로그램에 오랫동안 폴링하여 '실시간'데이터 요구를 처리하는 것입니다.

노드에 대해 몇 초 동안 생각해야하는 좋은 이유는 기술적 인 것이 아닙니다. 그것이하는 일에 훌륭하고 놀랍습니다.

비즈니스 및 특히 인적 자본, 즉이를 아는 프로그래머, 비용 및 가용성. 배우기가 어렵지는 않지만 새로운 기술과 마찬가지로 잘 알고 있거나 많은 사람들이 더 많은 수의 근로자 집단에 속합니다.

이것은 매우 좋은 질문이며, 우리가 최첨단 기술을 발전시키기 위해서는 반드시 물어봐야합니다.

Node.JS의 한계가 어디에 있는지 (Paul d' Aoust와 같은) 알고 싶습니다. 안타깝게도 많은 답변이 주관적인 편견과 일시적으로 관련된 이론적 근거로 가득 차 있습니다.

나는 나 자신에게 물었다 : 우리는 대체 비아스를 걸러 내고이 관련 질문에 대한 견고한 답변을 얻을 수 있는가?

나머지 포인트는 다음과 같습니다.

1. NodeJS는 기존 프레임 워크만큼 성숙하지 않습니다. 폴 다우 스트 (Paul d' Aoust)가 제안한 바와 같이, 이것은 완전히 회피하기위한 것이 아니라 일시적으로 검토하고 실사하는 일시적인 이유 일뿐입니다. 웹 전문가로서 우리의 숙제를하는 것이 기대되며, 조직, 그들의 요구, 미래, 팀 (그리고 우리가 아닌)에 가장 적합한 기술을 결정하는 것이 우리의 임무입니다. 성숙도는 설명이 필요하고 위험에 대한 식욕에 대한 판단이지만 피하지는 않습니다.

2. 프록시 서버로서의 NodeJS. 사전 논의에 대한 현명한 제안은 검토와 고려할 가치가 있습니다. 프론트 엔드 인터페이스 프록시 디자인 패턴으로 기존 기술과 상관없이 Node를 사용한다는 개념입니다. 또한 노드를 사용하여 AVOID를 사용하지 않는 것이 아니라 전체 교체로 사용하지 않는 이유도 있습니다. 대신에 접근 방식을 선택하십시오.

3. 디버깅 노드. Joyent의 핵심 노드 개발자와의 대화에서 디버그 가능성과 관련하여 많은 복잡성이 있으며 코어로 인한 문제의 근본 원인을 추적합니다 (단일 스레드 실행 및 과거 스레드를 볼 수 없음). 이것은 고려하고 평가할 가치가 있지만 봉투를 밀 수있는 가장자리 케이스 만 일반적인 용도로 혐오하지는 않습니다. 특정 요구 사항이이 범주에 속할 수도 있고 그렇지 않을 수도 있습니다.

4. 인적 자원. 이것이이 페이지에서 JS 사용을 피하는 가장 좋은 이유이며, 겸손한 견해로는 엄청나고 불편한 진실입니다. 질문은 다음과 같습니다. 귀사에는 전체 수명주기를 통해 프로젝트를 볼 수있는 적합한 재능있는 전문가가 있습니까? 그렇지 않은 경우 NodeJS를 피해야한다는 의문의 여지가 없습니다. 또는 A) 올바른 재능 찾기 또는 B) 기존 재능 교육을 고려하십시오.

불만 사항 : JavaScript에 대한 불만 사항에 대한 관찰 결과는 많은 언어 오류가 일관되게 실패한 것보다 User Error의 결과가 더 많다는 것입니다. 우리는 "증오 JavaScript Diatribe"에 대한 많은 주장을 털어 놓고 더 많은 내용을 계속해서 밝힐 것입니다. 문서화가 충분하지 않고, 섹시하지는 않지만, 사람들이 그것을 좋아하지 않거나, 암이거나, 악마이거나, 너무 "오타하기 쉬운"(-CRichardson)과 같은 문제는 주관적이며 정확한 기업 의사 결정을 위해 제거해야하는 편향된 불만.

결국 정답은 AVOID NodeJS에 대한 정당한 이유가 없을 수 있습니다 . 아마도 이것이 빠른 성장, 채택 및 기여를 겪고있는 이유 일 것입니다. 그러나 우리 모두에게 아마도 여기서 해답은 NodeJS를 더 잘 평가, 연구 및 이해하고 구체적인 혐오감을 찾는 것입니다. Node.JS가 어디에서 미숙한지를 정확히 이해하기 위해 개방하기 위해, 우리는 그것을 더 잘 만들어야하는 곳을 정확하게 찾습니다. 그리고 그것은 축복입니다.

좋은 질문. 나는 누군가가 NodeJS를 피해야하는 더 좋은 이유를 제시하는 것에 대해 호기심을 가지고 있습니다.

비 실시간 응용 프로그램에 X보다 node를 사용하면 어떤 이점이 있습니까?

• 스케일링 : 노드의 성능은 좋지만 다른 플랫폼도 마찬가지입니다. PHP, Ruby, Python 및 Java는 모두 확장 가능합니다. 수백만 명의 사용자가 사용하는 BIG 이름을 찾을 수 있습니다.
• 프론트 엔드 및 백엔드를위한 하나의 언어 : Java의 "한 번만 쓰기"와 마찬가지로 농담
• 뜨겁고 섹시한 : 유일한 포인트. 그러나 아무도 귀하의 웹 사이트가 초초 기술을 사용하고 있다고 신경 쓰지 않습니다!

비 실시간 응용 프로그램에 X over Node 사용의 이점 :

• 모범 사례 : Node가 새롭기 때문에 특히 CRUD 웹 응용 프로그램에 대한 다른 플랫폼보다 모범 사례가 적습니다.
• 자바 스크립트 언어 : 사람들은 자바 스크립트를 좋아하지 않습니다. Node.js는 뜨겁지 만 Javascript는 그렇지 않습니다. 이것이 바로 사람들이 클라이언트 쪽에서도 Javascript를 작성하지 않도록 Coffeescript를 만든 이유입니다.
• 개발 속도 : Rails 및 Django를 포함하여 이에 국한되지 않는 오래되고 지루한 프레임 워크는 CRUD 웹 사이트에서 수년에 걸쳐 잘 테스트되고 개선되었습니다. Node에서 유사한 애플리케이션을 구현할 수 있지만 할아버지의 프레임 워크에서 수행하는 것이 더 쉽습니다.
• 안정성 : Node의 웹 프레임 워크가 빠른 속도로 향상되고 있습니다. 그것은 그들이 변화하고 있으며 가까운 시일 내에 더 많은 API 비 호환성을 가질 것임을 의미합니다.
• 라이브러리 및 도구 : 사용자가 많은 오래된 기술에는 더 많은 라이브러리 및 도구가 있습니다.

내 대답은 2015 년에는 확실히 유효하지 않습니다. 2014 년에는 비 실시간 웹 응용 프로그램의 경우 노드를 건너 뛰고 계속 주시하십시오.

모든 웹 프레임 워크에는 장점이 있습니다. 해당 시점에 사용하는 동안 행복 할 것입니다. 비 실시간 웹 응용 프로그램은 Node의 웹 프레임 워크가 아닙니다.

Node.js는 매우 인기있는 플랫폼이며 많은 흥미로운 기능을 가지고 있지만 도구 사용은 개인적인 취향입니다. Node.js를 네 번 받았고 만족하지 못했습니다. 여기 내 이유가 있습니다. 이러한 이유 중 일부는 오래되었거나 단순히 개인적인 것임을 명심하십시오.

• 나는 다른 언어 / 구문을 선호했습니다 (Python, Scala를 좋아합니다. 가장 좋아하는 언어는 Prolog입니다).
• 내가 사용한 프레임 워크 및 라이브러리의 문서 품질은 Java, Scala, Python 라이브러리에 적합하지 않습니다.
• nodejs의 디자이너는 이벤트 모델, 관찰자 ​​또는 선물 대신 콜백에 매우 집착합니다.
• 2005 년에 개발 된 Ruby, Python, Java에서 수행하려는 작업에 대한 준비가되어 있습니다. 구성 파일을 편집하면됩니다.

HTTP는 상태 비 저장이므로 비 실시간 웹 앱과 같은 것은 없으므로 모든 것에 노드를 사용할 수없는 이유는 없습니다.

즉, 노드는 특정 유형의 응용 프로그램 아키텍처에 더 적합합니다. PHP는 약간의 코드를 포함하는 html 파일입니다. 노드는 선택적으로 약간의 html을 포함하는 코드입니다.

즉, 앱이 클라이언트 쪽 스크립트가없는 표준 html 양식 인 경우 PHP가 더 쉬워집니다. 노드에는 템플릿 도구가 있지만 PHP와 같이 성숙하지는 않습니다.

많은 클라이언트 측 스크립트가 있고 데이터를 ajax로 저장하면 서버에서 정적 html 클라이언트 호출 함수로 끝납니다. 이것이 바로 노드가 잘하는 것입니다. CRUD 앱이 일반적으로 구축되는 방식은 아니지만 올바른 프레임 워크를 사용하여 멋진 것을 만들 수 있습니다.