Sonic: A Slack Modernization Project

A look into how we incrementally modernized Slack, and what lessons we learned along the way

Over the last 18 months, Slack engineers went through a large modernization project. We rewrote the entire Slack client using modern JavaScript, made it faster and more efficient, and introduced new features such as offline support and dark mode.

Refactoring all existing code whilst introducing new features can carry a certain amount of risk with it. So in this session, we’ll explore how we went about achieving this in a safe way, and explore the lessons we learned along the way

Transcript

1. SONIC: A SLACK MODERNIZATION PROJECT A LOOK INTO HOW WE INCREMENTALLY MODERNIZED SLACK AND WHAT LESSONS WE LEARNED ALONG THE WAY @ANUJRNAIR
2. LEGACY SONIC
3. SLACK BEFORE SONIC
4. Smarty templates Loose in-house frontend framework No encapsulation; everything attached to a global TS object Manual DOM updates via jQuery Eager data loading 2014: SLACK OPEN BETA ! $
5. 2014-2017: PRODUCT DEVELOPMENT & MARKET FIT Slack started growing very quickly New features created to keep up with customer expectations Every team developed in their own way Slack workspaces rapidly outgrew early engineering assumptions
6. 100% GROWTH EVERY YEAR
8. Standardize our templating, DOM updates, and data model Develop new features such as offline and dark mode Improve application performance: boot time; memory consumption; app speed Incrementally transition to new architecture to reduce risk WHAT WE WANTED TO ACHIEVE
9. MODERNIZATION STRATEGY
10. Incremental Transition Plan Multi workspace aware architecture Performant boot process Offline support etc. SONIC TEAM BREAKDOWN Message Pane Threads Quick Switcher Search Sidebar (Channel details, stars, etc.) etc. Buttons Inputs Checkboxes Modals Tooltips etc. FOUNDATIONS SLACK KIT FEATURE TEAMS
11. INCREMENTAL TRANSITION PLAN
12. Idea: Modernize sections of code into a new codebase, and push it back into the legacy client. Problem: Modules could have many dependencies Problem: How do we stop legacy code polluting modern code? INCREMENTAL TRANSITION PLAN
13. INCREMENTAL TRANSITION PLAN THEORY LEGACY SONIC LIVE VERSION
14. Run 2 webpack compilations; one to bundle legacy TS modules; one to bundle modern only code Code should only mix during runtime, not compile time INCREMENTAL TRANSITION PLAN LEGACY INTEROP API ↕
15. Export and Adapt all functionality we need Over time, Exported code will grow and Adapted code will shrink INCREMENTAL TRANSITION PLAN LEGACY INTEROP API
16. Find a strategy to reduce risk Codify modernization strategy Mix code at runtime, not compile time Break your build if something important is bypassed INCREMENTAL TRANSITION PLAN LESSONS ✅ ✅ ✅ ✅
17. MULTI WORKSPACE AWARE ARCHITECTURE
18. Idea: House multiple workspaces in a single Electron process Problem: All code currently assumes a single workspace MULTI WORKSPACE AWARE ARCHITECTURE
19. MULTI WORKSPACE AWARE ARCHITECTURE LEGACY SONIC
20. Create modern code to be multi workspace aware “Export” a single team aware version back to the legacy client MULTI WORKSPACE AWARE ARCHITECTURE
21. MULTI WORKSPACE AWARE ARCHITECTURE RESULT: REDUCED MEMORY USAGE
22. Build it right in modern codebase; make it work in legacy Virtualize long lists to reduce memory consumption Ensure deferred functions have parameters bound MULTI WORKSPACE AWARE ARCHITECTURE LESSONS ✅ ✅ ✅
23. PERFORMANT BOOT PROCESS
24. Idea: Speed up boot by incrementally loading Slack with only the data and assets which are necessary at that time Problem: Client expects a full data model to be present Problem: API calls are blocking in the boot process PERFORMANT BOOT PROCESS
25. PERFORMANT BOOT PROCESS LEGACY
26. New framework: • Optimized Assets • Fetch data on demand • Optimized for client-side rendering • Front load API requests PERFORMANT BOOT PROCESS THEORY SERVER CLIENT TIME
27. Small boot payload starts API calls, and lazily downloads the rest of our app Split expensive API calls into multiple smaller calls - they run in parallel and finish faster Aggressive webpack plugins to produce highly optimized assets PERFORMANT BOOT PROCESS SONIC
28. PERFORMANT BOOT PROCESS RESULT: DECREASED BOOT TIME
29. Profile your app to find your blockers; solve for those specific blockers. Download the least amount of assets and data possible. Execute in parallel to optimize the main thread. PERFORMANT BOOT PROCESS LESSONS ✅ ✅ ✅
30. OFFLINE SUPPORT
31. Idea: Allow Slack to be used without internet; sync everything when we’re back online Problem: Components assume all data is always available Problem: Slack sessions are long lived OFFLINE SUPPORT
32. When online, boot Slack and download necessary assets & data in the background Subsequent boots will always boot from the service worker cache Periodically sync assets and data with the server to keep up-to-date OFFLINE SUPPORT SERVICE WORKERS
33. OFFLINE SUPPORT SERVICE WORKERS
34. OFFLINE SUPPORT RESULT: DECREASED BOOT TIME
35. Consider your asset lifecycle; once a service worker is installed, it will always intercept requests Don’t rely on the browser cache try catch everything OFFLINE SUPPORT LESSONS ✅ ✅ ✅
36. OTHER LEARNINGS
37. Align engineers as fast as possible, as much as possible • Tech specs to validate assumptions and share knowledge • ESLint and Prettier to align engineers on code styles and business logic • Custom ESLint and webpack plugins to reenforce best practices for your company OTHER LEARNINGS ✅
38. THANK YOU @ANUJRNAIR