Why Should You Care About NodeJS?
- Jan 17, 2014 at 11:16 PM
- Shawn Wildermuth
- 9 Comments
I know that many of my readers are .NET guys and a core constituency actively hate JavaScript so bear with me and let’s talk about NodeJS for a minute.
Just to be clear, I am not advocating anything by this post. What I think is important is that as you mature as a developer that you look at whatever is happening in the community and be open to why something is new and what new ideas are being proffered by the new technology. My hope is that this post will show some of that.
What is NodeJS?
Simply put, NodeJS is a runtime for JavaScript that encourages non-blocking I/O and fast networking. NodeJS itself isn’t written in JavaScript but it executes JavaScript using Chrome’s V8 engine. It is the engine that powers a lot of cool tools these days (e.g. Bower, GruntJS, etc.) but is primarily used as simple web server platform.
Is NodeJS Magically Scalable?
When I first heard about NodeJS, the comments were always about how you could create fast, scalable web sites/apps with it. While this is true, it’s nature isn’t magic. The trick here is that NodeJS encourages non-blocking behaviors. NodeJS itself is single threaded (though you can run multiple instances of it) but it encourages you to think in terms of events and callbacks. The thread isn’t busy while waiting for these callbacks so it can accommodate a lot more traffic than a traditional web server (e.g. IIS or Apache) per thread.
While NodeJS is an admirable technology, I think it’s real benefit is that it doesn’t rely on thread pools to achieve smart asynchrony. It encourages writing asynchronous code on the server. And if the request is waiting for an operation, it can release the thread to serve another request.
This means you can build better scalability, easier with NodeJS – per thread. Full throughput of NodeJS isn’t necessarily more than you’d get from IIS or Apache, but that’s because they can throw more threads at the problem. NodeJS out of the box doesn’t have the concept of scaling out as an obvious switch. Instead, it relies on that being applied to it separately. There are solutions for this, but it is something that you’d seek out or ‘buy’ (e.g. Azure, AWS, etc.)
What Can .NET Learn from NodeJS?
As far as I can tell (and I am ankle deep into a lot of these technologies), I think .NET is learning from NodeJS. That’s what a lot of the OWIN stuff is about. Combining OWIN and scriptcs gets you pretty close to the vision for NodeJS on .NET. But as a developer, what can you learn?
If you’re like me, you have a lot of skills and experience with ASP.NET (et al.) and I’d love to achieve some of the benefits ofNodeJS. One of the concepts you should think about is non-blocking I/O and event callbacks. Much of this is accomplished with Asynchronous Controllers in ASP.NET MVC and Web API. Often developers won’t both worrying about asynchrony here unless they’re doing something that takes a lot of time (like calling out to another web server or calling a database), but I think that you should be thinking about asynchrony every time you make a call that takes any time. The Windows team started thinking like this for WinRT in that any call that is > 50ms requires you to call it via an asynchronous API. The C# async stuff makes this pretty easy so we in web development land should treat it the same way. Most Controllers should be Asynchronous as far as I am concerned. Especially now that EF6 supports asynchronous queries.
Should You Be Looking at NodeJS?
Yes.
Ok, maybe more is useful. I think you should be looking at NodeJS to understand it’s philosophy. You may find for certain types of projects (e.g. APIs or networking projects) that NodeJS is a great model and you should deploy NodeJS project. But at a minimum I think programming NodeJS will teach you how to think in terms of non-blocking I/O. That’s a great skill to have regardless of how you build software.
당신은 왜 NodeJS에 관심가져야 하는가?
나는 내 독자들의 상당수가 닷넷가이들이고 자바스크립트를 혐오하는 핵심 지지층이라고 안다. 그러니 참고 나와 잠
시만 NodeJS에 대해 이야기 해보자.
명백하게, 나는 이 포스트를 통해 어떤것을 지지하고자 함이 아니다. 나는 당신이 충분히 성숙한 개발자라면 커뮤니
티 안에서 일어나는 어떤 것들이든 보고 왜 새로운 것이 나왔는지, 신기술에서는 어떤 개념이 제공되었는지에 대해
열려있는 것이라고 생각한다. 이 포스트가 그런것을 보여주길 바란다.
왜 NodeJS인가?
간단히 놓고, NodeJS는 넌블럭킹I/O와 빠른 네트워크를 권장하는 자바스크립트 런타임이다. NodeJS 자체는 자바스
크립트로 작성되지 않았다. 다만 이것은 크롬의 V8엔진을 사용하여 자바스크립트를 실행해준다. 이것은 요즘
Bower, GruntJS 등의 좋은 툴들을 많이 지원해주는 좋은 엔진이다. 하지만 기본적으로는 단순한 웹서버플랫폼에 사
용된다.
NodeJS는 마술처럼 확장적인가?
내가 처음 NodeJS에 대해 들었을 때, 항상 논점은 이걸로 어떻게 빠르고 확장적인 웹사이트/웹앱을 구축할 것인가였
다. 이것은 사실이지만 마술은 아니다. 그 속임수는 NodeJS가 넌블럭킹I/O 방식을 장려한다는 것이다. NodeJS 그
자체는 단일쓰레드(다중 인스턴스를 실행할 수는 있지만)이다. 하지만 당신에게 이벤트와 콜백이라는 개념 안에서
생각하도록 장려한다. 콜백수행을 기다리는 동안 쓰레드는 바쁘지 않다. 그래서 IIS, Apache같은 전경적인 웹서버보
다 쓰레드 당 더 많은 트래픽을 수용가능하다.
NodeJS가 존경할만한 기술인 반면, 나는 이 것의 진짜 장점은 스마트한 비동기처리를 위해서 쓰레드풀에 의지하지
않아도 된다는 것이다. 이 것은 서버에 비동기코드를 작성하도록 장려하고 요청을 기다리는 동안 서버가 또다른 요청
을 받을 수 있도록 쓰레드를 돌려줄 수 있다는 것이다.
이 것의 의미는 여러분이 NodeJS를 통해 쉽게 쓰레드 당 더 좋은 가용성으로 구축할 수 있다는 것이다. NodeJS의 전
체처리량은 IIS나 Apache로 부터 얻을 수 있는 것보다 필연적으로 많지는 않다. 하지만 문제를 처리하기 위해 더 많
은 쓰레드를 던져줄 수 있다. 박스 외에서의 NodeJS는 명백한 스위치로서의 확장의 개념은 아니다. 그러나 이것은
분리해서 처리하는 것에 의존한다. 이런 솔루션들이 있다. 하지만 아마도 이것들은 당신이 찾아보거나 구매한 것일
것이다(예를 들어 Azure, AWS 등).
.NET은 NodeJS에서 무엇을 배울 수 있나?
(이런 기술들에 발목까지 빠져있는 내가) 적어도 말할 수 있는 것은, .NET은 NodeJS를 배우고 있다는 것이다. 많은
OWIN관련기술들이 관련된 것이다. OWIN과 scriptcs와 결합하여 당신은 .NET에서 NodeJS의 비젼과 꾀 가깝게 다
가갈 수 있다. 하지만 개발자로선 무엇을 배울 수 있을까?
만약 당신이 나와 같다면 많은 ASP.NET경험과 기술을 가지고 있을 것이다. 그리고 나는 이런한 NodeJS의 일부 혜택
을 누리고 싶다. 당신이 생각해야 하는 하나의 개념은 넌블럭킹I/O와 이벤트콜백이다. 이것의 많은 부분은 ASP.NET
과 WebAPI의 비동기컨트롤러를 통해 성취될 수 있다. 주로 개발자들은 (타웹서버나 DB호출같은) 장시간 소요되는
무언가를 하지 않는다면 비동기성에 대해 두가지 고민을 하지 않을 것이다. 하지만 나는 시간이 소요되는 모든 요청
을 처리할때마다 비동기성을 생각해야 한다고 생각한다. 윈도우팀은 WinRT에서 비동기API를 통해서 당신의 모든 요
청이 50미리초 이내로 처리될 수 있게 하기 위해 이러한 생각을 하기 시작했다. C#비동기 관련 것들은 이런 것들을
쉽게 해준다. 그래서 우리 웹개발자들은 이것을 같은 방법으로 처리해야만 한다. 내가 고려하는 대부분의 컨트롤러
는 비동기화 되어야 한다. 특별히 지금 EF6는 비동기쿼리를 지원한다.
당신은 지금 NodeJS를 봐야 하는가?
맞다.
좋다, 아마도 유용할 것이다. 나는 당신이 NodeJS의 철학을 이해하기 위해서 이 것을 봐야 한다고 생각한다. NodeJS
배경의 특정한 타입의 프로젝트를 찾아볼 수 있을 것이다(APIs 또는 네트워킹프로젝트 등) 그리고 적용해봐야만 한
다. 하지만 최소한 나는 NodeJS프로그래밍이 넌블록킹I/O의 개념을 어떻게 생각해야 할지를 가르쳐줄 수는 있을 것
이라고 본다. 이 것은 당신이 어떻게 소프트웨어를 개발하느냐와 관계 없이 위대한 기술이다.