ESI consegnato: il prossimo capitolo

All'inizio di quest'anno, abbiamo condiviso un'analisi approfondita della tecnologia che alimenta lo sviluppo di terze parti in EVE Online: ESI. Essendo la spina dorsale dell'ecosistema di sviluppatori di EVE, ESI collega i creatori all'universo di New Eden, abilitando qualsiasi cosa, dagli strumenti di gestione della flotta alle app di pianificazione industriale e alle integrazioni killboard. Questi strumenti sono diventati essenziali per i capsuleer e l'API che li supporta merita lo stesso livello di cura e attenzione del gioco stesso.

Ascoltalo direttamente dai nostri sviluppatori! Dai un'occhiata al podcast di accompagnamento per questo blog degli sviluppatori, qui:

Youtube - Chat degli sviluppatori: EVE si è evoluto - ESI consegnato: il prossimo capitolo

L'articolo rivisitava le origini dell'API, spiegava come funziona oggi l'ESI e delineava una tabella di marcia per modernizzare la piattaforma. Gli obiettivi erano chiari: migliorare l'affidabilità, ritirare i componenti obsoleti e gettare le basi per nuove funzionalità.

Da allora sono stati compiuti progressi significativi. Il monitoraggio è stato ampliato per fornire un quadro più chiaro di come viene utilizzato ESI, quali applicazioni stanno effettuando richieste, con quale frequenza e con quanta efficacia viene applicata la memorizzazione nella cache. Gli endpoint obsoleti sono stati rimossi, sono stati adottati i primi passi verso la limitazione della velocità e la gestione degli errori è stata perfezionata. Questi sforzi hanno reso l’ESI più stabile e pronto a supportare nuove capacità.

Queste basi hanno portato al primo importante rilascio di funzionalità con questo approccio rinnovato: il lancio dei percorsi Corporation Projects. Ciò segna il debutto degli endpoint basati su Data Hub in ESI, fornendo dati più ricchi, impaginazione più efficiente e meno viaggi di andata e ritorno per gli sviluppatori. È un esempio di dove è diretta la piattaforma e un segno di ciò che è possibile fare quando stabilità e modernizzazione aprono la strada a nuove funzionalità.

Questo aggiornamento esamina più da vicino ciò che è cambiato da allora: gli sforzi di pulizia, i sistemi messi in atto e un'anteprima di ciò che verrà dopo.

Ottenere una visione chiara

Nel nostro ultimo aggiornamento abbiamo parlato dei piani per migliorare l'osservabilità all'interno dell'ESI. Negli ultimi mesi, questo sforzo è maturato in qualcosa di molto più potente. Con l'aiuto di Honeycomb, ora abbiamo piena visibilità sulle richieste in arrivo a ESI e su dove vengono instradate. Che si tratti di Quasar o del Monolito, possiamo tracciare l'intero percorso dall'inizio alla fine.

Uno dei maggiori vantaggi derivanti da questo approccio è stato comprendere le reali fonti degli errori 5xx. Fino a poco tempo fa, molte di queste erano supposizioni. Ora sappiamo esattamente cosa sta succedendo.

Alcuni esempi che vale la pena citare:

• Quando il Monolito ha restituito un 404, ma le specifiche API per quel percorso non includevano 404 come possibile risposta, ESI lo ha tradotto in 500. Ciò ha portato a errori in cui un 404 sarebbe stato il risultato corretto e previsto. Questo comportamento è stato corretto.
• Il timeout della nostra connessione HTTP è stato impostato su un solo secondo di inattività. Sfortunatamente, il sistema di bilanciamento del carico prevedeva che le connessioni inattive rimanessero aperte per almeno 60 secondi. Questa mancata corrispondenza ha causato un numero di errori 504 quando le connessioni venivano chiuse prematuramente. Ora è stato risolto.

Questi sono solo due dei numerosi problemi scoperti e risolti negli ultimi mesi. Il risultato è un calo misurabile degli errori 5xx. Di seguito è riportato un confronto prima e dopo.

Rimangono ancora alcuni casi su cui indagare e continueremo a lavorarci. Detto questo, l’attuale tasso 5xx è già molto basso (circa una su 10.000 richieste), quindi la maggior parte degli utenti non dovrebbe più notare alcun problema.

Pulizia della nave

Per molto tempo ESI ha supportato due diversi metodi di autenticazione: uno dei quali, internamente noto come “v1”, risale alle prime versioni dell’API. Il flusso "v2" più recente utilizza JWT, che consentono la verifica dei token localmente, senza contattare l'SSO per ogni richiesta. Potrebbe sembrare un piccolo dettaglio, ma quando gestisci migliaia di richieste al secondo, la differenza è enorme. I JWT sono più veloci, più semplici e molto meno impegnativi in ​​termini di infrastrutture.

Sebbene "v1" sia stato ufficialmente deprecato nel 2021, il supporto è rimasto attivo per evitare di interrompere gli strumenti di terze parti che ancora si affidavano ad esso. Fino a poco tempo fa, però, non c’era abbastanza visibilità per valutare quanto fosse ancora in uso.

Ciò è cambiato con i miglioramenti dell’osservabilità. Con le tracce complete delle richieste ora disponibili, è diventato possibile identificare quali applicazioni utilizzavano ancora i token "v1" esaminando le intestazioni User-Agent e gli ID delle applicazioni. Ove possibile, gli sviluppatori interessati sono stati contattati direttamente e incoraggiati a migrare. Fatto ciò, abbiamo pubblicato un avviso di deprecazione finale e abbiamo proceduto alla rimozione completa poche settimane dopo.

Un approccio simile è stato adottato con la rimozione di diverse versioni di percorsi obsolete. Innanzitutto, abbiamo contattato direttamente gli sviluppatori, quindi abbiamo inviato avvisi pubblici prima che venissero applicate eventuali deprecazioni. Poiché gli strumenti continuano a migliorare, questo tipo di processo (osservare, informare, agire) sta diventando lo standard. È un modo più pulito e prevedibile per ritirare i componenti legacy senza sorprese.

Instradamento del flusso

Negli ultimi mesi gran parte delle infrastrutture dell’ESI sono state ricostruite. L’obiettivo è stato duplice: modernizzare i sistemi utilizzando gli attuali standard interni come Terraform e Go e ritirare gradualmente i componenti legacy che non servivano più a uno scopo chiaro.

Al centro di questa revisione c'è un nuovo servizio noto come API Gateway. La sua responsabilità è gestire le richieste in arrivo: controllare l'autenticazione, applicare i limiti di velocità, convalidare percorsi e tenant e quindi trasmetterli al backend appropriato. Nel momento in cui una richiesta raggiunge la sua destinazione, è già stata esaminata. Ciò elimina la necessità che i servizi di backend ripetano gli stessi controlli e rende il sistema complessivo più semplice e affidabile.

Questa nuova architettura porta anche una migliore visibilità. Con il gateway che funge da punto di ingresso unico, il traffico può ora essere osservato in modo più dettagliato, sia in termini di tracciamento che di metriche. Questa ulteriore conoscenza ha reso più semplice il rilevamento tempestivo dei problemi e la risposta più precisa durante gli incidenti.

Un'analisi più dettagliata della progettazione e dell'implementazione del gateway è stata condivisa in un precedente post del blog. Al momento in cui scrivo, le fasi finali di implementazione sono quasi completate. La parte principale ancora in corso è la limitazione della velocità, che verrà trattata in seguito.

Impostare i confini

Nell'ambito del nostro impegno continuo per gestire il traffico ESI, abbiamo implementato i primi passi verso la limitazione della velocità nel gateway API. Attualmente è in modalità “solo monitor”. In questo modo stiamo raccogliendo informazioni su quali saranno i limiti tariffari validi prima di applicarli effettivamente.

La limitazione della velocità è stata un argomento ricorrente internamente e all'interno della comunità di sviluppatori di terze parti. Fino ad ora, all’ESI mancavano buone opzioni per gestire il traffico problematico. Sebbene alcuni modelli fossero chiaramente offensivi, la risposta principale è stata il divieto degli IP: manuale, reattivo e non ideale per chiunque sia coinvolto. Un approccio più proattivo è atteso da tempo.

Di seguito è mostrato un caso estremo: un singolo utente che invia una marea di richieste ben oltre ogni ragionevolezza. Quell'account è stato bannato. Sia chiaro: questo tipo di traffico non è accettabile.

Il problema più comune sono i picchi di traffico regolari, soprattutto ogni ora e mezz'ora. Percorsi come /assets/ sono spesso i più colpiti, con picchi di traffico fino a cinque volte superiori al normale. La scalabilità per soddisfare questi picchi mette a dura prova API Gateway, Monolith e Quasar. Esiste un limite all’estensione dell’infrastruttura solo per gestire il traffico esplosivo. Levigare questi picchi è essenziale.

Ciò si applica principalmente a framework più grandi e app ampiamente utilizzate. Se hai appena iniziato o hai una piccola base di utenti, non c’è motivo di preoccuparsi. Ma per gli strumenti con un’ampia distribuzione, vale la pena rivedere come vengono pianificate le richieste.

L'applicazione delle norme non inizierà senza preavviso. Un post dettagliato sul blog verrà condiviso in anticipo per dare agli sviluppatori la possibilità di prepararsi.

Stare al passo con gli standard

Un importante aggiornamento implementato di recente è la migrazione da Swagger 2.0 a OpenAPI 3.1. OpenAPI è la naturale evoluzione di Swagger, affrontando le limitazioni che rendevano difficile rappresentare accuratamente alcune delle strutture interne di ESI. Anche il supporto degli strumenti è cambiato poiché molti strumenti moderni supportano solo OpenAPI, mentre il supporto di Swagger è costantemente diminuito. Tenendo questo in mente, abbiamo deciso di migrare tutto ESI su OpenAPI.

Oltre all'aggiornamento delle specifiche, abbiamo anche modificato il modo in cui viene eseguita la versione dell'API. Le versioni ora sono basate sulla data e si applicano a tutta l'API. Ciò fornisce informazioni più chiare su quanto è recente una versione e rende più semplice sia per i team interni che per gli sviluppatori di terze parti tenere traccia della versione in uso. La transizione è stata resa più agevole grazie al nuovo API Gateway, che ha consentito di introdurre il nuovo sistema di controllo delle versioni senza interrompere le integrazioni esistenti. Gli sviluppatori possono adottare il nuovo modello secondo i propri ritmi (entro limiti ragionevoli) nel corso di circa un anno a partire da luglio 2025.

Progetti aziendali: ora disponibili

I progetti aziendali consentono ai leader aziendali di stabilire obiettivi di collaborazione per i membri, come trasportare materiali, uccidere ostili o contribuire con ISK, monitorando la partecipazione e premiando i membri che aiutano. È un sistema flessibile per dirigere l’attività di gruppo senza microgestione. Maggiori dettagli sulla funzionalità stessa possono essere trovati nella Panoramica di EVE Academy.

Oggi, i percorsi dei Progetti Corporativi diventano disponibili al pubblico (inserisci l'emoji del razzo, ma la pagina web non ce lo consente)

Gli sviluppatori possono ora eseguire query su ESI per quanto segue:

• Un elenco di tutti i progetti aziendali attivi
• Dettagli di un progetto aziendale, incluso il suo stato attuale e montepremi
• Un elenco di contributori al progetto e i loro contributi

Per sviluppatori

Come menzionato nel precedente aggiornamento di EVE Evolved, l'obiettivo a lungo termine è spostare il traffico più pesante in lettura sul Data Hub. Questi percorsi sono i primi a seguire quel modello. Sono stati realizzati in stretta collaborazione con il team di Data Engineering e segnano un passo avanti verso il disaccoppiamento dell'ESI dal Monolito.

I vantaggi sono già visibili:

• Risposte più complete alle inserzioni: il nuovo percorso di inserzione dei progetti include informazioni dettagliate e di alto livello come progressi, ISK ricompensati e altri parametri in tempo reale, senza richiedere una chiamata di follow-up per ciascun progetto.
• Impaginazione basata su cursore: invece di scorrere le pagine o aggiornare ogni visualizzazione dei dettagli, gli sviluppatori possono eseguire il polling dell'endpoint dell'elenco per vedere cosa è cambiato. È più efficiente per le applicazioni e più semplice per l'API stessa.
• Risoluzione estesa delle entità: ove possibile, gli ID vengono risolti in nomi. Ad esempio, i creatori del progetto vengono visualizzati sia con l'ID del personaggio che con il nome, riducendo la necessità di ulteriori ricerche. Anche se questo non è disponibile per tutti i campi, è incluso dove possibile.

Il risultato è un punto di integrazione più pulito e veloce che offre agli sviluppatori maggiore anticipo e riduce i viaggi di andata e ritorno non necessari. Se il lancio avrà successo, questo progetto servirà da base per altre nuove rotte in futuro.

Cosa c'è dopo?

La prossima importante aggiunta a ESI è il supporto per i lavori freelance. Proprio come Corporation Projects, questo sistema consentirà agli sviluppatori di accedere a dati strutturati sui lavori disponibili in New Eden: cosa viene offerto, dove, da chi e quali sono i premi.

Lo sviluppo è già in corso. Il feedback raccolto dal lancio dei Progetti Corporativi viene inserito direttamente nella progettazione di questi nuovi percorsi, aiutandoci a perfezionare l'interfaccia e la struttura prima che raggiungano il rilascio pubblico. Lavori freelance adotterà anche i nuovi modelli introdotti con Progetti aziendali, inclusi dati di elenchi più ricchi, risoluzione dei nomi e impaginazione basata su cursore. Ciò dovrebbe rendere più semplice la creazione di applicazioni che espongano un'ampia varietà di attività di gioco con cui i capsuleer possono impegnarsi in un dato momento.

Maggiori dettagli saranno condivisi nelle prossime settimane mentre perfezioniamo le specifiche.

ESI sei tu

Dietro ogni strumento di terze parti, app adatta o dashboard personalizzata c'è la creatività e l'impegno della comunità di sviluppatori di EVE. Che tu stia costruendo strumenti per la tua azienda, contribuendo a strutture ampiamente utilizzate o semplicemente armeggiando per migliorare il tuo gameplay, questi contributi modellano l'esperienza di innumerevoli capsuleer.

Se stai cercando di potenziare la tua esperienza EVE, la pagina Strumenti e servizi della community è un ottimo punto di partenza. E se vuoi dare un'occhiata più da vicino all'ecosistema stesso, dai un'occhiata a questa presentazione dello sviluppatore RIFT e partner di EVE Nohus per approfondimenti su strumenti, flussi di lavoro e idee che plasmano il futuro dello sviluppo di terze parti. Inoltre, sapevi che abbiamo un componente aggiuntivo ufficiale di Excel per l'accesso diretto ai dati di gioco di EVE all'interno dei fogli di calcolo?

Se sei uno sviluppatore alle prime armi o con anni di esperienza alle spalle, ecco alcune risorse chiave da esplorare:

• Portale per sviluppatori EVE: il tuo hub principale per lo sviluppo di terze parti. Qui puoi registrare applicazioni, accedere alla documentazione API e SSO, blog di sviluppo di terze parti e feed RSS di notizie disponibili) e trovare risorse aggiuntive da integrare con EVE Online.
• Problemi e richieste di funzionalità ESI – Il repository principale per tenere traccia di bug, segnalare problemi e richiedere nuove funzionalità ESI. Sia gli sviluppatori che i capsuleer possono impegnarsi qui per contribuire a plasmare il futuro di ESI.
• Partecipa alla discussione su Discord – Entra in contatto con gli sviluppatori CCP e gli sviluppatori di terze parti unendoti al canale #3rd-party-dev-and-esi sul server Discord ufficiale di EVE Online per condividere idee, porre domande e collaborare a nuovi progetti. Puoi anche iscriverti al canale di annunci del blog #3rd-party-dev per ricevere le notizie direttamente sul tuo Discord!