What is Node.js?
Want advice about which of these to choose?Ask the StackShare community!
I have benchmarked Node.js and other popular frameworks using a real life application example. You can find the results here: https://email@example.com/web-rest-api-benchmark-on-a-real-life-application-ebb743a5d7a3
- Most server-side scripts, all unit tests, all build tools, etc. were driven by NodeJS.
- ExpressJS served as the 'backend' server framework.
- MongoDB (which stores essential JSON) was the main database.
- MongooseJS was used as the main ORM for communicating with the database, with KnexJS used for certain edge cases.
- MochaJS, ChaiJS, and ExpectJS were used for unit testing.
- Frontend builds were done with Gulp and Webpack.
- Package management was done primarily with npm - with a few exceptions that required the use of Bower (also configured with JSON).
- The frontend was build primarily with ReactJS (as the View) and Redux (as the Controller / Store / frontend model).
- Configuration was done with json files.
The only notable exceptions were the use of SCSS (augmented by Compass) for styling, Bash for a few basic 'system chores' and CLI utilities required for development of the app (most notably git and heroku's CLI interface), and a bit of custom SQL for locations where the ORM extractions leaked (the app is DB-agnostic, but a bit of SQL was required to fill gaps in the ORMs when interfacing with Postgres).
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
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.
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.
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 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.
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.
We are now re-considering TypeScript because 1) the tooling has improved significantly, and 2) and the root cause of the majority of our front-end bugs are related to typing (despite having PropTypes).