JavaScript @ Spotify - JSConf Iceland 2016

A talk about the architecture of the Spotify Desktop application, which is currently based on Web technologies. How we organize our teams, war stories and lessons learned during our development process.

This is not a talk about one specific framework or tool, but about how we work with JavaScript in an environment that is a bit different from most web-based apps, the experiences we've had and some ideas that can be useful and applicable in different contexts.

1. JS @ SPOTIFY FELIPE RIBEIRO | @FELIPERNB
2. SPOTIFY FOR DESKTOP IS A WEB-BASED APP
3. A BIT OF HISTORY…
7. WEB VIEWS INSIDE THE CLIENT WITH CEF
12. WEB ALL THE THINGS!!1!
14. TO REWRITE OR NOT TO REWRITE?
15. ENGINEERING THINKING
16. THE ARCHITECTURE
17. client-core client-desktop Chromium Embedded Framework JS Container Browse Search Radio Playlist
19. DID YOU JUST SAY *IFRAMES*? !
20. THE CODEBASE
21. ▸ one repository per app (playlist, browse, search, …) ▸ one repository per lib ▸ internal npm registry to publish and distribute the libs
22. NOPE !
23. WHY NOT?
24. HARD TO COORDINATE HORIZONTAL CHANGES
25. COMPLICATES CI, TESTABILITY AND STANDARDIZATION
26. dependencies: { "spotify-css": "~1.0.0", "spotify-uri": "~1.5.0" } dependencies: { "spotify-css": "~2.0.0", "spotify-uri": "~1.0.0" }
28. One repo to rule them all — Git Sauron
29. MONOREPO !
30. ▸ simplified CI ▸ easier to test the impact of changes ▸ free to break backwards compatibility ▸ atomic refactorings (and rollbacks) ▸ consistency and standardization
32. things are simpler than before, but there’s still a lot of entropy
33. GOLDEN PATH
34. ▸ standardization workgroup ▸ de-facto standards and path of least resistance ▸ data-driven decision making
35. LESSONS LEARNED
36. ▸ evolve things incrementally ▸ no “ivory tower” infra team ▸ architecture shouldn't depend on repository organization ▸ consistency is paramount
37. spotify.com/jobs
38. THANKS @FELIPERNB