Five years of Node.js

Unity <3 Node.js, or do we…?

The Beginning

The Beginning

PHP + MySQL

PHP + MongoDB

Node.js + MongoDB

Late 2010: Node.js 0.4

700M ads served per day

Thus began our 5-year journey with Node.js

Initially, Node was used only for APIs for ad delivery

New products and features were an easy way to

transition

Backbone + Node.js + MongoDB

But it was not always a smooth ride…

Updating between Node versions was horrible

We ended up having different services run on different Node versions

A bleeding-edge tech stack will give you new challenges

Things we learned: MongoDB shards well…

on paper

Things we learned: It was easier to optimize code and data layout than shard

MongoDB

Things we learned: Handling memory leaks in

Node.js is a pain

Things we learned: External dependencies,

especially NPM, can make your deplos unreliable

While on the subject of NPM(JS.org)…

One of the best parts of Node.js is the community

One of the best worst parts of Node.js is the community

NPM, like actually most package managers, can be

a security issue

Are you doing this?

~1.2.3 or

^1.2.3

Are you doing this? If you are, stop right now.

But you have no control over dependencies of used

packages!

Worst case scenario

Your application

Dependency A

Dependency B

Sub-dependency

A.1

Sub-dependency

A.2

Worst case scenario

Your application

Dependency A

Dependency B

Sub-dependency

A.1

Compromised package

Worst case scenario

Your application

Dependency A

Dependency B

Sub-dependency

A.1

Compromised package

npm shrinkwrap

The Present

Tech Stack

Node.js MongoDB + Cassandra +

Redis Angular.js + Bootstrap

Infrastructure

Everything on AWS Docker for deployment

Teams

2010: 8 people in Helsinki 2015: 70+ people in Helsinki

Requirements

99.9% uptime Continuous deployment

Handle massive scale

How are we handling that?

#1: Testing

For continuous deployment, we must aim for ~100% test

coverage

Tests are our compiler type-safety check

#2: Automated Deployment

Developers must be able to handle deployment and rollback independently

Auto-scaling must be able to set up new instances in a few

minutes

Developer  

commit  

No.fies  of  commit  

Clones  repository  

Tests    run  

Docker  container  pushed  to  private  registery  

Deploy  Happiness  

#3: Understanding the weaknesses of Node.js

Leaking memory is easy, and debugging memory leaks is

insanely difficult

Callback-hell makes debugging painful

Node.js is single-threaded

Let’s talk about that for a while…

Making sure your code yields adds complexity you don’t

want

Measuring and monitoring these spikes is a nightmare

How do you measure?

Single-threaded also means that you cannot cache data

efficiently on the local machine

We run 40 Redis instances to act as data caches

… and we still run Memcached locally in

addition to that

Writing CPU-optimized code with Node.js is extremely

difficult

The Future

Would we choose Node.js again?

Probably not.

Node.js is useful for prototyping.

Node.js does create burden in sustainable development.

Node.js requires a lot of discipline from the

development team.

In the end: right tool for the right task.

Thank you!

http://unity3d.com/helsinki