Node.js vs. Rails vs. Sane Stack

This was my first Node.js app. You could call it experimental. I also used Express.

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.

Wikipedia and other Wikimedia Foundation projects use Node.js for VisualEditor's backend, Parsoid.

Node is installed for asset compilation during deployment.

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.

Node.js powers our new dashboard which is now super fast even while fetching 10-15 different data views.

Running all non-static content, from our very own website to social media scrapers.

More new stuff been made with node.js especially real-time bits.

I use this for some HTML5 based applications.

Powers our API along with all our DevOps tasks.

Node.js is the base for the RESTful API and drives all background jobs on the Azure WebSites platform.

Our web gateway is based on node-http-proxy, which allows us to have high performance and scalability.

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.

API for rich client application

Back-end is almost completely powered by Node.js.

The backend server in our API, we believe this is the future.

Rather than leverage Grunt.js, which is crap, repetitive tasks like minification can be done through Node.js scripts.

I use node as my backend, since I know javascript but I do not know any real backend technologies, with a CLI that can make all kinds of magic happen behind the scenes.

We use node.js and express in ur application server.

Core language

When ever there is a need for real time, event driven , non-blocking things this is my go to. It filles in the spots where Rails could not and it does that very well.

Heroku runs over Node.js

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.

Used for microservices

Power build tools

Automating gulp tasks

KB's backend is built on Node js

We are using Node.js as our API controller.

Node.js as an asynchronous allows easy scaling of our websocket server for the multiplayer aspect of the game

I use node.js mainly for backend-utility and data management scripts.

We use Node for our full stack web framework. The native libraries provide unparalleled "isomorphic" functionality.

Hexo is built on top of NodeJS and I had to use it to create the Deezer Hexo plugin.

Natively async for network programming. Reach for Native Addons when you need extra horsepower.

All our system relies on node.js

Most of the code we write on the server-side is in Node, due to it's flexibility, ease of use and extremely quick runtime once setup correctly.

Server side application logic and development tooling logic.

Data pump from Firebase into Apache Nifi. Manages keys to only listen for newest data.

Server-side data fetching and rendering of React components.

The framework the the http server to see the results and manage the documents processed.

As a main platform for the server stack

All my web applications and almost all of my command line scripts run on node.js

A lot of our tools that run on our IoT devices are written in Node.js. The simplicity & async nature of Node.js makes it very easy and efficient to develop and maintain these tools.

Main programming language of all backend services.

Catalogue

It's the heart of our application.

Builds and misc. server tasks.

Building tool and server side apps

Node.js is used both for our Frontend tooling and as a basis for some of our API endpoints.

Runs all my Build Tools

Platform for the build and command line utilities, for client interface module.

It is not used directly

Fast and easy to code. Hopefully. Development with Java is painfully slow.

Live chat server

We use Node JS for high speed I/O and REST-routing.

Backend handling WebUI and API requests.

Leverages on LevelDB to keep track of what's where/when it was stored. Interfaces to Yubico to check YubiKeys' OTP validity.

Server-side technology.

Our Ghost blog relies on Node.js

Basic webserver

As the server.

Backend instance to communicate via websockets.

In order to speed up loading times and allow SEO, a separate node server runs along side the Django server to render React components serverside and return the rendered HTML.

building stuff with bamboo

We were mesmerized by the great loop of libuv.

Used primary to setup the rest of the stack. NPM is just a amazing tool. Also used for testing simple javascript code straight from the command line.

Base Framework

We have some backend microservices written in Node.js throughout the company.

REST server for backend

Used it for full stack web application development.

API server built upon it. Tooling for Angular 2 runs with help of Node.js

Runs on Node v6+ as a standalone server. Optionally uses nodemon for monitoring of server process.

NodeJS drove the app's backend server (ExpressJS), frontend build tools (Gulp and Webpack), linters (ESLint), and most of the database scripts (through Knex and Mongoose)

Backend API is written in Node

Our web services are end-to-end javascript, powered by Node.js on the server side.

Most of the application is written in Node

We have a Node.js client library for the ThisData API

Ohh, Non-blocking, JSON embedded, javascriptable event loop server, we love you. Node is quick, easy, extensible, JSON and HTTP native. It's great. We can easily integrate Purescript code with it and even crazier stuff (like Idris https://github.com/statebox/dstbx)

Our server-side framework

Various bots

Full Stack framework

Used with Express.js and many other JavaScript frameworks and libraries.

javascript 의 눈부신 발전에 큰 도움이 되준 녀석이다. 빠르게 뭔가 만들고 싶다면, Node.js 가 최고 인것 같다. 그래서 개인 프로젝트는 거의 Node.js로 진행 했다. 작은 단위로 만들어 나가고 빨리 결과물을 볼 수 있어서 나에게 딱 맞는 것 같다.

Because sometime it's faster to do it with node than PHP :)

Ambar API is based on Node.js

Used for sending real-time notifications to connected browsers.

NodeJS is our language of choice for API and web application development.

We use node.js to build backend services as well as middleware for our react-redux frontend applications.

All backend projects I worked on during the past 3 years use Node at their core (mostly in combination with Express).

All backend code is done in node.js

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.

basic image processing, transform wrapper.

All backend servers at Wirkn are based on Node.js. Our production servers are always kept up to date with the latest LTS version.

Restful api gateway

Used for web apps, routing, chat clients, backend job systems and web socket apps.

I'm using node modules through npm for this addon. Modules include babel, auto-changelog, and run-when-changed.

For app server.

I use nodejs to build helper tools for my web application.

grunt task runner

Server-side JS, part of my full-stack JS approach.

ReactJs와 Express를 이용해보고있습니다

Runs front-end server

Mostly use it for NPM.

Serves routing for the app, allows quick deployment on Heroku.

서버사이드의 런타임 환경은 Node.js를 사용합니다.

Fast development.

Handles the grunt API work, authentication and providing API <-> Cache <-> Database link.

We use Node.js as our backend

Vue Server-Site Rendering
Socket.io server
etc...

Node is used by ghost, so for my personal blog I mainly work with configuration files, site structure, templates, and a little bit of database related work.

I am using nodejs as Back-end API server for the mobile application

Node.js is our primary language for both backend and frontend.

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!

应用服务器

I used node.js to program the bot and handle all of the NPM pacakges

Javascript is on its way ... typescripted

Aggregators

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?

Running local site build tasks.

Node.js is used for interactive parts of our homepage, cronjobs and building (gulp). The great performance and asynchronity makes a trustworthy companion in developing live web-parts (socket.io).

I use it with webpack & browserify to build my SPA websites or to build linkable libraries for my non-SPA websites

As part of ApertusVR's JsAPI plugin, Node.js serves REST API, socket API and runs JavaScript plugins.

Laravel mix runs on node.

Even though, It's full stakers' stuff. It has helped front end way too much with its power full build features and functionality

As a real-time proxy between frontend and backend components. (socket.io, publish, subscribe, redis, http restful api)

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.

Our stack core.

With expressjs - all our APIs and workers. 🎸🤘🚀

Backbone of the Documentation and PostCSS build process for the framework (development).

Not required for use.

Node.JS is a no-brainer for Hndhld's JavaScript environment.

JS serverside? OH YIS!

센드버드 메시지 웹훅 핸들러 활용

Node's Express framework makes it easy to create APIs

Server side APIs for mobile apps.

Code.

Gardenbed installs all of the tools that are necessary to deploy a Ruby on Rails application to a VPS.

We use Rails to power most of our APIs and internal services.

Web has always been in Rails from the beginning, so we used Redis for caching our items, which we had, from the beginning. Rails is kind of what we were comfortable with, and we knew we wanted the front end to be really, really snappy, so we de-normalized all the item attributes into Redis, and that's how it got served out.

Database is a fixtures file, loaded into ActiveRecord, cleaned up, compressed. Javascript code is generated by exporting JSON.

We use Rails for webpages and projects, not for backend services. Actually if you click through our website, you won't notice it but you're clicking though, I think, seven or eight different Rails projects. We tie those all together with a front-end library that we wrote, which basically makes sure that you have a consistent experience over all these different Rails apps.

It's a gem, we call it Karmeleon. It's not a gem that we released. It's an internal gem. Basically what it does is it makes sure that we have a consistent layout across multiple Rails apps. Then we can share stuff like a menu bar or footer or that kind of stuff.

So if we start a new front end project it's always a Rails application. We pull in the Karmeleon gem with all our styling stuff and then basically the application is almost ready to be deployed. That would be an empty page, but you would still have top bar, footer, you have some custom components that you can immediately use. So it kind of bootstraps our entire project to be a front end project.

Services that require a short iteration cycle, or any proof-of-concept work.

Rails is one of the easiest frameworks to use for API development.

Our monolithic application. Its the core of our stack.

The first live version of Leanstack was actually a WordPress site. There wasn’t a whole lot going on at first. We had static pages with static content that needed to be updated manually. Then came the concept of user-generated content and we made the switch to a full on Rails app in November of last year. Nick had a lot of experience with Rails so that made the decision pretty easy. But I had also played around with Rails previously and was comfortable working with it. I also knew I’d need to hire engineers with a lot more experience building web apps than I do, so I wanted to go with a language and framework other people would have experience with. Also, the sheer number of gems and tools available for Rails is pretty amazing (shout to RubyToolbox ).

I don’t see us ever having to move away from Rails really, but I could be wrong. Leanstack was built in Rails 3. For StackShare we decided to upgrade to Rails 4. Biggest issue with that has been caching. DHH decided to remove the standard page and action caching in favor of key-based caching (source)[http://edgeguides.rubyonrails.org/caching_with_rails.html#page-caching]. Probably a good thing from a framework-perspective. But pretty shitty to have to learn about that after testing out your new app and realizing nothing is cached anymore :( We’ll need to spend some more time implementing "Russian Doll Caching", but for now we’ve got a random mixture of fragment and action caching (usually one or the other) based on which pages are most popular.

Well-established framework for rapid development of web apps. Huge repository of good integrated 3rd party libraries (Gems)

Rails allows us fast prototyping.

Using Rails as a go to thing for creating API's or full blown web apps. Love writing Ruby, convention over configuration style is great and it has a tons of gems and community behind it :)

Rails makes it easy to build out sophisticated Web apps quickly, without re-inventing the wheel for each of our clients. SmartLogic ♥ Rails!

7 years of Rails development experience and project management.

Backend business logic

I work with Rails all the time, since 2011.

Backend and API.

Rails powers enlist's API.

Rails is our product's backend app. It handles user registration/logging, product's logic and Inspector communication with our users' devices.

Rails is used for some endpoints of our Frontend API. Though there are talks of deprecating it.

To save time and build great web apps

robust, fast, and easy MVC for Ruby. Now I've found it, i'm in love.

Rails 5 (beta 3) provided a nice structure for rendering responses, linking to front-end assets (compiled previously via Webpack), handling sessions w/ tailor made login links via an email button/token, background jobs, and creating an admin behind basic auth to allow managing of users and purchases.

Framework for building our MVP web app.

Backend micro-services REST API implementation

Application framework.

Used as the API endpoints connecting my database to the client's browser.

We use Rails as our Goto framework for systems build.

Rails API

PRS UI app is built in Rails (originally a proof of concept which has now become the primary tool for interaction with the PRS API).

Our API is built on Rails.

As a web app developer, all of my web apps have been built with Rails.

expert

Backend Code

My personal website is built entirely in Ruby on Rails. Apart from the actual website, there is also an CMS behind it supporting several third-party integrations (eg Embedly, Instagram API etc).

Built http://fube.io

Rails was simple to develop on, and the programming is very straightforward.

Build a dashboard for certified users.

We're a full-stack Rails shop.

A Ruby environment that takes on all the heavy lifting. Install Ruby on Rails, and create a working web app with a single command line. No brainer.

For this project rails was ideal due to new features introduced in Rails 5 that allowed us to build a lightweight "API only" project. Developer familiarity and the ability to rapidly iterate, as well as providing an accessible testing framework were additional factors.

Old but gold

Microservices

Bitödeme integrations RESTFul API uses Ruby on Rails to process API requests

Go with Ruby for Web Applications

Used for searching for doctors, adding articles, recipes, videos. Filtering by tags and categories.

3+ years experience (working remotely)