What Could Go Wrong with Node.js?
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)
- 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...
- 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.