Node.js 사용시기를 결정하는 방법?


2195

나는 이런 종류의 것들에 익숙하지 않지만 최근에는 Node.js 가 얼마나 좋은지에 대해 많이 들었습니다 . jQuery와 JavaScript로 작업하는 것을 얼마나 좋아하는지 고려할 때 Node.js를 언제 사용할지 결정하는 방법을 궁금해 할 수는 없습니다. 내가 염두에두고있는 웹 응용 프로그램은 Bitly비슷 합니다. 콘텐츠를 가져 와서 보관하십시오.

지난 며칠 동안 해왔 던 모든 숙제에서 다음과 같은 정보를 얻었습니다. Node.js

  • 일반 웹 서버로 실행할 수 있고 JavaScript 프로그램을 실행할 수있는 명령 줄 도구입니다.
  • 위대한 V8 JavaScript 엔진을 사용합니다
  • 동시에 여러 가지 일을해야 할 때 매우 좋습니다
  • 이벤트 기반이므로 멋진 Ajax 와 같은 모든 것을 서버 측에서 수행 할 수 있습니다.
  • 브라우저와 백엔드간에 코드를 공유 할 수 있습니다
  • 우리는 MySQL과 대화 할 수 있습니다

내가 찾은 소스 중 일부는 다음과 같습니다.

Node.js가 Amazon EC2 인스턴스에서 거의 기본적으로 실행될 수 있다는 점을 고려하여 PHP , PythonRuby 와 같은 강력한 왕과는 달리 Node.js에 어떤 유형의 문제가 필요한지 이해하려고합니다. . 나는 그것이 언어에 대한 전문 지식에 달려 있다는 것을 이해하지만 내 질문은 더 일반적인 범주에 속합니다. 특정 프레임 워크를 사용할 때와 어떤 유형의 문제가 특히 적합합니까?


4
이 질문은 메타 ( meta.stackoverflow.com/q/332386/497418 ) 에서 논의 입니다.
zzzzBov

답변:


1355

Node.js에 대한 멋진 점을 요약 한 훌륭한 작업을 수행했습니다. 내 느낌은 Node.js가 브라우저에서 서버로의 지속적인 연결을 유지하려는 응용 프로그램에 특히 적합하다는 것입니다. "long-polling" 이라는 기술을 사용하여 실시간으로 사용자에게 업데이트를 보내는 응용 프로그램을 작성할 수 있습니다. Ruby on Rails 또는 Django 와 같은 많은 웹 거대 기업에서 긴 폴링을 수행하면 각 활성 클라이언트가 하나의 서버 프로세스를 소비하기 때문에 서버에 막대한 부하가 발생합니다. 이 상황은 타르 핏 공격에 해당합니다. Node.js와 같은 것을 사용할 때 서버는 열린 각 연결에 대해 별도의 스레드를 유지할 필요가 없습니다.

이는 Node.js에서 많은 클라이언트에게 서비스를 제공하기 위해 시스템 리소스를 거의 사용하지 않는 브라우저 기반 채팅 응용 프로그램 을 만들 수 있음을 의미합니다 . 이런 종류의 긴 폴링을 원할 때마다 Node.js는 훌륭한 옵션입니다.

Ruby와 Python에는 모두 이러한 종류의 작업을 수행 할 수있는 도구 ( 이벤트 머신트위스티드 )가 있지만 Node.js는 예외적으로 잘 수행합니다. JavaScript는 콜백 기반 동시성 모델에 매우 적합하며 여기에서 뛰어납니다. 또한 클라이언트와 서버 모두에서 기본 JSON으로 직렬화 및 역 직렬화 할 수 있다는 것은 매우 멋진 일입니다.

나는 여기에 다른 답변을 읽을 수 있기를 기대합니다. 이것은 환상적인 질문입니다.

Node.js는 클라이언트 / 서버 간격에 걸쳐 많은 코드를 재사용하는 상황에서도 유용하다는 점을 지적 할 가치가 있습니다. 유성 프레임 워크는 정말 쉽게이를 만들고, 사람들의 많은이 웹 개발의 미래가 될 수 있습니다 제안합니다. 경험상 Meteor에서 코드를 작성하는 것은 정말 재미 있다고 말할 수 있습니다.이 중 상당 부분은 데이터를 재구성하는 방법에 대해 생각하는 데 적은 시간을 소비하므로 브라우저에서 실행되는 코드를 쉽게 사용할 수 있습니다 그것을 조작하고 다시 전달하십시오.

다음은 피라미드 및 롱 폴링에 관한 기사입니다.이 글은 gevent의 도움을 받아 TicTacToe 및 Long Polling with Pyramid 를 통해 매우 쉽게 설정할 수 있습니다.


12
예, 'node.js는 특히 브라우저에서 서버로 다시 연결해야하는 응용 프로그램에 적합하다고 생각하는 것이 매우 중요하다고 생각합니다. -채팅 프로그램 또는 대화식 게임과 같은 경우 '사용자 / 서버 통신이 필요하지 않은 응용 프로그램을 개발하는 경우 다른 프레임 워크를 사용하여 개발하는 것이 좋으며 시간이 훨씬 덜 걸립니다.
user482594

1
이 주셔서 감사합니다 ... 위대한 Q A는 ;-) 나는 또한 몇 가지 다른 사람을 통해 모두 앞면과 뒷면 엔드 개발을위한 하나 개의 좋은 기술을 마스터의 관점에서 그것에 대해 생각하는 것)
Stokedout

12
왜 긴 폴링을 사용합니까? 미래와 소켓은 어떻게 되었습니까?
hitautodestruct

1
나의 짧은 대답은 배경 과정입니다. 요청 및 응답 (휴식 API 포함)은 다른 언어 및 서버를 사용하여 수행 할 수 있습니다. 따라서 노드에서 웹 프로젝트를 변환하려는 사람들에게 적합합니다. 같은 것을 다시 생각하십시오! imap, 이미지 처리, 클라우드에 파일 업로드 또는 주로 이벤트 지향적 인
길거나

409

Node.js는 온라인 게임, 협업 도구, 대화방 또는 한 명의 사용자 (또는 로봇 또는 센서)가 해당 응용 프로그램으로 수행하는 작업이 다른 사용자에게 즉시 보여 져야하는 실시간 응용 프로그램에 가장 적합하다고 생각합니다. 페이지 새로 고침없이

또한 Node.js와 함께 Socket.IO를 사용하면 긴 폴링에서 가능한 것보다 실시간 대기 시간이 훨씬 줄어 듭니다. Socket.IO는 최악의 시나리오로 긴 폴링으로 돌아가고 대신 웹 소켓이나 플래시를 사용할 수 있습니다.

그러나 스레드로 인해 코드가 차단 될 수있는 상황은 Node.js로 더 잘 해결할 수 있다고 언급해야합니다. 또는 이벤트 중심의 응용 프로그램이 필요한 상황.

또한 Ryan Dahl은 Node.js 벤치 마크에서 기존의 오래된 HTTP 요청에 대해 Nginx와 거의 비슷한 벤치 마크에 참여한 적이 있다고 말했습니다. 따라서 Node.js로 빌드하면 일반 리소스를 매우 효과적으로 제공 할 수 있으며, 이벤트 중심의 자료가 필요할 때 처리 할 수 ​​있습니다.

또한 항상 모든 JavaScript입니다. 전체 스택에 Lingua Franca.


17
.Net과 Node 사이를 전환하는 사람의 관찰만으로도 시스템의 각 영역마다 다른 언어가 컨텍스트 전환시 많은 도움이됩니다. Javascript를 볼 때 클라이언트에서 일하고 있습니다 .C #은 App Server, SQL = 데이터베이스를 의미합니다. Javascript에서 일하면서 레이어를 혼동하거나 컨텍스트 전환에 더 오래 걸리는 것을 발견했습니다. 이것은 하루 종일 .NET 스택에서 작업하고 밤에는 Noding에서 발생하는 인공물 일 수 있지만 차이가 있습니다.
Michael Blackburn

9
흥미롭게도, 주류 문화와 원주민 문화 사이를 이동할 때 다문화 개인이 방언을 바꾸는 것을“코드 전환”이라고합니다.
Michael Blackburn

1
얼마 전 다른 .js파일에 다른 색상을 할당하는 방법에 대해 생각하고있었습니다 . 클라이언트 측의 경우 녹색, 서버 측의 경우 파란색 나는 "잃어버린"자신을 계속 받고있다
AJB

209

NodeJS를 사용해야하는 이유 :

  • Javascript를 실행하므로 서버와 클라이언트 에서 동일한 언어 를 사용하고 이들 사이에 코드를 공유 할 수도 있습니다 (예 : 양식 유효성 검사 또는 양쪽에서 뷰를 렌더링하기 위해).

  • 단일 스레드 이벤트 기반 시스템은 빠르게 기존의 멀티 스레드에 비해 한 번에 요청을 많이 처리하는 경우에도, 또한 간단한 자바 또는 ROR 프레임 워크.

  • 웹 개발을위한 명령 줄 도구뿐만 아니라 클라이언트 및 서버 측 라이브러리 / 모듈을 포함하여 NPM을 통해 액세스 할 수있는 꾸준한 패키지 풀 . 이들 중 대부분은 github에서 편리하게 호스팅되며 때로는 문제를보고하고 몇 시간 내에 문제를 해결할 수 있습니다! 표준화 된 문제보고 및 손쉬운 분기와 함께 모든 것을 한 지붕 아래에 두는 것이 좋습니다.

  • 태스크 실행기, 축소 기, 미화 기, 린터, 전 처리기, 번 들러 및 분석 프로세서를 포함하여 Javascript 관련 도구 및 기타 관련 도구 를 실행하는 사실상의 표준 환경이되었습니다 .

  • 프로토 타이핑, 민첩한 개발 및 신속한 제품 반복에 매우 적합합니다 .

NodeJS를 사용 하지 않는 이유 :

  • 컴파일 타임 유형 검사가없는 Javascript를 실행합니다. 크고 복잡한 안전에 중요한 시스템 또는 여러 조직 간의 협업을 포함한 프로젝트의 경우 계약 인터페이스 를 장려 하고 정적 유형 검사를 제공 하는 언어를 사용 하면 장기적으로 디버깅 시간 (및 폭발 )을 줄일 수 있습니다. (JVM이에 붙어 있지만 null핵 원자로에는 Haskell을 사용하십시오.)

  • 또한 NPM의 많은 패키지는 약간 원시적 이며 여전히 빠른 개발 중입니다. 이전 프레임 워크를위한 일부 라이브러리는 10 년 동안 테스트 및 버그 수정을 거쳤으며 현재까지 매우 안정적 입니다. Npmjs.org는 패키지를 평가하는 메커니즘이 없기 때문에 패키지 의 확산이 거의 일어나지 않아서 더 많은 비율이 유지되지 않습니다.

  • 중첩 된 콜백 지옥. (물론 이것에 대한 20 가지 솔루션 이 있습니다 ...)

  • 꾸준히 증가하는 패키지 풀은 하나의 NodeJS 프로젝트가 다음 프로젝트와 크게 다르게 보일 수 있습니다 . 사용 가능한 많은 옵션 (예 : Express / Sails.js / Meteor / Derby ) 으로 인해 구현에있어 다양성이 다양 합니다. 이로 인해 새로운 개발자가 Node 프로젝트에 참여하기가 더 어려워 질 수 있습니다. 기존 프로젝트에 참여하는 Rails 개발자 와는 대조적으로 : 모든 Rails 앱은 유사한 구조 를 사용하도록 권장되기 때문에 앱에 빠르게 익숙해 질 수 있어야합니다 .

  • 파일을 다루는 것은 약간의 고통이 될 수 있습니다. 텍스트 파일에서 줄을 읽는 것과 같이 다른 언어로 사소한 것은 Node.js 와 관련이 있으며 이상이 80 + upvotes 인 StackOverflow 질문이 있습니다. CSV 파일에서 한 번에 하나의 레코드를 읽는 간단한 방법없습니다 . 기타.

나는 NodeJS를 좋아합니다. 빠르고 신나고 재미 있습니다. 그러나 그것이 교정 가능성에 거의 관심이 없다는 것이 걱정됩니다. 우리가 궁극적으로 두 세계의 최고를 합칠 수 있기를 바랍니다. 나는 미래에 노드를 대체 할 것이 무엇인지보고 싶어합니다 ... :)


1
@nane 네, 나는 그 문제를 해결할 수 있다고 생각하지만 타입 안전 언어로 작성된 라이브러리 만 사용하도록 제한 하거나 모든 코드베이스 가 정적으로 입력 되지는 않는다는 것을 인정해야 합니다 . 그러나 한 가지 논거가 있습니다. 언어에 관계없이 코드에 대한 좋은 테스트 를 작성 해야하므로 동적으로 입력 된 코드의 경우 에도 신뢰 수준이 동일해야합니다 . 우리가 그 주장을 받아들이면 강력한 타이핑의 장점은 개발 / 디버깅 시간, 확률 및 최적화 를 돕는 것으로 줄어 듭니다 .
joeytwiddle

1
@kervin, 나는 일부 벤치 마크가 좋을 것이라고 동의하지만 온라인에서 찾을 수있는 것에 실망했습니다. 일부는 .NET 성능이 노드 와 비슷 하지만 실제로 수행하는 것이 중요하다고 주장했습니다. 노드는 많은 동시 연결로 작은 메시지를 전달하는 데는 좋지만 수학적 계산에는 적합하지 않습니다. 좋은 성능 비교는 다양한 상황을 테스트해야합니다.
joeytwiddle

2
@joeytwiddle은 더 큰 복잡한 프로그램과 정적 유형 검사를 처리 할 때 Typescript가 Node.js를 도와주지 않습니까?
CodeMonkey

2
@joeytwiddle의 가치에 대해서는 stillmaintained.com 을 사용 하여 npm 패키지가 여전히 유지되는지 여부를 확인할 수 있습니다 (대부분이 github에 있음). 또한, npm search그리고 npm show당신에게 패키지의 마지막 릴리스의 날짜를 표시합니다.
Dan Pantry

3
레일을 노드와 비교하면 플랫폼과 프레임 워크가 혼동됩니다. Rails는 Sails와 마찬가지로 Ruby의 프레임 워크이며 유성은 Javascript의 프레임 워크입니다.
BonsaiOak

206

짧게하려면 :

Node.js는 동시 연결이 많은 응용 프로그램에 매우 적합하며 함수 실행 중에 이벤트 루프 (다른 모든 클라이언트와 함께)가 차단되므로 각 요청마다 CPU주기가 거의 필요하지 않습니다.

Node.js의 이벤트 루프에 대한 좋은 기사는 Mixu의 기술 블로그 : node.js 이벤트 루프 이해 입니다.


127

Node.js를 사용한 실제 사례가 하나 있습니다. 내가 일하는 회사에는 간단한 정적 HTML 웹 사이트를 갖고 싶어하는 고객이 있습니다. 이 웹 사이트는 PayPal을 사용하여 하나의 품목을 판매하기위한 것이며 고객은 또한 판매 된 품목의 양을 보여주는 카운터를 원했습니다. 고객은이 웹 사이트를 방문 할 사람이 많을 것으로 예상했습니다. Node.js와 Express.js 프레임 워크를 사용하여 카운터를 만들기로 결정했습니다 .

Node.js 애플리케이션은 간단했습니다. Redis 데이터베이스 에서 판매 품목 수량을 가져 오고 품목 판매시 카운터를 늘리고 API 를 통해 사용자에게 카운터 값을 제공하십시오 .

이 경우 Node.js를 사용하기로 선택한 몇 가지 이유

  1. 매우 가볍고 빠릅니다. 3 주 동안이 웹 사이트를 방문한 횟수는 200000 회이며 최소한의 서버 리소스만으로도이 모든 것을 처리 할 수 ​​있습니다.
  2. 카운터는 실시간으로 만들기가 정말 쉽습니다.
  3. Node.js는 쉽게 구성 할 수있었습니다.
  4. 무료로 사용할 수있는 많은 모듈이 있습니다. 예를 들어 PayPal 용 Node.js 모듈을 찾았습니다.

이 경우 Node.js는 훌륭한 선택이었습니다.


7
어떻게 그런 식으로 호스트합니까? 그런 다음 프로덕션 서버에서 nodejs를 설정해야합니까? 리눅스에서?
미구엘 스티븐스

1
nodejitsu 및 Heroku와 같은 몇 가지 PaaS가 있습니다. 또는 실제로 Linux 상자, 즉 Amazon EC2에서 nodejs를 설정할 수 있습니다. 참조 : lauradhamilton.com/…
harry young

13
1,814,400 초 내에 200,000 회의 방문 전혀 관련이 없습니다. bash조차도 가장 느린 서버에서 많은 요청을 처리 할 수 ​​있습니다. 스크래치 서버. 가장 느린 VM.
Tiberiu-Ionuț Stan

105

노드를 사용하여 다음 프로젝트를 시작해야하는 가장 중요한 이유 ...

  • 모든 멋진 친구들이 여기에 있습니다 ... 그래서 재미 있어야 합니다.
  • 쿨러에서 행 아웃을하고 자랑 할 노드 모험을 많이 할 수 있습니다.
  • 클라우드 호스팅 비용과 관련하여 페니 핀처입니다.
  • Rails로 그렇게 했습니까?
  • 당신은 IIS 배포를 싫어
  • 기존 IT 작업이 다소 어려워지고 있으며 새롭고 빛나는 시작을 원합니다.

뭘 기대 할까 ...

  • 필요하지 않은 모든 서버 블로 트웨어없이 Express를 사용하여 안전하고 안전하게 느낄 수 있습니다.
  • 로켓처럼 뛰며 잘 확장됩니다.
  • 당신은 그것을 꿈꿉니다. 설치했습니다. 노드 패키지 repo npmjs.org 는 세계에서 가장 큰 오픈 소스 라이브러리 에코 시스템입니다.
  • 중첩 된 콜백의 땅에서 뇌가 뒤 틀릴 것입니다 ...
  • ... 약속 을 지키는 법을 배울 때까지 .
  • SequelizePassport 는 새로운 API 친구입니다.
  • 주로 비동기 코드를 디버깅하면 재미 있을 것 입니다.
  • 모든 Noder가 Typescript 를 마스터하기위한 시간 .

누가 사용합니까?

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • 이들이 Node로 전환 한 이유는 다음과 같습니다 .

18
예, 나는 전통적인 방식으로이 질문에 대답 할 수있었습니다. 나는 그렇게 할 자격이 있다고 생각하지만 대부분이 이미 언급되었으며 가벼운 마음의 재미가 단조 로움을 깨뜨릴 것이라고 생각했습니다. 다른 질문에 대해서는 정기적으로 기술 답변을 제공합니다.
Tony O'Hagan

1
중첩 된 콜백은 비동기 코드 ES6 생성기를 사용하여 방지 할 수 있습니다
리팩토링

1
@CleanCrispCode : 그렇습니다! ES6는 C #을 스타일을 채택했습니다 async/ await그래서 지금 우리는 또한 기존의 지원 노드 코드 비동기 많은 청소기 출시 할 수 try/을 catch. 2016/17 년에 JS 코더는 ES6로 전환하고 있습니다.
Tony O'Hagan

1
수만 번 "이것은 당신이 결코 필요하지 않은 모든 서버 bloatware없이 Express로 안전하고 안전하다고 느낄 것입니다"
Simone Poggi

60

Silver Bullet과 같은 것은 없습니다. 모든 것은 관련 비용이 함께 제공됩니다. 기름진 음식을 먹는 것과 마찬가지로 건강에 해를 끼치며 건강한 음식에는 기름진 음식과 같은 향신료가 없습니다. 그들이 음식 에서처럼 건강이나 향신료를 원하는지 여부는 개인의 선택입니다. 특정 시나리오에서 Node.js를 사용하는 것과 같은 방법입니다. 앱이 해당 시나리오에 맞지 않으면 앱 개발을 위해 고려해야합니다. 나는 단지 내 생각을 동일하게 생각하고 있습니다.

Node.JS를 사용하는 경우

  1. 서버 측 코드에 CPU 사이클이 거의 필요하지 않은 경우. 다른 세계에서는 비 차단 작업을 수행하고 많은 CPU주기를 소비하는 무거운 알고리즘 / 작업이 없습니다.
  2. Javascript를 기반으로하고 클라이언트 측 JS처럼 단일 스레드 코드를 작성하는 데 익숙한 경우.

Node.JS를 사용하지 않을 때

  1. 서버 요청은 많은 CPU 소비 알고리즘 / 작업에 의존합니다.

Node.JS를 통한 확장 성 고려 사항

  1. Node.JS 자체는 기본 시스템의 모든 코어를 사용하지는 않으며 기본적으로 단일 스레드이므로 멀티 코어 프로세서를 활용하고 멀티 스레드로 만들려면 자체적으로 논리를 작성해야합니다.

Node.JS 대안

Node.JS 대신 사용할 다른 옵션이 있지만 Vert.x 는 꽤 유망한 것으로 보이며 polygot 및 더 나은 확장 성 고려 사항과 같은 추가 기능이 많이 있습니다.


24
"사용하지 않을 때"에 "서버 측 요청에 File IO 또는 Socket IO와 같은 차단 작업이 포함되어 있는지"가 확실하지 않습니다. 내 이해가 옳다면 node.js의 강점 중 하나는 차단하지 않고 IO를 처리하는 강력한 비동기 수단을 가지고 있다는 것입니다. 따라서 Node.js는 IO 차단을위한 "치료법"으로 볼 수 있습니다.
Ondrej Peterka

3
@ OndraPeterka : Node.js가 서버 IO를 차단하는 것은 옳은 일이지만 서버의 요청 핸들러가 다른 웹 서비스 / 파일 작업을 차단 호출하는 경우 Node.js가 도움이되지 않습니다. 서버로 들어오는 요청에 대해서만 IO를 차단하지는 않지만 앱 요청 핸들러에서 나가는 요청에 대해서는 IO를 차단하지 않습니다.
Ajay Tiwari 2016 년

4
에서 @ajay nodejs.org 그들이 말하는, 당신의 "때 NOT"2, 3 확인하세요 "I / O 비 차단"
오마르 알 - Ithawi

5
현재 버전에서 노드는 실제로 클러스터를 사용하여 멀티 코어 지원을 지원합니다. 이것은 실제로 노드 앱 성능을 두 배 이상 향상시킵니다. 그러나 클러스터 lib를 안정화하면 성능이 두 배 이상 높아야한다고 생각합니다.
Nam Nguyen

4
무거운 계산에 node.js를 사용할 수 있습니다. 사용하십시오 fork. stackoverflow.com/questions/9546225/…를 참조하십시오 . 노드는 cluster모듈로 여러 코어를 잘 처리 합니다. nodejs.org/api/cluster.html
Jess

41

또 다른 좋은 점은 내가 생각 Node.js를에 대해 언급하고있다 아무도 놀라운 커뮤니티, 패키지 관리 시스템 (NPM) 그리고 당신이 단순히 package.json 파일을 포함하여 포함 할 수 있다는 존재하는 모듈의 양입니다.


6
그리고이 패키지는 모두 비교적 신선하므로, 뒤늦은 이점이 있으며 최신 웹 표준을 따르는 경향이 있습니다.
joeytwiddle

3
npm에는 패키지를 평가할 메커니즘이 없기 때문에 npm 의 많은 패키지는 끔찍 합니다 . CPAN 누구의 힌트 ?
Dan Dascalescu

너무 나쁜 웹 소켓 라이브러리는 rfc 6455 사양을 충족시킬 수 없습니다. 이 사실이 알려지면 node.js fanboys는 귀머거리, 멍청한 및 장님입니다.
r3wt

1
주석을 언제 작성했는지 모르지만 현재로서는 ws 라이브러리가 해당 사양을 지원합니다.
Jonathan Gray

37

내 작품 : nodejs는 분석, 채팅 앱, api, 광고 서버 등과 같은 실시간 시스템을 만드는 데 좋습니다. 지옥, 시험 시간 동안 nodejs와 socket.io를 사용하여 첫 채팅 앱을 만들었습니다.

편집하다

nodejs를 사용하기 시작한 지 몇 년이 지났으며 정적 파일 서버, 간단한 분석, 채팅 앱 등을 포함하여 여러 가지를 만드는 데 사용했습니다. 이것은 nodejs를 사용할 때 가져가는 것입니다.

사용시기

동시성과 속도에 중점을 둔 시스템을 만들 때.

  • 채팅 앱, irc 앱 등과 같은 서버 만 소켓
  • 지리적 위치, 비디오 스트림, 오디오 스트림 등과 같은 실시간 리소스에 중점을 둔 소셜 네트워크
  • 분석 웹앱처럼 작은 데이터 덩어리를 빠르게 처리합니다.
  • REST 만 api를 노출시킵니다.

사용하지 않을 때

매우 다양한 웹 서버이므로 원하는 곳에서 사용할 수 있지만 아마도이 곳에서는 사용할 수 없습니다.

  • 간단한 블로그 및 정적 사이트.
  • 정적 파일 서버와 같습니다.

나는 단지 nitpicking입니다 명심하십시오. 정적 파일 서버의 경우 아파치는 주로 사용 가능하므로 더 좋습니다. nodejs 커뮤니티는 수년에 걸쳐 점점 커지고 성숙해졌으며, 자신이 원하는 호스팅 옵션이 있다면 거의 모든 곳에서 nodejs를 사용할 수 있다고 말하는 것이 안전합니다.


간단한 블로그는 여전히 Node.js의 혜택을 누릴 수 있습니다. 정적 파일을 제공하기 위해 여전히 Node.js를 사용할 수 있으며로드가 증가하면 현재 모범 사례에 따라 Nginx 리버스 프록시를 추가하십시오. Apache httpd 서버는 죽어가는 공룡입니다 . 이 Netcraft 설문 조사를 참조하십시오 .
Endrju

나는 그렇지 않다고 말할 것입니다 -ghost.org를 보고, 놀랍게 보이며 NodeJs의 공동 작업, 실시간 기사 편집을 기반으로합니다. 또한, sailsjs.org를 사용하는 등 NodeJs 에서 간단한 페이지를 작성하는 것은 쉽고 빠르며 서버 측 프로그래밍 언어를 배우는 데 신경을 쓸 필요가 없습니다.
Bery

30

어디에서나 사용할 수 있습니다

  • 높은 이벤트 주도형 및 I / O가 많은 애플리케이션
  • 다른 시스템에 대한 많은 수의 연결을 처리하는 응용 프로그램
  • 실시간 애플리케이션 (Node.js는 처음부터 실시간으로 설계되어 사용하기 쉽도록 설계되었습니다.)
  • 다른 소스로 또는 다른 소스로 스트리밍되는 수많은 정보를 저글링하는 응용 프로그램
  • 트래픽이 많고 확장 가능한 응용 프로그램
  • 많은 데이터 분석을하지 않고도 플랫폼 API 및 데이터베이스와 통신해야하는 모바일 앱
  • 네트워크 응용 프로그램 구축
  • 백엔드와 매우 자주 대화해야하는 애플리케이션

모바일 업계에서 프라임 타임 회사는 모바일 솔루션으로 Node.js를 사용했습니다. 이유를 확인 하시겠습니까?

LinkedIn 은 저명한 사용자입니다. 전체 모바일 스택은 Node.js를 기반으로합니다. 각 물리적 시스템에서 15 개의 인스턴스가있는 15 대의 서버를 실행하는 것에서 2 개의 트래픽을 처리 할 수있는 4 개의 인스턴스로 전환했습니다!

eBay 는 HTTP API 용 웹 쿼리 언어 인 ql.io를 시작하여 Node.js를 런타임 스택으로 사용합니다. 그들은 정규 개발자 품질의 Ubuntu 워크 스테이션을 조정하여 node.js 프로세스 당 120,000 개 이상의 활성 연결을 처리 할 수 ​​있었으며 각 연결은 약 2kB 메모리를 소비했습니다!

Walmart 는 Node.js를 사용하도록 모바일 앱을 리엔지니어링하고 JavaScript 처리를 서버로 푸시했습니다.

http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/ 에서 자세히 알아보십시오 .


20

동시 요청 처리에 가장 적합한 노드-

이야기부터 시작하겠습니다. 지난 2 년 동안 저는 JavaScript를 개발하고 웹 프론트 엔드를 개발하고 있으며 즐기고 있습니다. 백엔드 녀석은 Java, Python으로 작성된 API를 제공합니다 (우리는 상관하지 않습니다). 우리는 단순히 AJAX 호출을 작성하고 데이터를 가져 와서 무엇을 추측합니다! 우리는 끝났습니다. 그러나 실제로 그렇게 쉬운 일이 아닙니다. 우리가 얻는 데이터가 정확하지 않거나 서버 오류가 발생하면 우리는 붙어 있거나 메일이나 채팅을 통해 백엔드 사람들에게 연락해야합니다 (때로는 whatsApp에서도 :).) 시원하지 않습니다. JavaScript로 API를 작성하고 프론트 엔드에서 해당 API를 호출하면 어떻게됩니까? 예, API에서 문제가 발생하면 살펴볼 수 있기 때문에 꽤 멋집니다. 뭔지 맞춰봐 ! 당신은 지금 이것을 할 수 있습니다, 어떻게? – 노드가 당신을 위해 있습니다.

Ok는 JavaScript로 API를 작성할 수 있다고 동의했지만 위의 문제로 괜찮다면 어떻게해야합니까? rest API에 node를 사용해야하는 다른 이유가 있습니까?

마법이 시작됩니다. 예, API에 노드를 사용해야하는 다른 이유가 있습니다.

블로킹 작업 또는 스레딩을 기반으로하는 기존의 rest API 시스템으로 돌아가 보겠습니다. 두 개의 동시 요청 (r1 및 r2)이 발생한다고 가정하면 각각 데이터베이스 작업이 필요합니다. 따라서 전통적인 시스템에서 어떤 일이 일어날까요?

1. 대기 방법 : 서버가 r1요청 처리를 시작하고 쿼리 응답을 기다립니다. 완료 후 r1서버가 서비스를 시작하고 r2동일한 방식으로 수행합니다. 대기 시간은 많지 않기 때문에 좋은 생각이 아닙니다.

2. 스레딩 방식 : 서버는 요청에 대해 두 개의 스레드를 생성 r1하고 r2데이터베이스를 쿼리 한 후 목적을 제공하므로 빠르게 냉각합니다. 그러면 교착 상태 문제를 처리해야합니다. 그래서 기다리는 방법보다 낫지 만 여전히 문제가 있습니다.

이제 여기에 노드가 수행하는 방법이 있습니다.

3. Nodeway : 동일한 동시 요청이 노드에 들어 오면 콜백으로 이벤트를 등록하고 특정 요청에 대한 쿼리 응답을 기다리지 않기 때문에 r1요청이 오면 노드의 이벤트 루프 (예 : 이벤트 루프가 있음) 콜백 기능을 사용 r2하여 이벤트를 등록하고 요청 을 처리하기 위해 계속 진행 하고 해당 이벤트를 콜백에 등록하십시오. 쿼리가 완료 될 때마다 해당 이벤트가 트리거되고 중단되지 않고 완료 될 때까지 콜백을 실행합니다.

따라서 대기, 스레딩, 메모리 소비 없음 – 예, 나머지 API를 제공하기위한 노드입니다.


1
안녕하세요 안설. 스레드 방식으로 교착 상태가 발생할 수있는 방법에 대한 일부 리소스를 설명하거나 제안 할 수 있습니까
jsbisht

16

또 하나의 이유는 새로운 프로젝트에 대한 Node.js를 선택 할 수있다 :

순수한 클라우드 기반 개발 가능

Cloud9 IDE 를 한동안 사용해 왔지만 지금은 상상할 수 없으며 모든 개발 수명주기를 다룹니다. 브라우저 만 있으면 모든 장치에서 언제 어디서나 코딩 할 수 있습니다. 한 컴퓨터 (예 : 집)에서 코드를 체크인 한 다음 다른 컴퓨터 (예 : 직장)에서 코드를 체크인 할 필요가 없습니다.

물론 다른 언어 또는 플랫폼을위한 클라우드 기반 IDE가있을 수 있지만 (Cloud 9 IDE는 다른 언어에 대한 지원도 추가하고 있음) Cloud 9를 사용하여 Node.js 개발을 수행하는 것은 정말 좋은 경험입니다.


1
실제로 Cloud9 IDE와 다른 것 (내가 사용하는 코드)은 거의 모든 종류의 웹 언어를 지원합니다.
Wanny Miarelli

7
당신은 진지한 친구입니까? 이것이 스택을 선택하기위한 기준입니까? :) 그것은 당신을 위해 일하고 행복합니다!
matanster

15

노드가 제공하는 또 하나의 기능은 노드의 자식 프로세스 ( 각각 문서 당 10mb 메모리가 필요한 childProcess.fork ())를 사용하여 여러 v8 인스턴스 노드를 생성 하여 서버를 실행하는 기본 프로세스에 영향을 미치지 않는 기능입니다. 따라서 서버로드가 많이 필요한 백그라운드 작업을 오프로드하면 어린이 놀이가되고 필요할 때 쉽게 죽일 수 있습니다.

나는 노드를 많이 사용했으며 우리가 빌드하는 대부분의 앱에서 동시에 서버 연결이 필요하므로 네트워크 트래픽이 많이 발생합니다. Express.js 및 새로운 Koajs (콜백 지옥을 제거함) 와 같은 프레임 워크 는 노드 작업을 훨씬 쉽게 해줍니다.


15

석면 Longjohns을 착용 ...

어제 Packt 간행물, 내 제목 자바 스크립트와 반응성 프로그래밍 . 실제로 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.js의 이러한 행동이 당신의 등을 물었 기 때문에 당신은 바보가 아닙니다. Node.js의 디자이너가 여기서 적절한 동작을 제공 할 이유가 없다는 것입니다. 노드 수퍼바이저 나 다른 솔루션의 도움을받을 수도 있지만 어리석은 느낌을 버리지 마십시오. 당신은 문제를 가진 사람이 아닙니다. 문제는 Node.js의 기본 동작에 있습니다.”

이 섹션은 약간의 토론 후에“쉽습니다”라는 인상을주고 싶지 않기 때문에 남겨졌습니다. 일을하면서 반복해서 손을 difficulties 다가 어려움을 극복하고 Node.js와 생태계가 제대로 작동하도록하는 것이 간단한 문제이고 너무 간단하지 않다고 생각하도록 설정하고 싶지 않습니다. , 당신은 무엇을하고 있는지 모른다. Node.js를 사용하는 데 어려움을 겪지 않는다면 훌륭합니다. 당신이 그렇게한다면, 나는 당신이“나는 바보입니다. 나에게 문제가있을 것입니다.”라는 느낌을 버리지 않기를 바랍니다. Node.js를 다루는 놀라운 놀라움을 경험한다면 어리석지 않습니다. 네가 아니야! Node.js와 생태계입니다!

마지막 장에서 크레센도가 올라간 후 실제로 원하지 않는 부록과 결론은 생태계에서 찾을 수 있었던 것에 대해 이야기하고 모 론적 리터럴 리즘에 대한 해결 방법을 제공했습니다.

완벽하게 맞는 것처럼 보이고 아직 사용할 수있는 또 다른 데이터베이스는 HTML5 키-값 저장소의 서버 측 구현입니다. 이 접근 방식은 가장 우수한 프론트 엔드 개발자가 충분히 이해하는 API의 장점이 있습니다. 그 점에서, 그것은 좋지 않은 프론트 엔드 개발자가 충분히 이해하는 API이기도합니다. 그러나 노드 로컬 스토리지 패키지를 사용하면 사전 구문 액세스가 제공되지 않지만 (localStorage [key]가 아닌 localStorage.setItem (key, value) 또는 localStorage.getItem (key)를 사용하려는 경우) 전체 localStorage 시맨틱이 구현됩니다. 기본 5MB 할당량을 포함하여- 왜? 서버 측 JavaScript 개발자를 자신으로부터 보호해야합니까?

클라이언트 측 데이터베이스 기능의 경우 웹 사이트 당 5MB 할당량은 개발자가 작업 할 수있는 관대하고 유용한 호흡 공간입니다. 할당량을 훨씬 더 낮게 설정해도 쿠키 관리와 함께 절뚝 거림보다 개선 할 수없는 성능을 개발자에게 제공 할 수 있습니다. 5MB 제한은 Big Data 클라이언트 측 처리에 그다지 빠르게 적용되지는 않지만 풍부한 개발자가 많은 작업을 수행 할 수있는 매우 관대 한 여유가 있습니다. 그러나 반면에 5MB는 최근에 구입 한 대부분의 디스크 중 특히 큰 부분은 아닙니다. 즉, 귀하와 웹 사이트가 디스크 공간의 합리적인 사용에 대해 동의하지 않거나 일부 사이트가 단순히 호기심을 느끼면 실제로 비용이 들지 않습니다. 하드 드라이브가 이미 가득 차 있지 않으면 하드 드라이브가 휩쓸 릴 위험이 없습니다.

그러나 서버용 코드를 작성하는 경우 데이터베이스를 허용 가능한 5MB 이상의 크기로 만드는 것으로부터 추가적인 보호가 필요하지 않다는 점이 부드럽게 지적 될 수 있습니다. 대부분의 개발자는 보모 역할을하고 5MB 이상의 서버 측 데이터를 저장하지 못하게하는 도구가 필요하지도 않습니다. 그리고 클라이언트 측에서 골든 밸런싱 행위 인 5MB 할당량은 Node.js 서버에서 약간 어리 석습니다. (그리고이 부록에서 다룬 여러 사용자를위한 데이터베이스의 경우, 각 사용자 계정에 대해 디스크에 별도의 데이터베이스를 만들지 않는 한 사용자 계정 당 5MB가 아니라는 점이 약간 아 slightly습니다. 모든 사용자 계정이 함께 있습니다. 고통 스러울 수 있습니다바이러스 성이라면!) 문서에는 할당량을 사용자 지정할 수 있지만, 일주일 전에 개발자에게 할당량 변경 방법을 묻는 전자 메일에 대한 답변이 없습니다. 내가 찾은 유일한 대답은 Github CoffeeScript 소스에서 생성자에 대한 선택적 두 번째 정수 인수로 나열됩니다. 따라서 충분히 쉬우 며 디스크 또는 파티션 크기와 동일한 할당량을 지정할 수 있습니다. 그러나 의미가없는 기능을 포팅하는 것 외에도, 툴의 저자는 0이 자원이나 리소스 사용에 대한 최대 제한을 지정하는 변수 나 함수에 대해 "무제한"을 의미하는 것으로 해석하는 표준 규칙을 완전히 따르지 못했습니다. 이 기능을 사용하지 않는 가장 좋은 방법은 할당량이 무한대임을 지정하는 것입니다.

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

두 개의 주석을 순서대로 교환 :

사람들은 불필요하게 지속적으로 JavaScript 전체를 사용하여 발을 내딛었습니다. JavaScript가 존경받는 언어로 된 부분은 본질적으로 더글러스 크록 포드 (Doglas Crockford)였습니다. 좋은 부분은 다음과 같습니다. 다른 것이 있다는 것을 잊어 버리십시오.” 아마도 뜨거운 Node.js 생태계는 자체 “Douglas Crockford” 를 성장시킬 것입니다. 로드맵이 있습니다. 거의 모든 비용으로 피해야 할 영역은 다음과 같습니다. 어떤 언어 나 환경에서도 볼 수있는 가장 풍요로운 급여가있는 지역은 다음과 같습니다.”

아마도 다른 누군가가 그 말을 도전으로 받아 들일 수 있고 Crockford의 리드를 따라 Node.js와 생태계에 대한“좋은 부분”및 / 또는“더 나은 부분”을 작성할 수 있습니다. 사본을 사겠다!

그리고 모든 프로젝트에 대한 열의와 쉬어가는 근무 시간이 주어지면,이 글을 쓰는 시점의 미성숙 한 생태계에 대한 언급을 급격히 강화하기 위해 1 년 또는 2 년 또는 3 년 안에 보증 될 수 있습니다. “2015 년 Node.js 생태계에는 여러 개의 지뢰밭이있었습니다. 2020 Node.js 생태계에는 여러 가지 낙원이 있습니다.”


9

응용 프로그램이 주로 웹 API 또는 다른 io 채널을 테 더링하거나 사용자 인터페이스를 제공하거나 사용하는 경우 node.js는 특히 가장 확장 성이 뛰어나거나 주요 언어를 사용하려는 경우에 적합합니다. javascript (또는 일종의 javascript 변환기)입니다. 마이크로 서비스를 구축한다면 node.js도 괜찮습니다. Node.js는 작거나 간단한 프로젝트에도 적합합니다.

주요 판매 포인트는 프론트 엔드가 일반적인 격차가 아닌 백엔드 항목에 대한 책임을지게한다는 것입니다. 또 다른 정당한 판매 포인트는 직원이 자바 스크립트를 중심으로하는 경우입니다.

그러나 특정 지점을 넘어 서면 모듈성, 가독성 및 흐름 제어를 강요하는 끔찍한 해킹없이 코드를 확장 할 수 없습니다. 그러나 이러한 이벤트를 좋아하는 사람들, 특히 이벤트 중심 자바 스크립트 배경에서 오는 사람들은 친숙하거나 용서할 수있는 것처럼 보입니다.

특히, 애플리케이션이 동기식 흐름을 수행해야하는 경우 개발 프로세스 측면에서 속도가 상당히 느려지는 반 베이크 솔루션에 대한 유출이 시작됩니다. 응용 프로그램에 계산 집약적 인 부품이있는 경우 신중하게 선택하여 node.js를 선택하십시오. 어쩌면 http://koajs.com/ 또는 다른 참신이 원래 node.js를 사용하거나 이것을 쓴 때와 비교했을 때 원래의 가시적 인 측면을 완화시킬 수 있습니다.


3
Node.js 응용 프로그램을 확장하는 기존 방법이 많이 있으며 "반 구운 솔루션", "끔찍한 핵"및 "끔찍한 API"클레임에 대한 참조를 제공하지 않는 것 같습니다. 그 점에서 마음이 넓어 지나요?
Sven Slootweg

나는 그것을 독자에게 연습으로 남겨 두지 만, 흐름 제어를위한 소위 솔루션을 보는 것으로 충분하다.
matanster

2
그것은 실제로 답이 아닙니다. 기존 솔루션은 "끔찍한 핵"이라고 주장하지만 그 중 하나를 지적하지는 않습니다. Node.js 애플리케이션을 확장하는 올바른 방법을 이해하지 못하거나 알지 못할 수도 있다고 생각 했습니까?
Sven Slootweg

나는 대답을 조금 업데이트했다. 어쩌면 여전히 불만이있을 수 있지만 잘못되었다고 생각되면 답변에 부족함을 지적하기보다는 세부 사항을 언급해야합니다. 그것은 공동체 imo에게 더 생산적 일 것입니다.
matanster

-2

노드 j를 사용해야하는 이유와 이유를 몇 가지 공유 할 수 있습니다.

  1. 채팅, 협업 편집과 같은 실시간 응용 프로그램의 경우 서버에서 클라이언트에게 화재 이벤트 및 데이터가 발생하는 이벤트 기반이므로 nodejs를 사용하는 것이 좋습니다.
  2. 대부분의 사람들이 생각하는 자바 스크립트 기반이므로 간단하고 이해하기 쉽습니다.
  3. 현재 웹 응용 프로그램의 대부분은 각도 js 및 백본을 향하고 있으며 노드를 사용하면 둘 다 json 데이터를 사용하므로 클라이언트 측 코드와 쉽게 상호 작용할 수 있습니다.
  4. 사용 가능한 많은 플러그인.

단점 :-

  1. 노드는 대부분의 데이터베이스를 지원하지만 복잡한 조인 및 기타를 지원하지 않는 mongodb가 가장 좋습니다.
  2. 컴파일 오류 ... 개발자는 오류 어코드 응용 프로그램이 다시 어디에서 작동을 멈추고 수동으로 시작하거나 자동화 도구를 사용해야하는 경우 각 예외를 다른 방법으로 처리해야합니다.

결론 :-Nodejs는 간단한 실시간 응용 프로그램에 사용하는 것이 가장 좋습니다. 비즈니스 로직이 크고 복잡한 기능이 있으면 nodejs를 사용하지 않는 것이 좋습니다. 채팅 및 모든 협업 기능과 함께 응용 프로그램을 빌드하려는 경우 특정 부분에서 노드를 사용할 수 있으며 편의 기술과 함께 사용해야합니다.


-3
  1. Node는 빠른 프로토 타입에는 유용하지만 복잡한 용도로는 절대 다시 사용하지 않습니다. 나는 컴파일러와의 관계를 개발하는 데 20 년을 보냈고 그것을 놓쳤다.

  2. 노드는 한동안 방문하지 않은 코드를 유지 관리하는 데 특히 고통 스럽습니다. 유형 정보 및 컴파일 시간 오류 감지는 좋은 일입니다. 왜 모든 것을 버려? 무엇을 위해? 그리고 댕, 무언가가 남쪽으로 갈 때 스택 흔적은 종종 완전히 쓸모가 없습니다.


2
컴파일 타임 검사를받지 못하는 동안 JSDoc을 사용하면 원하는 유형 정보를 추가하여 돌아올 때 상황이 더 잘 이해할 수 있습니다. 적절하게 분해 된 (작은) 기능은 일반적으로 잘 정의 된 환경 (닫힘)으로 인해 쉽게 잡을 수 있습니다. 잘못된 스택 추적은 종종 일부 리팩터링으로 해결되어 비동기 콜백으로 로직을 분리하지 않도록 할 수 있습니다. 비동기 콜백을 동일한 폐쇄 내에서 유지하면 추론하고 유지하기가 쉽습니다.
Rich Remer

2
컴파일 된 언어로 30 년을 보냈지 만 약 1 년 동안 사용한 후에는 JavaScript가 이제 제가 선택한 언어입니다. Java C # C ++ 또는 C보다 훨씬 적은 코드로 더 많은 작업을 수행 할 수 있습니다. 그러나 다른 사고 방식입니다. 유형이 지정되지 않은 변수는 실제로 많은 경우에 유리합니다. JSLINT는 필수적입니다. 동시에 작업을 수행해야하는 경우 비동기 콜백은 스레드를 사용해야하는 모든 언어보다 훨씬 안전하고 쉽고 생산성이 높습니다. 그리고 브라우저 언어이기 때문에 어쨌든 JavaScript를 알아야합니다.
James

제기 된 우려에 동조하고 있으며, 비록 그들이 보편적으로 적용되지는 않았지만,이를 해결하기 위해 몇 가지 노력을 기울 였다는 점에 주목합니다. Java 스크립트 코드 및 라이브러리의 정적 분석에서 유형 파생 을 제공 할 수있는 Tern 이라는 놀라운 프로젝트 가 있습니다 . 다양한 편집자를위한 플러그인이 있습니다. Typescript, JSDoc 및 BetterJS도 있습니다. 그리고 많은 Javascript 컴파일 언어 중 하나 인 Go있습니다 !
joeytwiddle
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.