Is Node.js Just a Temporary WebRTC Component?

July 15, 2013

Node.js is looking like a great match for WebRTC, but is that really the case?

Chris Matthieu, founder of Twelephone shared his view here once about Node.js and WebRTC, indicating the great match they make together. There are some other viewpoints as well.

The WebRTC Conference & Expo in Atlanta was a great event. Besides meeting a lot of interesting people, it has given me a lot to think about. In the “Node.js and MongoDB” panel during the conference, Vidtel’s Alex Doyle and Solaborate’s Labinot Bytyqi explained their use of the technology. Something that struck me as interesting was how both are viewing Node.js as an interim solution at best.

Node.js is temporary?

Both Vidtel and Solaborate are using Node.js in the backend for WebRTC signaling and nothing more – the rest of their system uses other technologies. Both have mentioned that they have opted for Node.js due to the rapid development it provides – being in a dynamic environment such as WebRTC required them to be agile enough and act fast, so Node.js was their technology of choice.

I asked them a question during the panel, of how they plan on tackling fast growth in their usage an user base, and what part will Node.js take in such a case. I was rather surprised by their answers.

Alex Doyle of Vidtel raised his concern and hesitation from using something based on Java Script in the backend that can solidly scale and work in a robust manner. He plans on switching from Node.js to something else if and when Vidtel sees an uptake in WebRTC use in their service.

Labinot Bytyqi of Solaborate stated that they are running on Windows Azure cloud, which was interesting – somehow, Node.js didn’t strike me as a Windows type of a solution. He also stated that he sees Node.js as an interim solution and that they are pursuing some other options, based on Windows technologies that Microsoft might soon have available in Azure. Being part of the Microsoft ecosystem anyway, I guess it makes sense.

I am torn here. I once thought that Node.js is a fad – something that worked for front end developers who wanted to do some backend programming. When I researched a bit further, and saw so many WebRTC companies adopting it, I changed my mind. But do I need to change my mind again?

Is Node.js just a way to get to market fast and then throw away the moment there some more cash available to invest in a real solution?

If you are reading this, and know Node.js, and even use it – I’d love to hear your thoughts:

Node.js – a robust addition to WebRTC or a temporary “patch” for the lean startup?

You may also like

WebRTC predictions for 2023

WebRTC predictions for 2023

Your email address will not be published. Required fields are marked

  1. Tsahi, the point on scalability makes sense though we @frisB have a slightly different take. also currently hovers on a node.js proxy which handles signaling among other things.

    but we are not concerned about porting to another platform for scale, since we have invented a very unique way of scaling voip without requiring any special hardware or sbc’s.

    So I think that despite node being predicated on javascript, it is an extremely high performance framework, and its robustness for WebRTC would depend purely on the use case.

  2. Tsahi,

    As for Azure, Node.JS is a giant part of the MS cloud service, if you will recall MS effort with AJAX is the precedent that started the JavaScript movement.

    As for Node.js and WebRTC, I could make a case for MQTT being the best way for the signaling to take place. So far we are still very telco driven in our modeling of signaling.

    As we see weblets and other add ons take advantage of WebRTC I think other protocols may emerge.

    If you think about the PubNub presentation, the data channel may be the most likely area for something new to emerge.

    However IMHO the most important point here is that Google was wise to let the signal have a life of its own, we shall see a lot of innovation this way.

  3. Node.JS is transforming the way modern developers build realtime, event-driven applications. The days of writing blocking code such as .NET and JAVA are over.

    Take a look at this Node.JS infographic:

    Node.JS is the most watched framework on GitHub and has had over 1M downloads of the current version. Many of the Fortune 500 companies are embracing it including: eBay, Yahoo, Zappos, LinkedIn, CBS, Mozilla, Time Warner, NPR, GM, DowJones, Barnes & Noble, and even Microsoft and Walmart.

    Node.JS offers massive scale. In fact, Voxer is running over 1B VoIP message transactions per day on their 100% Node.JS-based platform.

    Microsoft included Node.JS in Azure as a speculative play that the open source framework would outpace .NET development – and it’s only 4 years old 🙂

    I fear that your panelists are either misinformed about the potential of Node.JS or they are clinging on to old, outdated technologies for fear of the unknown.

    1. You seem to totally ignore other non-blocking IO frameworks for .Net or Java that achieve the same performance as node but with the goodness of static typing and well-designed language that help to scale a code database.
      I think that frameworks such as Play Framework (for Scala and Java) deals with non-blocking IO in a MUCH more elegant and efficient way than node.

      You quoted a lot of companies, but as far as i know Ebay or LinkedIn uses node only for proxies. Real backend work is never done with node. BTW, LinkedIn is now moving to Play Framework Scala for web server tasks.

      Fanatic node people seem to totally ignore innovation from other fields…

      1. Alex,

        I am not ignoring them – I am just mirroring what I see WebRTC vendors opting for. The issues you raise are valid ones. It would be intresting to see how this evolved in the WebRTC ecosystem.

        1. Hi Tsahi,

          I was not answering to your post but to Chris Mathieu’s comment 😉 Sentences like “The days of writing blocking code such as .NET and JAVA are over.” are misinformation.

  4. I was unfortunately not at the show, so I don’t know what Alex was up to, but I would like to perhaps clarify a little. Alex is correct that we use Node.js, however as the CTO of Vidtel, I can assure you that it is not just a temporary solution for us, nor is it just used for backend WebRTC signaling on our network. I would be happy to discuss our plans with it and other WebRTC related projects if you like.

  5. Node.js modules and express are the best features to implement real-time messaging. Windows Azure supports websocket on cloud service with node.js. We used it for messaging across platforms (web, iphone & android app) using socket libraries. Its working perfectly for signaling. To manage it in XMPP was not the robust solution.

    Node.js with webrtc will rock 🙂

  6. Hi Tsahi,

    At XirSys, we were working heavily with Node.JS several years ago for what was then (and probably still is) some revolutionary tech. This was pre-WebRTC, but had many features which are very relevant. At the time, we were very excited with what we could accomplish. We were using the Haxe language to develop our tech, which meant we could do some very cool stuff with Node.JS and the client, which would otherwise be very difficult to do.

    What we eventually found, however, is that Node.JS simply started to fall apart when we put our stack under heavy load. It wasn’t that we didn’t design it sufficiently, but more so that Node.JS simply wasn’t designed to perform at the level we wanted. We had file descriptor issues, memory ceiling issues, speed issues and scaling issues which culminated in a serious need to rebuild our tech using a more appropriate platform.

    In retrospect, while Node.JS offered rapid development and ease of development, we feel it’s simply just not cut out for the bigger tasks in life.


      1. We started using Go, actually, using the SkyNet project and building out services to handle our requirements. Experimental, really. However, Go is still a new platform and some of the basic things we needed were insufficiently supported and immature. It’s certainly something we’re keeping an eye on for future work.

        What we ended up using long term is predominantly Erlang. It gives much of the scaling goodness, but with fault tolerance and a very mature list of libraries and community members unparalleled in the more modern platforms. I’m actually a real Erlang fanboy and recommend it to everyone 🙂

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}