Frontend
Non l’ennesimo sito di statistiche: League of Legends dentro un sistema operativo virtuale, con filesystem, terminale e finestre.
Origine
Iodid ha una cronologia propria: il primo commit è del 9 luglio 2026. Il progetto parte già dall’idea di un sistema operativo virtuale, con shell desktop, dock, finestre, terminale e un primo modello di filesystem. Non è il porting del bot Discord: è un’interfaccia distinta sullo stesso dominio di dati.
Il problema progettuale non è soltanto mostrare una tabella di statistiche. Un profilo deve aprirsi da un URL, da un comando o da una finestra senza diventare tre prodotti diversi. Il percorso virtuale, l’identità del giocatore e la richiesta API devono mantenere lo stesso significato in ciascun ingresso.
La metafora OS ha anche un limite concreto: su mobile il desktop con finestre non viene semplicemente rimpicciolito. Cambia la superficie di navigazione, mentre dominio, query, dati e contenuti rimangono condivisi.
Come funziona
Profili, campioni e classifiche sono risorse del VFS. ls e cd navigano i percorsi; profile attiva il visualizzatore nel terminale. Le risorse pubbliche hanno anche URL condivisibili.
Ogni comando risolve un nodo del VFS; i dati arrivano dalle API di Beebot.
Framework
Ogni contenuto è un nodo di un filesystem virtuale unificato: profili, campioni e classifiche si aprono da finestre, terminale o URL indicizzabili. La navigazione di pagina resta separata dalle azioni solo interfaccia.
Desktop con finestre, terminale, scorciatoie persistenti e temi.
Namespace unico con nodi risorsa, permessi e route intent.
Moduli Next.js con metadata SEO, JSON-LD e sitemap.
API di Beebot, che resta l’unico backend del sistema.
Logica
Una pagina come /euw1/profile/Sunyx-0117 viene risolta lato server e apre il contesto corretto della shell. Il renderer pubblico e il desktop riusano i dati della stessa risoluzione, con metadati e contenuti iniziali prima dell’interazione JavaScript.
Il VFS distingue directory semantiche, risorse e file materializzati. Terminale, Hexplorer e navigazione delle finestre passano da questi nodi. Gli artefatti generati non devono sostituire una directory reale del dominio, né introdurre un secondo modo di risolvere la stessa identità.
Un comando interpreta ciò che l’utente vuole fare e lo passa ai proprietari del dominio. Non costruisce URL API e non esegue richieste Axios. LeagueApiEndpoint possiede i percorsi HTTP, LeagueApiClient il trasporto, LeagueApi la validazione e i mapper, LeagueApiQuery chiavi e politiche della cache.
I cataloghi e alcune pagine pubbliche vengono preparati in generazioni giornaliere e file HTML riutilizzabili. I profili dinamici e le varianti non preparate restano nel flusso SSR. Pending, dato vuoto e API non disponibile restano stati distinti: un errore temporaneo non diventa automaticamente un 404.
API ed esempi
I percorsi sono esempi del contratto del progetto. Il terminale opera sul filesystem virtuale del browser, non sul filesystem del computer del visitatore.
Esempio 01 / text
La regione resta parte del contesto. Il Riot ID è leggibile nell’URL pubblico; dopo la risoluzione, le chiamate per la stessa identità usano il PUUID. La vista non deve attendere l’apertura manuale di una finestra per esistere nell’HTML.
URL pubblico
/euw1/profile/Sunyx-0117
Risoluzione SSR → query condivise → HTML + metadati
Hydration → stesso contesto nella shellEsempio 02 / shell
help e pwd mostrano il contesto del terminale; ls esplora il namespace, windows elenca le finestre. Il cambio tema passa dal runtime condiviso, mantenendo i contenuti del prodotto.
help
pwd
ls /
windows
theme draculaEsempio 03 / text
Questo è un flusso architetturale, non una nuova API introdotta dal case study. Il profilo per nome e l’elenco delle partite sono endpoint del backend Beebot; Iodid li valida e li converte in modelli immutabili prima di usarli nelle viste.
Comando / URL / finestra
→ contesto VFS e route intent
→ LeagueApiQuery
→ LeagueApi + LeagueApiEndpoint
→ LeagueApiClient
→ API Beebot
→ modelli di dominio → vista condivisaEsempio 04 / text
La pagina Build ricava il ruolo canonico dai dati dei campioni. Per una vista MID di Ahri, la richiesta al backend usa il nome del campione e i codici di coda e ruolo. Patch, rango e regione sono filtri aggiuntivi; omettere region richiede l’aggregato di tutte le regioni.
Pagina pubblica
/champions/ahri/build
API Beebot, esempio di ruolo MID
GET /api/lol/champion/Ahri?queue=RANKED_SOLO_5X5&role=MIDTimeline
La timeline segue la cronologia del repository Iodid. I dati LoL arrivano da Beebot, ma le due storie Git rimangono distinte.
Il primo commit contiene già desktop, dock, window manager, terminale e risolutori di percorsi virtuali. Il progetto nasce intorno alla metafora OS, non la aggiunge come decorazione finale.
Il lavoro sulle API collega la shell ai dati del backend. Il problema diventa mantenere identità, conversione e stato delle richieste coerenti tra i diversi punti di ingresso.
Compaiono il lavoro sulla leaderboard e l’aggiornamento della sitemap. La navigazione da sistema operativo deve convivere con URL comprensibili e contenuti trovabili dai motori di ricerca.
I commit lavorano su sitemap statica e pagine prerenderizzate. Nei giorni successivi seguono titoli, percorsi dei campioni e un primo prototipo mobile.
Una sequenza di migrazioni separa token, temi, shell, chrome delle finestre e ricette dei materiali. Validator e strumenti browser accompagnano il lavoro: il tema deve essere una capacità condivisa, non una condizione copiata in ogni componente.
La migrazione unifica directory materializzate, artefatti, comandi e autocomplete. I risolutori iniziali lasciano spazio a un modello che possiede davvero i percorsi e i loro consumatori.
Il lavoro sui navigation intent preserva gli href e aggiunge Hexplorer per le directory virtuali. Aprire una risorsa dall’interfaccia non deve rompere link condivisibili e apertura in una nuova scheda.
Il refactor SEO rivede la rappresentazione pubblica delle risorse. Contenuto, canonical, stati dei dati e hydration devono derivare dalla stessa rotta risolta.
Snapshot isolati, pubblicazione atomica e preparazione HTML fuori dal percorso del visitatore riducono il lavoro ripetuto. Nello stesso ciclo vengono corretti i timer che trattenevano i QueryClient SSR dopo una richiesta.
Gli ultimi commit consultati proseguono il redesign, dopo il lavoro sul nuovo mobile e sulla home. Il contratto condiviso tra dati e navigazione serve proprio a permettere queste evoluzioni senza riscrivere il backend.
Stato attuale
Iodid non esegue un sistema operativo nel computer del visitatore. Usa finestre, comandi e filesystem virtuale come modello coerente per esplorare statistiche di League of Legends. La parte importante è la continuità della risorsa attraverso queste interfacce.
I contenuti pubblici convivono con una UI ricca: SSR, link HTML e policy di indicizzazione servono a rendere leggibili le pagine anche prima dell’hydration. Preparare snapshot non rende statico tutto il prodotto: partite, profili e richieste non preparate conservano i propri flussi.
Scelte progettuali
La stabilità del filesystem viene prima di ogni migrazione di routing, con terminale e window manager sempre operativi.
CostoLe migrazioni ampie slittano finché il VFS non regge.
Mapper, resolver, parser e cache hanno un’unica origine. Niente secondi percorsi API.
CostoPrima di scrivere codice va trovato il punto giusto.
Niente finestre né terminale: ogni pagina è un’app con barra a icone e componenti condivisi.
CostoDue esperienze da progettare, con gli stessi dati.
Scope