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.