Building a highly scalable exchange - To react or not to react
summary
A crypto exchange built on Ruby on Rails hits thousands of users and Rails view rendering fails under realtime load, so the team moved to React and decoupled front end while fixing slow SQL and caching. Backend changes include Aurora + Redis + ELK and C#/.NET for heavy lifting; websocket load shifts to Pusher. Benchmarks show page load falling from 2.8s → 1.07s (React-only ~1.8s). Remaining issues: virtual DOM slowness, high client memory and startup latency.
AI-written summary · about
chapters (23)
- 0:00Intro
- 0:20Building a highly scalable exchange To react or not to react
- 1:29What this presentation is not
- 2:51Our initial stack
- 3:39The best part
- 6:27RCA - The three letter horror
- 8:13Data, data, data
- 9:50Fixing the backend issues
- 10:42Initial JavaScript days
- 11:16Limitations of this setup
- 14:09The learning curve
- 16:14JSX as a pain point
- 17:11The good part - Components
- 18:40Components & Actions
- 19:13Dispatchers to do the work
- 21:17The good part – Invisible DOM
- 23:35100s of lines of code to a few
- 24:35MVC to Pure API
- 26:26React Native
- 29:13Benchmarking Load times between page loads and data population
- 31:10Unsolved Issues
- 33:04The learnings
- 35:57The takeaways
related talks
18mReact-ing to Rails: Why Ruby on Rails is the best Stop for Web Developer
31mReact.js on Rails
07mBuilding Real-Time App with React/Redux/Rails/RethinkDB
26mUsing Rails to communicate with the New York Stock Exchange
46m365 Days Later: Moving from Java to RoR and how it changed everything
28mBuilding in Rails, Backbone, and CoffeeScript
42mHow Rails fosters a diverse and competitive tech ecosystem in the era of big tech
35mGoing fullstack React(ive)