Quelle est la langue ou de la technologie a été utilisée pour développer le Spotify application de bureau?

À partir d'ici: http://www.quora.com/What-is-the-technology-behind-the-Spotify-desktop-app

Date: 2014-09-09

Andreas Blixt, 5 ans, Spotify employé:

La base de tous nos clients est le C++, mais que le cœur a depuis Rasmus du
poste obtenu condensée, avec des fonctionnalités divisé en modules. Comme
Spotify devient disponible sur de plus en plus de plates-formes ainsi que
l'obtention d'un riche ensemble de fonctionnalités, nous devons nous assurer que "de base" n'est pas
devenir "un peu de tout". Cela signifie briser
certaines fonctions, telles que le contrôle de la lecture, dans leur propre
les modules. Ces modules sont toujours en C++, mais sont autonomes assez
que leur logique pourrait théoriquement être mis en œuvre dans d'autres
les langues. Nous en appelons à la couche d'interface de ces modules "Cosmos", et
il fonctionne d'une manière pas trop dissemblables de HTTP. Cosmos permet à toute partie
du client de communiquer avec un module à l'aide des chemins arbitraires et
les charges utiles, permettant plus de flexibilité de l'architecture. Certains évident
les avantages sont versionnées interfaces (exemple: OBTENIR sp://player/v1/main
renvoie le joueur de l'etat) et JSON pour le passage des données autour de. C'est
pour un autre changement dans nos client de bureau.

Beaucoup de notre INTERFACE utilisateur de bureau ces jours-ci est fait à l'aide de Chrome Intégré
Cadre (CEF), qui signifie fondamentalement nos points de vue sont alimentés par
JavaScript, HTML et CSS. Pour l'ensemble de nos équipes pour être en mesure de
travailler sur leurs fonctions sans crainte de casser quelqu'un d'autre en vue,
chaque point de vue est en bac à sable dans leur propre "navigateur" (je suppose que vous pouvez penser
des points de vue sous forme d'onglets dans Chrome, à l'exception de nous montrer plus qu'un à un
de temps). Cela entraîne une restriction cependant: le partage de données
entre les points de vue devient de plus en plus difficile. C'est là Cosmos et de
vraiment simplifie la communication entre le noyau (C++) et JavaScript
terres: la JS clients peuvent faire arbitraire demande et si il y a un
de liaison, qui demande sera traitée et traitée. Un exemple en est
les "messages" de point de terminaison, qui permet à tout point de vue de pousser les données JSON à tout
autre point de vue, qui est à l'écoute (un peu comme de la fenêtre.postMessage en HTML5,
sauf cela, on peut aussi l'interface avec le C++ modules). C'est aussi la façon dont
tous les boutons de lecture dans le client de savoir si une piste est en cours de lecture ou
pas, ou si il est disponible en mode hors connexion (un autre Cosmos module), ou
si vous avez enregistré une chanson à votre la musique.

Un autre changement important à notre technologie de pile, c'est que nous avons déménagé
un peu de logique plus loin "retour", en vue d'agrégation de services. Alors, où nous
serait avant de faire presque tout dans la logique des clients, en utilisant uniquement de l'
backend comme une banque de données, nous avons maintenant de faire beaucoup plus de travail dans une logique de couche
entre les banques de données et les clients, exposant les points de terminaison de très
semblable à Cosmos (en fait, vous pouvez faire appel à un backend exactement de la même manière
vous appelez un Cosmos module, donc le déplacement entre les couches n'est pas une corvée).
La raison pour cela est de deux ordres: l'un, cela nous permet d'étendre à plus
les plates-formes plus rapidement, car il y a moins de clients logique à mettre en œuvre
et de deux, il nous aide vraiment à garder notre client un comportement plus conforme
et up-to-date, car le client est plus "stupide". Pour atténuer les
ralentissement qui pourrait venir de cela, nous avons veillé à ce qu'il y a
la mise en cache des règles pour toutes les données, de sorte que le client aura toujours conserver les données
localement, il est tout simplement pas responsable pour autant la logique des affaires comme ça
utilisé pour être.

Selon un Spotify designer:

http://twitter.com/#!/tobiasahlin/statut/96483609799692288

"Certains de il est en C++, et certains de il est dans un HTML-ish langage de balisage appelé "Araignée"
"Il est construit uniquement à être utilisés à l'intérieur de Spotify"

De leur site web:

Spotify est construit principalement en Python et C++

Vérifier la première réponse ici:
https://www.quora.com/What-is-the-technology-stack-behind-the-Spotify-web-client

Andreas Blixt qui est un ancien de la Technologie Plomb à Spotify a répondu en détails.

Nous avons un PHP couche qui traite de la connexion (et quelques autres
logique côté serveur), ainsi qu'à des applications dans des domaines différents (pour
des raisons de sécurité). Le reste n'est que du JavaScript.

Pour le JavaScript pour communiquer avec le backend, il le fait via
ce que nous appelons un" point d'accès (AP), un très C++ optimisé service
qui peut gérer beaucoup de connexions actives à la fois. Ce service est
responsable du routage des requêtes vers le bon service principal. Cette
le service est capable de courir sur les ports 80 et 443 pour surmonter
restrictions de pare-feu. La communication se fait via WebSocket (ou
Flash pour certains navigateurs).

Pour communiquer avec spécifique des services back-end, nous router les demandes
par le biais de l'AP à l'aide de notre propre service de transport appelé "Hermes". C'est
fondamentalement, un schéma d'URL qui permet à l'AP de savoir où envoyer les
demande. Les charges sont codés comme des Protobuf. Hermès a une belle mise en cache
système (nous l'appelons le "Mercure") qui stocke les résultats de IndexedDB pour
les navigateurs qui le supportent (nous avons le même système dans le bureau
client, mais plutôt implémenté en C++), pour éviter de demander la même
les données deux fois. Ceci est très utile pour les ressources qui se re-demandé un
beaucoup, comme les artistes, les albums et les titres.

Pour l'INTERFACE utilisateur, nous avons écrit un assez avancé cadre d'application
(appelé "Point") pour permettre à tout point de vue est développé
de manière indépendante par des équipes différentes, sans avoir à vous soucier de
casser quoi que ce soit. Les points de vue de fonctionner dans un bac à sable , mais peut
dépendent encore des bibliothèques partagées pour le commun des choses telles que le chargement de
métadonnées de la piste, etc. A ce jour, nous avons ~35 vues uniques (ou
apps) dans le lecteur web.

Vue d'obtenir des données et effectuer des actions par le biais de ce que nous appelons un "pont"
(en gros, une API) à l'aide de postMessage, de sorte que nous n'avons pas besoin de
réinitialiser toutes les communes de code pour chaque application. La chose vraiment cool
c'est que beaucoup de ceux ~35 points de vue je l'ai mentionné avant peut
en fait exécuter à l'intérieur de l'ordinateur client sans modification. De
bien sûr, au lieu de postMessage ils seront à l'aide d'un crochet en Chrome
Intégré au Cadre, et de notre C++ de base.

Nous essayons d'utiliser le HTML 5 de technologies autant que possible, mais dans certains
cas dépendent de Flash. Je pense que nous avons vraiment cool tech pile pour
notre player web en général.