前端是用 FLEX 编写的，请在您的 Mac 或 Windows 计算机上查看源代码。 你会看到很多flex文件格式的xml文件。
当然，与服务器的连接和平台集成可能是用 C++ 本机编写的。 但UI部分只是FLEX...
The frontend is written in FLEX, checkout the sources on your mac or windows machine. You will see a lot of xml file which are in the flex file format.
Off course the connection to the server and platform integration is probably written natively in c++. But the UI part is just FLEX...
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.
The Spotify Desktop client is a Windows and Mac native application that uses CEF (Chromium Embedded Framework) to display a web-based user interface. That’s still true today, but for the previous version of Desktop, every “page” in the client was built as a standalone “app” to run inside its own iframe.
However, they recently had to update their architecture because they wanted to integrate their Web Player built with React and Desktop Client in a way that a single team can develop and ship features for both clients.
The final architecture looks like a layer of Platform APIs that expose the underlying Spotify ecosystem to clients, with a React-based user interface and the Platform APIs exposed via React Hooks. Thus, the new UI can run on the web, and it can run in our Desktop container, and never know, or care, if the data is coming from our C++ stack or our web infrastructure.
鉴于它在 Windows 上运行，显然不是 .NET（进程资源管理器告诉我这一点），没有遵循 AIR 安装过程，我想说的是使用跨平台库的 C++。
所有内容都被编译成一个可执行文件，这表明他们可以访问所有依赖项的源。
对于 Techno 来说……我认为他们使用了 Hardhouse Electronica
Given it's running on windows, clearly not .NET (Process explorer is telling me that), didn't follow a AIR install process, I'd say C++ using cross platform libraries.
Everything is compiled down into one executable, which indicates they had access to the source of all dependencies.
W.r.t to Techno...i think they used Hardhouse Electronica
Andreas Blixt who is a former Technology Lead at Spotify has answered it in details.
We have a PHP layer that deals with logging in (and some other server-side logic) as well as serving apps on different domains (for security reasons). The rest is all JavaScript.
For the JavaScript to communicate with the backend, it does so via what we call an "access point" (AP), a highly optimized C++ service which can handle lots of active connections at once. This service is responsible for routing requests to the correct backend service. This service is capable of running over ports 80 and 443 to overcome firewall restrictions. The communication is done over WebSocket (or Flash for some browsers).
To communicate with specific backend services, we route the requests through the AP using our own transport called "Hermes". This is basically a URL scheme that lets the AP know where to send the request. Payloads are encoded as Protobuf. Hermes has a nice caching system (we call it "Mercury") that stores results to IndexedDB for browsers that support it (we have the same system in the desktop client, but instead implemented in C++), to avoid requesting the same data twice. This is very useful for resources that get re-requested a lot, such as artists, albums and tracks.
For the UI we have written a pretty advanced application framework (called "Stitch") for allowing every view to be developed independently by different teams without having to worry about breaking anything. The views run in a sandboxed , but can still depend on shared libraries for common things such as loading track metadata, etc. As of this writing we have ~35 unique views (or apps) in the web player.
Views get data and perform actions via what we call a "bridge" (basically, an API) using postMessage, so that we don't need to reinitialize all the common code for every app. The really cool thing about this is that a lot of those ~35 views I mentioned before can actually also run inside the desktop client without modification. Of course, instead of postMessage they will be using a hook into Chromium Embedded Framework, and our C++ core.
We try to use HTML 5 technologies as much as possible but in some cases depend on Flash. I think we have a really cool tech stack for our web player in general.
发布评论
评论（10）
问题跟踪器：
安全性：
其他：
标签管理器：
JavaScript 库：
PaaS：
Envoy：
其他：
Issue trackers:
Security:
Miscellaneous:
Tag managers:
JavaScript libraries:
PaaS:
Envoy:
Others:
前端是用 FLEX 编写的，请在您的 Mac 或 Windows 计算机上查看源代码。 你会看到很多flex文件格式的xml文件。
当然，与服务器的连接和平台集成可能是用 C++ 本机编写的。 但UI部分只是FLEX...
The frontend is written in FLEX, checkout the sources on your mac or windows machine. You will see a lot of xml file which are in the flex file format.
Off course the connection to the server and platform integration is probably written natively in c++. But the UI part is just FLEX...
从这里：http://www.quora。 com/Spotify-desktop-app 背后的技术是什么
日期：2014-09-09
From here: http://www.quora.com/What-is-the-technology-behind-the-Spotify-desktop-app
Dated: 2014-09-09
以下是他们使用的第三方组件的列表（当然是在 C++ 之上）：
Here's the list of third-party components they use (on top of C++ of course):
根据 Spotify 设计师的说法：
http://twitter.com/#!/tobiasahlin/status/96483609799692288
“其中一些是用 C++ 编写的，另一些是用一种名为 Spider 的 HTML 标记语言编写的”
“它专为在 Spotify 内使用而设计”
According to a Spotify designer:
http://twitter.com/#!/tobiasahlin/status/96483609799692288
"Some of it is in C++, and some of it is in a HTML-ish markup language called Spider"
"It's built solely to be used within Spotify"
Spotify 现在使用 Chromium 嵌入式框架 (CEF) 在桌面内显示由 HTML/CSS/JavaScript 组成的网络界面应用。
Spotify now uses the Chromium Embedded Framework (CEF) to display a web interface consisting of HTML/CSS/JavaScript within the desktop application.
这个答案是更新的，来自他们的工程博客：https://engineering.atspotify.com/2021/04/07/building-the-future-of-our-desktop-apps/
但是，他们最近必须更新其架构，因为他们希望集成使用 React 构建的 Web Player 和 桌面客户端，以便单个团队可以开发和发布功能两个客户。
架构图
This answer is more updated and coming from their engineering blog: https://engineering.atspotify.com/2021/04/07/building-the-future-of-our-desktop-apps/
However, they recently had to update their architecture because they wanted to integrate their Web Player built with React and Desktop Client in a way that a single team can develop and ship features for both clients.
Architecture Diagram
从他们的网站：
From their website:
鉴于它在 Windows 上运行，显然不是 .NET（进程资源管理器告诉我这一点），没有遵循 AIR 安装过程，我想说的是使用跨平台库的 C++。
所有内容都被编译成一个可执行文件，这表明他们可以访问所有依赖项的源。
对于 Techno 来说……我认为他们使用了 Hardhouse Electronica
Given it's running on windows, clearly not .NET (Process explorer is telling me that), didn't follow a AIR install process, I'd say C++ using cross platform libraries.
Everything is compiled down into one executable, which indicates they had access to the source of all dependencies.
W.r.t to Techno...i think they used Hardhouse Electronica
在这里检查第一个答案：
https://www.quora. com/What-is-the-technology-stack-behind-the-Spotify-web-client
Spotify 前技术主管 Andreas Blixt 对此进行了详细解答。
Check the first answer here:
https://www.quora.com/What-is-the-technology-stack-behind-the-Spotify-web-client
Andreas Blixt who is a former Technology Lead at Spotify has answered it in details.