What Could Go Wrong with Node.js? - NodeSource

The NodeSource Blog

You have reached the beginning of time!

What Could Go Wrong with Node.js?

What Could Go Wrong? was a presentation originally given by Gregory Wild-Smith of Bleacher Report in June of 2016 at the SFNode meetup.

Bleacher Report has made an astounding reduction in the footprint of their application, and are continuing to transition the rest of their site from the monolithic Ruby app to a small, nimble Node stack. The What Could Go Wrong? presentation outlined the different challenges they faced, notable statistics of the transition, and tools they've implemented effectively.

Top 5 Takeaways

  • Start small - learning hard lessons is much easier when it happens on a small scale.
  • Atomic Design is applicable to JS, and highly effective.
  • Mental models don't always map well to effective data structures.
  • Using configuration tools is a barrier, not a blessing
  • Went from maintaining a 64mb frontend monolith to a 1.8mb frontend with Node.



Bleacher Report has…

  • 60 - 100 million daily users
  • Up to 250k users a second (with an average of 100k a second)

In their monolithic Ruby project, BReport, Bleacher Report had…

  • 8mb of HTML (erb)
  • 46mb of JavaScript
  • 10mb of CSS
  • Lots of Ruby code, including 50+ models, controllers, and so on.
  • Even more Ruby code that had absolutely nothing to do with rendering.

In their monolith-replacing Node system, NodeReport, Bleacher Report has...

  • 0kb of HTML (that they maintain, at least - 58kb generated and sent by JavaScript)
  • 1.5mb of JavaScript (~240kb gzipped), roughly 1.1mb of which is libraries
  • 304kb of CSS (~120kb gzipped), which is mostly structured by Atomic Design
  • Data is provided by microservices that pipe the needed data through

Bleacher Report was being held up by technical debt from their monolithic application - which had gone through iteration after iteration, for years - to the point that they weren’t able to comfortably move forward with developing their product.

Bleacher Report has implemented Atomic Design within their JavaScript applications. Atomic Design has typically been a CSS design system, but Bleacher Report adopted the concepts throughout their system, including within their JavaScript application system.

Bleacher Report has iterated on tooling - they used Gulp, moved to Grunt, and finally landed on npm scripts. The npm script structure helps them focus on making effective tooling and not writing more JavaScript than they need to, when it’s unnecessary to do so.





The NodeSource platform offers a high-definition view of the performance, security and behavior of Node.js applications and functions.

Start for Free