Fans

7

Votes

10

Jobs

0

Hacker News, Reddit, Stack Overflow Stats

GitHub Stats

Description

What is
Node.js?

Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

What is
.NET?

.NET is a general purpose development platform. With .NET, you can use multiple languages, editors, and libraries to build native applications for web, mobile, desktop, gaming, and IoT for Windows, macOS, Linux, Android, and more.

What is
Atmosphere?

The Atmosphere Framework contains client and server side components for building Asynchronous Web Applications. The majority of popular frameworks are either supporting Atmosphere or supported natively by the framework. The Atmosphere Framework supports all major Browsers and Servers.

How developers use Node.js vs .NET vs Atmosphere

The social ranking platform, Klout, used to use a PHP & LAMP stack but found it difficult to continue to scale, so when they had the chance they moved to a Node.js backend. They even wrote about switching to Node.js and how they use it. [additional source: http://blog.klout.com/2011/10/the-tech-behind-klout-com/]

The server side of Trello is built in Node.js. We knew we wanted instant propagation of updates, which meant that we needed to be able to hold a lot of open connections, so an event-driven, non-blocking server seemed like a good choice. Node also turned out to be an amazing prototyping tool for a single-page app. The prototype version of the Trello server was really just a library of functions that operated on arrays of Models in the memory of a single Node.js process, and the client simply invoked those functions through a very thin wrapper over a WebSocket. This was a very fast way for us to get started trying things out with Trello and making sure that the design was headed in the right direction. We used the prototype version to manage the development of Trello and other internal projects at Fog Creek.

We decided to move the provisioning process to an API-driven process, and had to decide among a few implementation languages:

Go, the server-side language from Google

NodeJS, an asynchronous framework in Javascript

We built prototypes in both languages, and decided on NodeJS:

NodeJS is asynchronous-by-default, which suited the problem domain. Provisioning is more like “start the job, let me know when you’re done” than a traditional C-style program that’s CPU-bound and needs low-level efficiency.

NodeJS acts as an HTTP-based service, so exposing the API was trivial

Getting into the headspace and internalizing the assumptions of a tool helps pick the right one. NodeJS assumes services will be non-blocking/event-driven and HTTP-accessible, which snapped into our scenario perfectly. The new NodeJS architecture resulted in a staggering 95% reduction in processing time: requests went from 7.5 seconds to under a second.

Used node.js server as backend. Interacts with MongoDB using MongoSkin package which is a wrapper for the MongoDB node.js driver.
It uses express for routing and cors package for enabling cors and eyes package for enhancing readability of logs.
Also I use nodemon which takes away the effort to restart the server after making changes.

For JavaScript-heavy Web sites, Node.js makes it possible to reuse the same code on both the client and the server. The evented architecture is particularly well suited for "glue" code that connects other services.

We have a SOA for our systems. It isn't quite Microservices jsut yet, but it does provide domain encapsulation for our systems allowing the leaderboards to fail without affecting the login or education content.

We've written a few internal modules including a very simple api framework.

I ended up picking Node.js because the game client is entirely in JavaScript as well. This choice made it a lot easier for developers to cross borders between being "client side" game developers and "server side" game developers. It also meant that the pool of knowledge/best practices is applicable almost across the company.

Node.js is the foundation for the server. Using Express.js for serving up web content, and sockets.io for synchronizing communications between all clients and the server, the entire game runs as Javascript in Node.js.

I don't know how well this will scale if/when I have hundreds of people connected simultaneously, but I suspect that when that time comes, it may be just a matter of increasing the hardware.

As for why I chose Node.js... I just love JavaScript! My code is all original, meaning that I didn't have to inherit anyone's bad Javascript. I'm perfectly capable of creating my own bad Javascript, thank you! Also, npm rocks!

Node.js simplifies development by letting you use a single language on the client and server. This has the added benefit of keeping your apps DRY because you can share code between them.

Its package registry, npm, is the largest of any language. With over 500,000 packages and 500+ new packages being registered every day, you can almost always find what you're looking for. And if you can't, why not make your own and share it with the world?

We use NodeJS as one of the systems for our backends. We use NodeJS primarily when working with apps that need to work in realtime or carry out many actions asynchronously. We also use NodeJS for our custom Nagios and Grafana reporting and monitoring tools.

Microsoft has done an incredible job of keeping the .NET Framework powerful and stable. It is well designed and keeps getting more robust with each release. It isn't the most popular technology in this space, but I think a good case can be made to use .NET in many new projects.

As we started on Windows Phone we use C# and .NET for most of our apps and sites. Being a small team of 2, using .NET enables us to work on each part of the service without having to switch to different languages.