From here: http://www.quora.com/What-is-the-technology-behind-the-Spotify-desktop-app
Dated: 2014-09-09
Andreas Blixt, 5-year Spotify employee:
The core of all our clients is C++, but that core has since Rasmus’s
post gotten condensed, with functionality split out into modules. As
Spotify becomes available on more and more platforms as well as
getting a richer feature set, we need to ensure that “core” doesn’t
become “a little bit of everything”. This has meant breaking out
certain features, such as playback control, into their own separate
modules. These modules are still C++ but are self-contained enough
that their logic could theoretically be implemented in other
languages. We call the interface layer to these modules “Cosmos”, and
it works in a way not too dissimilar from HTTP. Cosmos lets any part
of the client communicate with a module using arbitrary paths and
payloads, allowing for a much more flexible architecture. Some obvious
benefits are versioned interfaces (example: GET sp://player/v1/main
returns player state) and JSON for passing data around. This is
important for another change in our desktop client.A lot of our desktop UI these days is actually using Chromium Embedded
Framework (CEF), which basically means our views are powered by
JavaScript, HTML and CSS. For all of our feature teams to be able to
work on their features without fear of breaking someone else’s view,
each view is sandboxed in their own “browser” (I guess you can think
of the views as tabs in Chrome, except we show more than one at a
time). This brings with it one restriction though: sharing data
between views gets more difficult. This is where Cosmos comes in and
really simplifies the communication between core (C++) and JavaScript
land: the JS clients can make arbitrary requests and if there’s a
binding, that request gets handled and responded to. One example is
the “messages” endpoint which lets any view push JSON data out to any
other view that’s listening (kind of like window.postMessage in HTML5,
except this one can also interface with C++ modules). This is also how
all the play buttons in the client know whether a track is playing or
not, or whether it’s available offline (another Cosmos module), or
whether you’ve saved a song to your music.Another important change to our technology stack is that we’ve moved
some logic further “back”, into view aggregation services. So where we
would before do almost all logic in the clients, only using the
backend as a data store, we now do much more work in a logic layer
between the data stores and the clients, exposing endpoints very
similar to Cosmos (in fact, you can call a backend the exact same way
you call a Cosmos module, so moving between layers is not a hassle).
The reason for this is two-fold: one, it lets us expand to more
platforms more quickly because there’s less client logic to implement
and two, it really helps us keep our client behavior more consistent
and up-to-date because the client is more “stupid”. To mitigate any
slowdown that might come from this we have ensured that there are
caching rules for all data, so that the client will still keep data
locally, it’s just not responsible for as much business logic as it
used to be.