나는 이런 종류의 일에 익숙하지 않지만 최근에 Node.js 가 얼마나 좋은지 많이 들었습니다. 일반적으로 jQuery와 JavaScript로 작업하는 것을 얼마나 좋아하는지 생각하면 Node.js를 언제 사용할지 결정하는 방법이 궁금하지 않을 수 없습니다. 내가 염두에 두고 있는 웹 응용 프로그램은 Bitly 와 같은 것입니다. 일부 콘텐츠를 가져와서 보관합니다.
지난 며칠간 해온 모든 숙제에서 다음과 같은 정보를 얻었습니다. 노드.js
일반 웹 서버로 실행할 수 있고 JavaScript 프로그램을 실행할 수 있는 명령줄 도구입니다.
Node.js는 Amazon의 EC2 인스턴스에서 거의 즉시 실행할 수 있다는 점을 고려하면 PHP , Python 및 Ruby 와 같은 강력한 왕과 달리 Node.js가 필요한 문제 유형을 이해하려고 합니다. . 나는 그것이 실제로 언어에 대한 전문 지식에 달려 있다는 것을 이해하지만 내 질문은 다음과 같은 일반적인 범주에 더 많이 속합니다. 특정 프레임워크를 언제 사용하고 어떤 유형의 문제에 특히 적합합니까?
Node.js의 멋진 점을 훌륭하게 요약했습니다. 내 생각에 Node.js는 브라우저에서 서버로의 지속적인 연결을 유지하려는 애플리케이션에 특히 적합합니다. "long-polling" 으로 알려진 기술을 사용하여 사용자에게 실시간으로 업데이트를 보내는 애플리케이션을 작성할 수 있습니다. Ruby on Rails 또는 Django 와 같은 많은 웹 거물에서 긴 폴링을 수행하면 각 활성 클라이언트가 하나의 서버 프로세스를 사용하기 때문에 서버에 엄청난 부하가 발생합니다. 이 상황은 타핏 공격에 해당합니다. Node.js와 같은 것을 사용할 때 서버는 열려 있는 각 연결에 대해 별도의 스레드를 유지할 필요가 없습니다.
즉, Node.js에서 많은 클라이언트에게 서비스를 제공하는 데 시스템 리소스를 거의 사용하지 않는 브라우저 기반 채팅 응용 프로그램 을 만들 수 있습니다. 이러한 종류의 긴 폴링을 수행하려는 경우 Node.js는 훌륭한 옵션입니다.
Ruby와 Python 모두 이러한 종류의 작업을 수행하는 도구( 각각 eventmachine 및 twisted )를 가지고 있지만 Node.js는 처음부터 이 작업을 매우 잘 수행합니다. JavaScript는 콜백 기반 동시성 모델에 매우 적합하며 여기에서 탁월합니다. 또한 클라이언트와 서버 모두에 기본 JSON을 사용하여 직렬화 및 역직렬화할 수 있다는 것은 매우 유용합니다.
여기에서 다른 답변을 읽기를 기대합니다. 이것은 환상적인 질문입니다.
Node.js는 클라이언트/서버 간극에서 많은 코드를 재사용하는 상황에서도 훌륭하다는 점을 지적할 가치가 있습니다. Meteor 프레임워크 는 이것을 정말 쉽게 만들고 많은 사람들이 이것이 웹 개발의 미래가 될 수 있다고 제안하고 있습니다. 경험상 Meteor에서 코드를 작성하는 것은 매우 재미있고, 이것의 큰 부분은 데이터를 재구성하는 방법에 대해 생각하는 데 시간을 덜 소비하므로 브라우저에서 실행되는 코드가 쉽게 그것을 조작하고 다시 전달하십시오.
저는 Node.js가 실시간 애플리케이션에 가장 적합하다고 생각합니다. 온라인 게임, 협업 도구, 대화방 또는 한 사용자(또는 로봇? 또는 센서?)가 애플리케이션으로 수행하는 모든 작업은 다른 사용자가 즉시 볼 수 있어야 합니다. 페이지 새로고침 없이.
Node.js와 함께 Socket.IO를 사용하면 긴 폴링으로 가능한 것보다 훨씬 더 실시간 대기 시간을 줄일 수 있다는 점도 언급해야 합니다. Socket.IO는 최악의 시나리오로 긴 폴링으로 대체되며 대신 웹 소켓 또는 사용 가능한 경우 Flash를 사용합니다.
그러나 스레드로 인해 코드가 차단될 수 있는 모든 상황은 Node.js로 더 잘 처리할 수 있다는 점도 언급해야 합니다. 또는 이벤트 기반 애플리케이션이 필요한 모든 상황.
또한 Ryan Dahl은 내가 한 번 참석한 강연에서 Node.js가 일반적인 오래된 HTTP 요청에 대해 Nginx와 밀접하게 경쟁한다고 말했습니다. 따라서 Node.js로 빌드하면 일반 리소스를 매우 효과적으로 제공할 수 있으며 이벤트 기반 항목이 필요할 때 처리할 수 있습니다.
게다가 항상 JavaScript입니다. 전체 스택의 링구아 프랑카.
fisherwebdev
NodeJS를 사용하는 이유:
Javascript를 실행하므로 서버와 클라이언트에서 동일한 언어 를 사용할 수 있으며 일부 코드를 공유할 수도 있습니다(예: 양식 유효성 검사 또는 양쪽 끝에서 보기 렌더링).
클라이언트 및 서버 측 라이브러리/모듈과 웹 개발을 위한 명령줄 도구를 포함하여 NPM을 통해 액세스할 수 있는 계속 증가하는 패키지 풀. 이들 대부분은 github에서 편리하게 호스팅되며, 때때로 문제를 보고하고 몇 시간 내에 수정된 것을 찾을 수 있습니다! 표준화된 문제 보고와 쉬운 분기를 통해 모든 것을 한 지붕 아래에 두는 것이 좋습니다.
Javascript 관련 도구 및 기타 웹 관련 도구( 태스크 러너, 미니파이어, 미화, 린터, 전처리기, 번들러 및 분석 프로세서 포함)를 실행하는 사실상의 표준 환경이 되었습니다.
프로토타이핑, 민첩한 개발 및 신속한 제품 반복에 매우 적합합니다.
NodeJS를 사용 하지 않는 이유:
컴파일 타임 유형 검사가 없는 Javascript를 실행합니다. 크고 복잡한 안전에 중요한 시스템 또는 다른 조직 간의 협업을 포함하는 프로젝트의 경우 계약 인터페이스 를 권장하고 정적 유형 검사를 제공하는 언어를 사용하면 장기적으로 디버깅 시간(및 폭발적 증가)을 줄일 수 있습니다. (JVM은 null 로 고정되어 있으므로 원자로에는 Haskell을 사용하십시오.)
이에 더해 NPM의 많은 패키지는 약간 원시적 이며 여전히 빠르게 개발되고 있습니다. 이전 프레임워크를 위한 일부 라이브러리는 10년 간의 테스트 및 버그 수정을 거쳤으며 지금 은 매우 안정적입니다.Npmjs.org에는 패키지를 평가할 수 있는 메커니즘이 없습니다 . 이로 인해 거의 동일한 작업을 수행하는 패키지가 확산되고 그 중 많은 비율이 더 이상 유지되지 않습니다.
계속 증가하는 패키지 풀은 하나의 NodeJS 프로젝트를 다음 프로젝트와 근본적으로 다르게 보이게 할 수 있습니다. 사용 가능한 옵션(예: Express/ Sails.js / Meteor / Derby )이 매우 많기 때문에 구현이 매우 다양합니다. 이것은 때때로 새로운 개발자가 Node 프로젝트에 뛰어드는 것을 어렵게 만들 수 있습니다. 기존 프로젝트에 참여하는 Rails 개발자와 대조해 보십시오 . 모든 Rails 앱이 유사한 구조 를 사용하도록 권장되기 때문에 그는 앱에 매우 빨리 익숙해질 수 있어야 합니다.
Node.js를 사용한 실제 예가 하나 있습니다. 내가 일하는 회사에는 간단한 정적 HTML 웹 사이트를 갖고 싶어하는 한 명의 클라이언트가 있습니다. 이 웹사이트는 PayPal을 사용하여 하나의 품목을 판매하기 위한 것으로 클라이언트도 판매된 품목의 양을 보여주는 카운터를 원했습니다. 클라이언트는 이 웹사이트에 엄청난 양의 방문자가 있을 것으로 예상했습니다. Node.js와 Express.js 프레임워크를 사용하여 카운터를 만들기로 결정했습니다.
Node.js 애플리케이션은 간단했습니다. Redis 데이터베이스에서 판매된 항목 금액을 가져오고 항목이 판매될 때 카운터를 늘리고 API 를 통해 사용자에게 카운터 값을 제공합니다.
이 경우 Node.js를 사용하기로 선택한 몇 가지 이유
그것은 매우 가볍고 빠릅니다. 이 웹사이트는 3주 동안 200000회 이상 방문했으며 최소한의 서버 리소스로 이 모든 것을 처리할 수 있었습니다.
카운터는 실시간으로 만들기 정말 쉽습니다.
Node.js는 구성하기 쉬웠습니다.
무료로 사용할 수 있는 모듈이 많이 있습니다. 예를 들어 PayPal용 Node.js 모듈을 찾았습니다.
이 경우 Node.js는 탁월한 선택이었습니다.
Joonas
Node를 사용하여 다음 프로젝트를 시작하는 가장 중요한 이유는 ...
모든 멋진 친구들은 그것으로 있습니다 ... 재미 있어야합니다 그래서.
쿨러에서 놀고 자랑할 노드 모험을 많이 할 수 있습니다.
클라우드 호스팅 비용과 관련하여 당신은 페니 핀처입니다.
Rails로 그 일을 수행했습니다.
IIS 배포를 싫어합니다.
귀하의 기존 IT 작업은 다소 지루해지고 있으며 반짝이는 새로운 스타트업에 있기를 원합니다.
뭘 기대 할까 ...
전혀 필요하지 않은 모든 서버 블로트웨어 없이 Express를 사용하면 안전함을 느낄 수 있습니다.
로켓처럼 달리고 잘 확장됩니다.
당신은 그것을 꿈. 당신이 그것을 설치했습니다. 노드 패키지 repo npmjs.org 는 세계에서 가장 큰 오픈 소스 라이브러리 생태계입니다.
Silver Bullet 같은 것은 없습니다. 모든 일에는 그에 따른 비용이 따릅니다. 기름진 음식을 먹으면 건강을 해치고 기름진 음식과 같은 향신료가 들어가지 않는 건강한 음식과 같습니다. 건강을 원하는지 음식처럼 향신료를 원하는지는 개인의 선택입니다. 동일한 방식으로 Node.js는 특정 시나리오에서 사용되는 것으로 간주합니다. 앱이 해당 시나리오에 맞지 않는 경우 앱 개발에 고려해서는 안 됩니다. 나는 단지 같은 생각을 하고 있습니다.
Node.JS를 사용하는 경우
서버 측 코드에 CPU 주기가 거의 필요하지 않은 경우. 다른 세계에서는 비 차단 작업을 수행하고 있으며 많은 CPU 사이클을 소비하는 무거운 알고리즘/작업이 없습니다.
Javascript 배경 출신이고 클라이언트 측 JS처럼 단일 스레드 코드를 작성하는 데 익숙하다면.
Node.JS를 사용하지 않는 경우
서버 요청은 CPU를 많이 사용하는 알고리즘/작업에 따라 다릅니다.
Node.JS의 확장성 고려 사항
Node.JS 자체는 기본 시스템의 모든 코어를 활용하지 않으며 기본적으로 단일 스레드이므로 멀티 코어 프로세서를 활용하고 멀티 스레드로 만들기 위해서는 직접 로직을 작성해야 합니다.
Node.JS 대안
Node.JS 대신 사용할 수 있는 다른 옵션이 있지만 Vert.x 는 꽤 유망한 것으로 보이며 polygot 및 더 나은 확장성 고려 사항과 같은 추가 기능이 많이 있습니다.
Ajay Tiwari
내가 Node.js를에 대해 언급하고있다 아무도 놀라운 커뮤니티, 패키지 관리 시스템 (NPM) 그리고 당신이 단순히 package.json 파일을 포함하여 포함 할 수 있다는 존재하는 모듈의 양입니다 생각하는 또 다른 좋은 점.
BoxerBucks
내 글: nodejs는 분석, 채팅 앱, API, 광고 서버 등과 같은 실시간 시스템을 만드는 데 아주 좋습니다. 젠장, 나는 nodejs와 socket.io를 사용하여 2시간 이내에 첫 채팅 앱을 만들었고 그것도 시험 주간에!
편집하다
nodejs를 사용하기 시작한 지 몇 년이 지났고 정적 파일 서버, 간단한 분석, 채팅 앱 등을 포함하여 많은 다른 것들을 만드는 데 사용했습니다. 이것은 nodejs를 언제 사용해야 하는지에 대한 나의 견해입니다.
사용 시기
동시성과 속도를 중시하는 시스템을 만들 때.
채팅 앱, IRC 앱 등과 같은 소켓 전용 서버
지리적 위치, 비디오 스트림, 오디오 스트림 등과 같은 실시간 리소스에 중점을 둔 소셜 네트워크
분석 웹앱처럼 작은 데이터 덩어리를 정말 빠르게 처리합니다.
REST 전용 API 노출로.
사용하지 않을 때
매우 다재다능한 웹 서버이므로 원하는 곳 어디에서나 사용할 수 있지만 이러한 장소에서는 사용할 수 없습니다.
간단한 블로그와 정적 사이트.
정적 파일 서버와 같습니다.
나는 단지 nitpicking하고 있음을 명심하십시오. 정적 파일 서버의 경우 Apache는 주로 널리 사용 가능하기 때문에 더 좋습니다. nodejs 커뮤니티는 수년에 걸쳐 더 커지고 성숙해졌으며 자신만의 호스팅 선택이 있다면 nodejs를 거의 모든 곳에서 사용할 수 있다고 말하는 것이 안전합니다.
shash7
어디에 사용할 수 있습니다
이벤트 중심적이고 I/O에 많이 의존하는 애플리케이션
다른 시스템에 대한 많은 수의 연결을 처리하는 애플리케이션
실시간 애플리케이션(Node.js는 처음부터 실시간으로 사용하기 쉽도록 설계되었습니다.)
다른 소스와 주고받는 정보 스트리밍을 저글링하는 애플리케이션
높은 트래픽, 확장 가능한 애플리케이션
많은 데이터 분석 없이 플랫폼 API 및 데이터베이스와 대화해야 하는 모바일 앱
네트워크 애플리케이션 구축
백엔드와 매우 자주 통신해야 하는 애플리케이션
모바일 분야에서 황금 시간대 기업은 모바일 솔루션을 위해 Node.js에 의존해 왔습니다. 이유를 확인하세요?
LinkedIn 은 저명한 사용자입니다. 그들의 전체 모바일 스택은 Node.js를 기반으로 합니다. 각 물리적 시스템에 15개의 인스턴스가 있는 15개의 서버를 실행하던 것에서 트래픽을 두 배로 처리할 수 있는 단 4개의 인스턴스로 변경했습니다!
eBay 는 Node.js를 런타임 스택으로 사용하는 HTTP API용 웹 쿼리 언어인 ql.io를 출시했습니다. 그들은 node.js 프로세스당 120,000개 이상의 활성 연결을 처리하도록 일반 개발자 수준의 Ubuntu 워크스테이션을 조정할 수 있었으며 각 연결은 약 2kB 메모리를 소비했습니다!
Walmart 는 Node.js를 사용하도록 모바일 앱을 재설계하고 JavaScript 처리를 서버에 푸시했습니다.
자, 이야기를 시작하겠습니다. 지난 2년 동안 저는 JavaScript 작업을 하고 웹 프론트 엔드를 개발하고 있으며 즐기고 있습니다. 백엔드 사람들은 우리에게 Java, python으로 작성된 API를 제공하고(우리는 상관하지 않습니다) AJAX 호출을 작성하고 데이터를 가져와 추측합니다! 우리는 끝났습니다. 하지만 실제로는 쉽지 않습니다. 만약 우리가 받고 있는 데이터가 정확하지 않거나 서버 오류가 있다면 우리는 멈추고 우리는 메일이나 채팅을 통해 백엔드 직원에게 연락해야 합니다(때로는 whatsApp에서도 :)). 멋지지 않다. API를 JavaScript로 작성하고 프런트 엔드에서 해당 API를 호출하면 어떻게 될까요? 예, API에서 문제가 발생하면 조사할 수 있기 때문에 매우 좋습니다. 뭔지 맞춰봐 ! 지금 할 수 있습니다 , 어떻게 ? – 노드는 당신을 위해 있습니다.
Ok는 JavaScript로 API를 작성할 수 있다는 데 동의했지만 위의 문제가 괜찮다면 어떻게 될까요? 나머지 API에 node를 사용하는 다른 이유가 있습니까?
여기 마법이 시작됩니다. 예, 우리 API에 노드를 사용해야 하는 다른 이유가 있습니다.
차단 작업이나 스레딩을 기반으로 하는 기존의 나머지 API 시스템으로 돌아가 보겠습니다. 두 개의 동시 요청이 발생한다고 가정합니다( r1 및 r2) . 각각 데이터베이스 작업이 필요합니다. 따라서 기존 시스템에서는 다음과 같은 일이 발생합니다.
1. Waiting Way : 우리 서버는 r1 요청을 처리하기 시작하고 쿼리 응답을 기다립니다. r1 완료된 후 r2 를 서비스하기 시작하고 동일한 방식으로 수행합니다. 시간이 많지 않기 때문에 기다리는 것은 좋은 생각이 아닙니다.
2. 스레딩 방식:r1 과 r2 모두에 대해 두 개의 스레드를 생성하고 데이터베이스를 쿼리한 후 해당 목적을 수행하므로 빠르게 냉각됩니다. 그러나 두 개의 스레드를 시작한 것을 볼 수 있기 때문에 메모리를 소모하며 두 요청 모두 쿼리할 때 문제가 증가합니다. 동일한 데이터를 사용하면 교착 상태 문제를 처리해야 합니다. 따라서 기다리는 것보다 낫지 만 여전히 문제가 있습니다.
이제 노드가 수행하는 방법은 다음과 같습니다.
3. Nodeway : 동일한 동시 요청이 노드에 오면 콜백으로 이벤트를 등록하고 특정 요청에 대한 쿼리 응답을 기다리지 않습니다. 따라서 r1 요청이 오면 노드의 이벤트 루프(예, 이벤트가 있습니다. 이 목적을 수행하는 노드의 루프.) 콜백 함수 r2 요청을 처리하기 위해 앞으로 이동하고 마찬가지로 해당 이벤트를 콜백으로 등록합니다. 쿼리가 완료될 때마다 해당 이벤트를 트리거하고 중단 없이 완료될 때까지 콜백을 실행합니다.
따라서 대기, 스레딩, 메모리 소비가 없습니다. 예, 이것은 나머지 API를 제공하기 위한 nodeway입니다.
Anshul
새 프로젝트에 Node.js를 선택하는 또 다른 이유는 다음과 같습니다.
순수 클라우드 기반 개발 가능
한동안 Cloud9 IDE를 사용해 왔으며 이제는 Cloud9 IDE 없이는 상상할 수 없습니다. 모든 개발 수명 주기를 다룹니다. 브라우저만 있으면 언제 어디서나 모든 장치에서 코딩할 수 있습니다. 집에서와 같이 한 컴퓨터에서 코드를 체크인한 다음 직장에서와 같이 다른 컴퓨터에서 체크아웃할 필요가 없습니다.
물론 다른 언어나 플랫폼을 위한 클라우드 기반 IDE가 있을 수 있지만(Cloud 9 IDE는 다른 언어에 대한 지원도 추가하고 있습니다.) Cloud 9를 사용하여 Node.js 개발을 수행하는 것은 저에게 정말 좋은 경험입니다.
Sean Zhao
노드가 제공하는 또 하나의 기능은 노드의 자식 프로세스( 각각 문서에 따라 10MB 메모리가 필요한 childProcess.fork())를 사용하여 노드의 여러 v8 인스턴스를 생성하는 기능이므로 서버를 실행하는 메인 프로세스에 영향을 미치지 않습니다. 따라서 엄청난 서버 부하를 필요로 하는 백그라운드 작업을 오프로딩하는 것은 어린아이의 장난이 되며 필요할 때 쉽게 제거할 수 있습니다.
나는 노드를 많이 사용해 왔으며 우리가 구축하는 대부분의 앱에서 동시에 서버 연결이 필요하므로 네트워크 트래픽이 많습니다. Express.js 및 새로운 Koaj (콜백 지옥을 제거한)와 같은 프레임워크는 노드 작업을 훨씬 더 쉽게 만들었습니다.
I_Debug_Everything
석면 롱존 입기...
어제 Packt Publications, Reactive Programming with JavaScript 에 대한 제 제목입니다. 이것은 실제로 Node.js 중심의 제목이 아닙니다. 초기 챕터는 이론을 다루기 위한 것이고 이후의 코드가 많은 챕터는 실습을 다루기 위한 것입니다. 독자에게 웹 서버를 제공하지 않는 것이 적절할 것이라고 생각하지 않았기 때문에 Node.js는 단연코 분명한 선택처럼 보였습니다. 케이스가 열리기도 전에 닫혀 있었습니다.
Node.js에 대한 내 경험에 대해 매우 장밋빛 관점을 제시할 수 있었습니다. 오히려 내가 만난 좋은 점과 나쁜 점에 대해 솔직하게 말했다.
여기에 관련된 몇 가지 인용문을 포함하겠습니다.
경고: Node.js와 그 생태계는 당신을 심하게 태울 만큼 뜨겁습니다!
내가 수학 교사의 조교였을 때, 내가 들었던 명확하지 않은 제안 중 하나는 학생에게 어떤 것이 "쉬운" 것이라고 말하지 말라는 것이었습니다. 그 이유는 돌이켜보면 다소 분명했습니다. 사람들에게 무언가가 쉽다고 말하면 해결책을 보지 못하는 사람은 결국 문제를 해결하는 방법을 알지 못할 뿐만 아니라 문제를 이해하지 못하기 때문에 (더욱) 어리석게 느낄 수도 있습니다. 그들은 너무 어리석어서 이해하기 쉽습니다!
Python / Django에서 오는 사람들을 귀찮게하지 않는 문제가 있습니다. 변경 사항이 있으면 즉시 소스를 다시로드합니다. Node.js를 사용하면 기본 동작은 한 가지를 변경하면 시간이 끝날 때까지 또는 수동으로 서버를 중지했다가 다시 시작할 때까지 이전 버전이 계속 활성화된다는 것입니다. 이 부적절한 행동은 Pythonistas만 짜증나게 하는 것이 아닙니다. 또한 다양한 해결 방법을 제공하는 기본 Node.js 사용자를 짜증나게 합니다. StackOverflow 질문 "Node.js의 파일 자동 다시 로드"는 이 글을 쓰는 시점에서 200개 이상의 찬성과 19개의 답변을 가지고 있습니다. 편집은 http://tinyurl.com/reactjs-node-supervisor 에 홈페이지가 있는 유모 스크립트 node-supervisor로 사용자를 안내합니다. 이 문제는 새로운 사용자가 문제를 해결했다고 생각하기 때문에 어리석게 느낄 수 있는 큰 기회를 제공하지만 이전의 버그가 있는 동작은 완전히 변경되지 않았습니다. 그리고 서버를 반송하는 것을 잊기 쉽습니다. 나는 여러 번 그렇게 했습니다. 그리고 제가 드리고 싶은 메시지는 "아니요, Node.js의 이러한 행동이 당신의 등을 물어뜯었기 때문에 당신은 바보가 아닙니다. Node.js의 디자이너는 여기서 적절한 동작을 제공할 이유가 없다고 생각합니다. 노드 감독자나 다른 솔루션의 도움을 받아 대처하려고 노력하지만 자신이 어리석다고 생각하지 마십시오. 문제가 있는 사람은 당신이 아닙니다. 문제는 Node.js의 기본 동작에 있습니다.”
이 섹션은 약간의 토론 끝에 "쉽다"라는 인상을 주고 싶지 않기 때문에 생략되었습니다. 나는 일을 처리하는 동안 반복적으로 손을 자르고, Node.js와 그 생태계가 잘 작동하도록 하는 것이 간단한 문제이고 그것이 당신에게도 간단하지 않다면 어려움을 부드럽게 넘기고 싶지 않습니다. , 당신은 당신이 무엇을하고 있는지 모릅니다. Node.js를 사용하여 불쾌한 문제에 부딪히지 않는다면 그것은 훌륭합니다. 그렇게 한다면 "나는 바보야. 나에게 뭔가 문제가 있는 게 틀림없어." Node.js를 다룰 때 불쾌한 놀라움을 경험했다면 바보가 아닙니다. 네가 아니야! Node.js와 생태계입니다!
마지막 장과 결론에서 상승하는 크레센도 이후에 내가 정말로 원하지 않았던 부록은 생태계에서 내가 찾을 수 있었던 것에 대해 이야기하고 멍청한 문자주의에 대한 해결 방법을 제공했습니다.
완벽해 보이지만 아직 사용할 수 있는 또 다른 데이터베이스는 HTML5 키-값 저장소의 서버 측 구현입니다. 이 접근 방식은 대부분의 우수한 프론트 엔드 개발자가 충분히 이해할 수 있는 API의 기본적인 이점을 가지고 있습니다. 그런 점에서 대부분의 좋지 않은 프론트엔드 개발자가 충분히 이해할 수 있는 API이기도 합니다. 그러나 node-localstorage 패키지를 사용하면 사전 구문 액세스가 제공되지 않지만(localStorage[key]가 아닌 localStorage.setItem(key, value) 또는 localStorage.getItem(key)를 사용하려는 경우) 전체 localStorage 의미 체계가 구현됩니다. , 기본 5MB 할당량 포함 — 왜? 서버 측 JavaScript 개발자는 스스로를 보호해야 합니까?
클라이언트 측 데이터베이스 기능의 경우 웹 사이트당 5MB 할당량은 개발자가 작업할 수 있는 매우 관대하고 유용한 공간입니다. 훨씬 더 낮은 할당량을 설정하고 개발자에게 쿠키 관리와 함께 절뚝거림에 대해 측정할 수 없는 개선을 제공할 수 있습니다. 5MB 제한은 빅 데이터 클라이언트 측 처리에 매우 빠르게 적합하지 않지만, 자원이 풍부한 개발자가 많은 작업을 수행하는 데 사용할 수 있는 정말 넉넉한 허용량이 있습니다. 그러나 반면에 5MB는 최근 구입한 대부분의 디스크에서 특히 큰 부분을 차지하지 않습니다. 즉, 귀하와 웹사이트가 디스크 공간을 합리적으로 사용하는 것에 대해 의견이 다르거나 일부 사이트가 단순히 허술한 경우 비용이 많이 들지 않습니다. 당신은 당신의 하드 드라이브가 이미 너무 가득 차 있지 않는 한 늪에 빠진 하드 드라이브의 위험에 처하지 않습니다. 균형이 조금 더 많거나 적으면 더 나을 수 있지만 전반적으로 클라이언트 측 컨텍스트의 본질적인 긴장을 해결하는 데는 괜찮은 솔루션입니다.
그러나 서버용 코드를 작성하는 사람이라면 데이터베이스를 허용 가능한 5MB 이상으로 만드는 추가 보호가 필요하지 않다는 점을 조심스럽게 지적할 수 있습니다. 대부분의 개발자는 유모 역할을 하고 5MB 이상의 서버 측 데이터를 저장하지 못하도록 보호하는 도구가 필요하지도 원하지도 않습니다. 그리고 클라이언트 측에서 골든 밸런싱 작업인 5MB 할당량은 Node.js 서버에서 다소 어리석습니다. (그리고 이 부록에서 다루는 것과 같이 여러 사용자를 위한 데이터베이스의 경우 각 사용자 계정에 대해 디스크에 별도의 데이터베이스를 생성하지 않는 한 사용자 계정당 5MB가 아니라는 점을 약간 고통스럽게 지적할 수 있습니다. 모든 사용자 계정을 함께 사용합니다. 입소문을 타면 고통스러울 수 있습니다!) 문서에는 할당량을 사용자 지정할 수 있다고 나와 있지만 일주일 전에 개발자에게 할당량을 변경하는 방법을 묻는 이메일은 답변이 없었습니다. . 내가 찾을 수 있었던 유일한 대답은 생성자에 대한 선택적 두 번째 정수 인수로 나열된 Github CoffeeScript 소스에 있습니다. 충분히 쉽고 디스크 또는 파티션 크기와 동일한 할당량을 지정할 수 있습니다. 그러나 의미가 없는 기능을 이식하는 것 외에도 이 도구의 작성자는 정수가 일부 리소스 사용에 대한 최대 제한을 지정하는 변수 또는 함수에 대해 0을 "무제한"을 의미하는 것으로 해석하는 매우 표준적인 규칙을 완전히 따르지 못했습니다. 이 오작동을 처리하는 가장 좋은 방법은 할당량을 무한대로 지정하는 것입니다.
if (typeof localStorage === 'undefined' || localStorage === null) { var LocalStorage = require('node-localstorage').LocalStorage; localStorage = new LocalStorage(__dirname + '/localStorage', Infinity); }
두 개의 주석을 순서대로 바꾸기:
사람들은 자바스크립트 전체를 끊임없이 사용하면서 불필요하게 스스로를 쏘았고, 자바스크립트가 존경받는 언어가 된 부분은 본질적으로 더글라스 크록포드(Douglas Crockford)가 말했습니다. 다음은 좋은 부분입니다. 다른 것이 있다는 것을 잊어버리십시오.” 아마도 뜨거운 Node.js 생태계는 자체 "Douglas Crockford"를 성장시킬 것입니다. 그는 "Node.js 생태계는 코딩 와일드 웨스트이지만 찾을 수 있는 진짜 보석이 있습니다. 다음은 로드맵입니다. 거의 모든 비용으로 피해야 할 영역이 있습니다. 다음은 모든 언어 또는 환경에서 찾을 수 있는 가장 풍부한 페이더트가 있는 영역입니다."
아마도 다른 누군가가 이 말을 도전으로 받아들이고 Crockford의 리드를 따라 Node.js 및 생태계에 대한 "좋은 부분" 및/또는 "더 나은 부분"을 작성할 수 있습니다. 나는 사본을 살 것입니다!
그리고 모든 프로젝트에 대한 열정과 순전한 노동 시간을 감안할 때 이 글을 쓰는 시점에서 미성숙한 생태계에 대한 어떤 발언도 날카롭게 누그러뜨리는 데 1, 2, 3년이 걸릴 수 있습니다. "2015 Node.js 생태계에는 여러 지뢰밭이 있었습니다. 2020 Node.js 생태계에는 여러 천국이 있습니다.”
Christos Hayward
애플리케이션이 주로 웹 API 또는 기타 io 채널을 연결하고 사용자 인터페이스를 제공하거나 사용하는 경우 node.js는 특히 최고의 확장성을 짜내고자 하는 경우 또는 인생의 주요 언어가 자바스크립트(또는 일종의 자바스크립트 트랜스파일러)입니다. 마이크로서비스를 구축한다면 node.js도 괜찮습니다. Node.js는 작거나 간단한 모든 프로젝트에도 적합합니다.
주요 판매 포인트는 프론트 엔드가 일반적인 분할이 아닌 백엔드 항목에 대한 책임을 지도록 허용한다는 것입니다. 또 다른 정당한 판매 포인트는 직원이 처음부터 자바스크립트 지향적인 경우입니다.
그러나 특정 지점을 넘어서면 모듈화, 가독성 및 흐름 제어를 강제하는 끔찍한 해킹 없이는 코드를 확장할 수 없습니다. 하지만 이러한 해킹을 좋아하는 사람들, 특히 이벤트 기반 자바스크립트 배경에서 오는 사람들은 친숙하거나 용서할 수 있는 것처럼 보입니다.
특히, 애플리케이션이 동기식 흐름을 수행해야 하는 경우 개발 프로세스 측면에서 상당히 느려지는 하프 베이크 솔루션에 대한 출혈이 시작됩니다. 응용 프로그램에 계산 집약적인 부분이 있는 경우 node.js만 신중하게 선택하십시오. 아마도 http://koajs.com/ 또는 다른 참신함은 내가 원래 node.js를 사용하거나 이것을 썼을 때와 비교하여 원래 어려운 측면을 완화합니다.
matanster
노드 js를 사용해야 하는 몇 가지 포인트를 공유할 수 있습니다.
채팅, 공동 편집과 같은 실시간 응용 프로그램의 경우 nodejs가 서버에서 클라이언트로 이벤트 및 데이터를 발생시키는 이벤트 기반이기 때문에 더 나은 방법입니다.
대부분의 사람들이 생각하는 자바스크립트 기반이라 간단하고 이해하기 쉽습니다.
현재 웹 애플리케이션의 대부분은 Angular js&backbone으로 가고 있으며 노드를 사용하면 둘 다 json 데이터를 사용하므로 클라이언트 측 코드와 쉽게 상호 작용할 수 있습니다.
많은 플러그인을 사용할 수 있습니다.
단점:-
노드는 대부분의 데이터베이스를 지원하지만 가장 좋은 것은 복잡한 조인 및 기타를 지원하지 않는 mongodb입니다.
컴파일 오류... 개발자는 오류 협정 응용 프로그램이 다시 이동하여 수동으로 시작하거나 자동화 도구를 사용하여 시작해야 하는 곳에서 작동을 멈춘 경우 다른 모든 예외를 처리해야 합니다.
결론: - Nodejs는 단순 및 실시간 응용 프로그램에 가장 적합합니다. 매우 큰 비즈니스 로직과 복잡한 기능이 있는 경우 nodejs를 사용하지 않는 것이 좋습니다. 채팅 및 모든 협업 기능과 함께 응용 프로그램을 구축하려는 경우.. 노드는 특정 부분에서 사용할 수 있으며 나머지는 편의 기술과 함께 가야 합니다.
BEJGAM SHIVA PRASAD
Node는 빠른 프로토타입에 적합하지만 복잡한 작업에는 다시는 사용하지 않을 것입니다. 나는 컴파일러와의 관계를 발전시키는 데 20년을 보냈고 확실히 그리워합니다.
Node는 한동안 방문하지 않은 코드를 유지 관리하는 데 특히 고통스럽습니다. 유형 정보 및 컴파일 시간 오류 감지는 좋은 것입니다. 그걸 왜 다 버려? 무엇을 위해? 그리고 젠장, 무언가가 남쪽으로 갈 때 스택 추적은 종종 완전히 쓸모가 없습니다.