Nodeday 2014: Node App Lifecycle
NodeDay 2014: Node App Lifecycle
Akbar S. Ahmed | Apr 15, 2014

Lessons learned

Building a Node App from the ground up - What we did the second time This is a talk about the lessons we learned building our first product with Node.js and how we rectified the issues we faced when we built our latest product. We will discuss the challenges of building maintainable code bases with Node.js, from development, to testing, to deploy, and how we’ve overcome those problems with tooling and policy.


  • Name: Ian Livingstone
  • Title: VP of Engineering
  • Company: GoInstant
  • Twitter: ianlivingstone

The following are some general lessons learned:

  • Create a separate api
  • Maintentance costs increased massively as the code base increased
  • Legacy code that used different programming styles as problematic
  • Make small pull requests and implement code review (i.e. do not simply commit to master)
  • Focus on integration planning a core part of development
  • Think about how to break code into small bits.
  • Enforce jshint in CI, must pass before merged to master.
  • Common config on client and server
  • Have written coding standard
  • Use a smaller subset of JS

Event Listeners

  • Most people get this wrong.
  • Use a registry for event registration - aggregator

State Management

  • modules should not maintain state
  • if a class has state then it must have an initialize and destruction method
  • constructor should only be responsible for configuration

JSON Schema (he really likes this)

  • schema makes it easy to test code
  • have a schema for request and response
  • run JSON schema in development
  • only use JSON schema in limited situations in production b/c it’s slow

Problem: Multi-user integration tests

  • they required multi-user integration tests required to exercise the UI
  • tried Selenium, but tests were verbose, fragile and slow
  • solution was to create Barista, which is an extension of Mocha

Improve development

Use build tools to improve development.

Problem: Code manageability

  • as code base grew responsibilities started to leak into modules
  • this made it hard to write unit tests
  • and made the code base fragile


  • small, simple and independent modules!!! (this is KEY!)
  • treat application as glue between different independent modules
  • create clear lines of responsibility
  • keep it small and simple and single purpose
  • pull as much code out to modules as possible


  • code is cleaner and easier to work with
  • increased amount of code reuse
  • downside: npm install takes longer (which they solved by using proxy backed by S3)

They are looking at PayPal’s Kappa as a possible solution.

API abstraction

  • each client has wraps the transport converns
  • the benefit of abstracting the transport is that each service has well defined responsibilities, and each client can be tested by stubbing the service


  • use supervisord to manage processes
  • HAProxy manages load balancing to different services


  • adopt the concept of small, simple things
  • use coveralls for code coverage
  • he finds unit tests are the most valuable tests
  • jscs + jshint

Subscribe to our newsletter

Contact Information


We specialize in helping professional developers, like you, expand your skill set. Our courses are focused on enabling you to learn everything necessary to use a new technology in a live, production application.


All courses are made with love in
Palo Alto, CA.

Subscribe to our newsletter