Como Spotify fez uma aplicação desktop multiplataforma, leve e bem desenhada? Qual é a tecnologia por trás disso?

O núcleo de todos os nossos clientes é C++, mas esse núcleo ficou condensado desde o pós Rasmus&apos, com a funcionalidade dividida em módulos. À medida que o Spotify se torna disponível em cada vez mais plataformas, assim como um conjunto de funcionalidades mais rico, precisamos de garantir que o "core" não se torne "um pouco de tudo". Isto significou quebrar certas funcionalidades, como o controlo de reprodução, nos seus próprios módulos separados. Estes módulos ainda são C++ mas são suficientemente autónomos para que a sua lógica possa teoricamente ser implementada em outras linguagens. Nós chamamos a camada de interface para estes módulos de "Cosmos", e funciona de uma forma não muito diferente do HTTP. O Cosmos permite que qualquer parte do cliente se comunique com um módulo usando caminhos e cargas úteis arbitrárias, permitindo uma arquitetura muito mais flexível. Alguns benefícios óbvios são interfaces versionadas (exemplo: GET sp://player/v1/main retorna o estado do jogador) e JSON para passar dados. Isto é importante para outra mudança em nosso cliente desktop.

Uma grande parte da nossa interface desktop hoje em dia está usando o Chromium Embedded Framework (CEF), o que basicamente significa que nossas views são alimentadas por JavaScript, HTML e CSS. Para que todas as nossas equipes de recursos sejam capazes de trabalhar em suas funcionalidades sem medo de quebrar a visão de alguém&apos, cada visão é sandboxed em seu próprio "browser" (acho que você pode pensar nas visões como abas no Chrome, exceto que nós mostramos mais de uma de cada vez). Mas isto traz consigo uma restrição: partilhar dados entre as views torna-se mais difícil. É aqui que entra o Cosmos e simplifica realmente a comunicação entre o núcleo (C++) e o JavaScript: os clientes JS podem fazer pedidos arbitrários e se houver's uma ligação, esse pedido é tratado e respondido. Um exemplo é o endpoint "mensagens" que permite que qualquer visualização empurre os dados JSON para qualquer outra visualização que's escute (como window.postMessage em HTML5, excepto que este também pode interagir com módulos C++). Isto também é como todos os botões de play no cliente sabem se uma faixa está tocando ou não, ou se ela's está disponível offline (outro módulo Cosmos), ou se você've salvou uma música na sua música.

Outra mudança importante na nossa pilha de tecnologia é que nós've moveu um pouco mais de lógica "para trás", para os serviços de agregação de view. Assim, onde antes fazíamos quase toda a lógica nos clientes, usando apenas o backend como data store, agora fazemos muito mais trabalho em uma camada lógica entre os data stores e os clientes, expondo pontos finais muito semelhantes ao Cosmos (na verdade, você pode chamar um backend exatamente da mesma forma que chama um módulo Cosmos, então mover-se entre as camadas não é um incômodo). A razão para isso é dupla: uma, nos permite expandir para mais plataformas mais rapidamente porque há menos lógica de cliente para implementar e duas, realmente nos ajuda a manter nosso comportamento de cliente mais consistente e atualizado porque o cliente é mais "estúpido". Para mitigar qualquer desaceleração que possa vir disso, garantimos que existem regras de cache para todos os dados, para que o cliente ainda mantenha os dados localmente, it's apenas não é responsável por tanta lógica de negócio como costumava ser.