Come ha fatto Spotify a creare un'applicazione desktop multipiattaforma, leggera e ben progettata? Qual è la tecnologia dietro?

Il nucleo di tutti i nostri clienti è C++, ma quel nucleo si è condensato dopo il post di Rasmus, con funzionalità divise in moduli. Man mano che Spotify diventa disponibile su sempre più piattaforme, oltre a ottenere un set di funzionalità più ricco, dobbiamo assicurarci che il "core" non diventi "un po' di tutto". Questo ha significato suddividere alcune caratteristiche, come il controllo della riproduzione, nei loro propri moduli separati. Questi moduli sono ancora C++ ma sono abbastanza autonomi che la loro logica potrebbe teoricamente essere implementata in altri linguaggi. Chiamiamo il livello di interfaccia di questi moduli "Cosmos", e funziona in un modo non troppo dissimile da HTTP. Cosmos permette a qualsiasi parte del client di comunicare con un modulo usando percorsi e payloads arbitrari, permettendo un'architettura molto più flessibile. Alcuni ovvi benefici sono le interfacce versionate (esempio: GET sp://player/v1/main restituisce lo stato del giocatore) e JSON per il passaggio dei dati. Questo è importante per un altro cambiamento nel nostro client desktop.

Molto della nostra UI desktop in questi giorni sta usando Chromium Embedded Framework (CEF), che fondamentalmente significa che le nostre viste sono alimentate da JavaScript, HTML e CSS. Affinché tutti i nostri feature team siano in grado di lavorare sulle loro caratteristiche senza paura di rompere la vista di qualcun altro, ogni vista è sandboxata nel proprio "browser" (credo che si possa pensare alle viste come alle schede di Chrome, tranne che ne mostriamo più di una alla volta). Questo porta con sé una restrizione però: la condivisione dei dati tra le viste diventa più difficile. Qui è dove Cosmos entra in gioco e semplifica davvero la comunicazione tra il core (C++) e il terreno JavaScript: i client JS possono fare richieste arbitrarie e se c'è un binding, quella richiesta viene gestita e risponde. Un esempio è l'endpoint "messages" che permette a qualsiasi vista di inviare dati JSON a qualsiasi altra vista in ascolto (un po' come window.postMessage in HTML5, tranne che questo può anche interfacciarsi con i moduli C++). Questo è anche il modo in cui tutti i pulsanti di riproduzione nel client sanno se una traccia è in riproduzione o meno, o se è disponibile offline (un altro modulo Cosmos), o se avete salvato una canzone nella vostra musica.

Un altro importante cambiamento al nostro stack tecnologico è che abbiamo spostato alcune logiche più "indietro", nei servizi di aggregazione delle viste. Così, dove prima facevamo quasi tutta la logica nei client, usando solo il backend come magazzino di dati, ora facciamo molto più lavoro in uno strato logico tra i magazzini di dati e i client, esponendo endpoint molto simili a Cosmos (in effetti, si può chiamare un backend nello stesso modo in cui si chiama un modulo Cosmos, quindi muoversi tra i livelli non è una seccatura). La ragione di questo è duplice: uno, ci permette di espanderci a più piattaforme più rapidamente perché c'è meno logica client da implementare e due, ci aiuta davvero a mantenere il nostro comportamento client più coerente e aggiornato perché il client è più "stupido". Per mitigare qualsiasi rallentamento che potrebbe derivare da questo ci siamo assicurati che ci siano regole di caching per tutti i dati, in modo che il client conservi ancora i dati localmente, semplicemente non è responsabile di tanta logica di business come lo era prima.