Ecco cosa succede quando chiedi a degli sviluppatori di tracciare gli asteroidi in avvicinamento alla terra

28/05/2026 - 9 min di lettura

La NASA mette a disposizione un'API pubblica che traccia gli Near Earth Objects, asteroidi e comete che passano pericolosamente vicino alla Terra. Abbiamo chiesto alla community di costruirci sopra qualcosa. Quello che è uscito ha superato ogni aspettativa.

La sfida

Il brief era volutamente aperto: usare la NASA NeoWs API per costruire qualcosa di utile, informativo o bello. Nessun vincolo di linguaggio, nessun framework obbligatorio, nessuna struttura imposta. Solo un dataset affascinante e una settimana di tempo.

Il dataset della NASA cataloga ogni oggetto astronomico che si avvicini alla Terra entro 1.3 AU — circa 194 milioni di km. Ogni NEO ha massa stimata, velocità relativa, distanza minima di approccio e un flag is_potentially_hazardous_asteroid che, detto così, è già un prompt narrativo di per sé.

👉 La challenge é terminata, ma puoi comunque provarla per arricchire i progetti del tuo portfolio: https://arkemis.it/challenges/nasa-neo

Le soluzioni consegnate

01 — Nasa Neo

⭐ La più completa a livello di feature

nasa_neo_challenge_3

Autore: Rkomi98

Stack: NextJS · FastAPI · Echarts · Vercel

GitHub: https://github.com/Rkomi98/NASA-NEO

Live: https://nasa-neo-rose.vercel.app/

Dashboard React completa con visualizzazioni interattive dei dati NEO. Grafici temporali, filtraggio per hazard, tabelle con sorting, il tutto con un'UI super pulita che mette i dati della NASA al centro senza distrazioni.

02 — Gleamfall

⭐ Scelta coraggiosa

challenge_1

Autore: lupodevelop

Stack: Gleam · BEAM/JS target · Functional

GitHub: https://github.com/lupodevelop/gleamfall

Live: https://lupodevelop.github.io/gleamfall/

La soluzione più coraggiosa della batch. lupodevelop ha scelto Gleam, un linguaggio funzionale e type-safe che compila sia in Erlang/BEAM che in JavaScript. Un linguaggio giovane, con una community piccola ma in crescita. Performante e elegante.

Gleamfall usa il pattern di Gleam di costruire pipeline di dati immutabili: ogni asteroide è un valore, ogni trasformazione è una funzione pura. Il risultato visivo è minimalista ma il codice sottostante è un esempio didattico di come il type system di Gleam rende impossibile certi tipi di bug runtime.

03 — neo-wasm

⭐ Retro & Massima performance

Autore: SimoSbara

Stack: C99 · WebAssembly

GitHub: https://github.com/SimoSbara/neo-wasm

Live: https://simosbara.github.io/neo-wasm/

SimoSbara ha portato C nel browser. Usando C99 con WebAssembly WASI, tutta la logica computazionale, parsing del JSON, calcoli di distanza, filtraggio, gira in WASM con un wrapper JavaScript minimale. Questa è ingegneria.

Il motivo è solido: quando elabori migliaia di oggetti in real-time, il garbage collector di JavaScript è il tuo nemico. WASM ti dà memoria lineare, nessun GC, e performance vicine al nativo. Nei benchmark, neo-wasm surclassa tutte le soluzioni JS pure sulla velocità di filtraggio.

04 — Neo StarZero

⭐ Rappresentazione 3D

Autore: AdrianoG96

Stack: Python · FastAPI · Railway · Next.js · Vercel

GitHub: https://github.com/AdrianoG96/NasaNeoHub

Live: https://nasa-neo-hub.vercel.app

Si distingue per l’esperienza interattiva: tabella filtrabile, dettaglio asteroide, grafici, heatmap, radar, confronto tra oggetti ed esplorazione 3D/orbitale. Il backend FastAPI funziona da proxy con caching e aggregazione automatica dei range data, mentre il frontend Next.js punta su una UX robusta e scenografica.

05 — Neo StarZero

⭐ Feed Apocalittico

Autore: StarZero

Stack: PHP · Blade · Javascript · Vercel

GitHub: https://github.com/FabioGuin/Nasa-Neo

Live: https://neo.starzero.it/

Se bisogna tenere d'occhio i sassi cosmici tanto vale farlo con stile.

Dashboard NEO con UX originale e tono ironico. Offre filtri avanzati, ordinamenti, schede asteroide e grafici su distanza, dimensioni e livello di rischio. Backend Laravel con proxy verso NeoWs, caching con TTL configurabili e chunking automatico lato server per range oltre i 7 giorni imposti dall'API NASA. Frontend in Livewire + Blade.

06 — Neo Watch

⭐ Delphi

Autore: Klea Turhani

Stack: Delphi · Horse · Sempare · HTMX · Redis/Memurai

GitHub: https://github.com/kleaturhani28/neo-watch-webapp

Live: https://swirl-engraved-afterlife.ngrok-free.dev

Costruita in Delphi 12, perché nel 2026 nessuno se lo aspetta, e funziona benissimo.

Backend Horse (framework HTTP per Delphi) con proxy verso NeoWs, caching Redis/Memurai, chunking automatico dei range oltre i 7 giorni dell'API e rendering server-side via Sempare Templates. Il frontend non chiama mai la NASA direttamente: ogni richiesta passa dal backend Delphi, che valida l'input, gestisce la cache e restituisce dati pronti per il render. Aggiornamenti dinamici via HTMX, grafici con Chart.js.

Architettura pulita con layer espliciti (Clean Architecture + presentazione MVC-style), applicata a un monolite Delphi che fa tutto: proxy, cache, template, validazione e visualizzazione. Il punto non è solo la dashboard è la dimostrazione che Delphi nel 2026 è un runtime perfettamente capace di reggere un'applicazione web moderna, server-side rendering incluso.

07 — NASA Near Earth Objects

nasa_neo

Autore: NicolasBrazzo

Stack: Python · FastAPI · Next.js · Recharts · Railway · Vercel

GitHub: https://github.com/NicolasBrazzo/NASA-NEO-Dashboard

Live: https://nasa-neo-dashboard-brz.vercel.app/

Backend FastAPI e frontend Next.js, pensata per esplorare i dati NASA in modo chiaro e visuale. Include KPI settimanali, radar SVG custom, lista filtrabile, dettaglio asteroide e statistiche con grafici Recharts. Solida la parte architetturale: proxy backend verso NASA, API key protetta, caching con TTL, chunking dei range data, deduplica e gestione degli errori. Estetica dark/HUD molto curata e coerente con il tema spaziale.

08 — NASA Challenge

nasa_neo_challenge_6

Autore: davideblaffard

Stack: React · TypeScript · Vercel

GitHub: https://github.com/davideblaffard/nasa-challenge

Live: https://nasa-neo.vercel.app/

Dashboard con un’identità visuale molto riconoscibile, in stile terminal/HUD spaziale. L’esperienza è guidata e progressiva: onboarding iniziale, KPI chiari, grafici leggibili, filtri e dettaglio asteroide. Buona attenzione alla UX, alla resa responsive e alla leggibilità dei dati numerici, con un’interfaccia che trasforma i dati NASA in un’esperienza più immersiva e facile da esplorare.

09 — NASA NEO Dashboard

nasa_neo_challenge_5

Autore: FrancescoBellingeri

Stack: React · D3.js · Vercel

GitHub: https://github.com/FrancescoBellingeri/nasa_neo_dashboard

Live: https://nasa-neo-dashboard.vercel.app/

Presentazione visivamente ricca con emphasis sugli asteroidi potenzialmente pericolosi. Include una sezione dedicata ai close approaches con visualizzazione timeline e una mappa della distribuzione per dimensione stimata.

10 — NASA NEO Dashboard

Autore: madmiki80

Stack: Python · Streamlit · Pandas · Plotly

GitHub: https://github.com/madmiki80/AsteroidChecker

Live: https://asteroidchecker.streamlit.app/

Approccio data-science-first che mette l'analisi al centro. Streamlit permette di costruire app interattive in Python puro, distribuendole come web app. Include analisi statistiche avanzate e una sezione "what if" per esplorare scenari.

Deep Dive — Gleam: il linguaggio che nessuno si aspettava

gleam

Tecnicamente valido. Certamente coraggioso. Indiscutibilmente memorabile.

Gleam è un linguaggio funzionale fortemente tipizzato, lanciato nel 2024 nella versione 1.0, che compila sia su BEAM (la virtual machine di Erlang, usata da WhatsApp e Discord per l'alta concorrenza) sia in JavaScript. Il suo punto di forza è un type system che rende impossibile dimenticare un caso in un pattern match, se il tuo codice compila, moltissimi bug di runtime sono già esclusi strutturalmente.

Gleamfall sfrutta questo: ogni risposta dell'API NASA viene decodificata in un tipo Asteroid custom. Se la struttura del JSON cambia, il programma non crasha silenziosamente, non compila. Per un'applicazione che consuma dati esterni, questa è una garanzia non banale.

Deep Dive — C nel browser: WebAssembly contro il garbage collector

web_assembly

Quando la maggior parte degli sviluppatori sente "app web per dati NASA", pensa React. SimoSbara ha pensato in C99.

La pipeline di neo-wasm è questa: il codice C99 viene compilato in un modulo .wasm tramite WebAssembly WASI, con un piccolo wrapper JavaScript minimale. Il browser scarica il modulo WASM, lo istanzia, e da quel momento la logica computazionale gira fuori dall'heap JavaScript, nessun garbage collector, allocazione deterministica, performance prevedibili.

Il vantaggio emerge chiaramente quando il dataset cresce. Con migliaia di asteroidi da filtrare in real-time mentre l'utente interagisce, la soluzione WASM non subisce i pause del GC di V8.

È overengineering? Per questa dimensione di dati, forse. Ma è anche un proof-of-concept eccellente di un pattern che diventerà sempre più rilevante: portare logica computazionale intensiva nel browser senza sacrificare la UX. E con WASI, lo standard che permette a WASM di girare anche fuori dal browser, il codice scritto oggi è già pronto per runtime futuri.

👨🏻‍💻 Takeaway tecnici

Sul dato. La NASA NeoWs API restituisce fino a 7 giorni di dati per chiamata. Ogni oggetto ha 20+ campi, incluse stime della dimensione in più unità, velocità relative alla Terra e al Sole, e coordinate orbitali. Gestire questa struttura nested in modo robusto è già di per sé un test di qualità del codice. La soluzione più elegante per il data modeling è stata, ironia della sorte, quella in Gleam: i tipi custom rendono esplicito quale sottoinsieme del JSON viene effettivamente usato.

Sul deployment. Le soluzioni statiche (Gleamfall, neo-wasm) hanno un vantaggio strutturale: nessun cold start, nessuna dipendenza da un server, costi zero. Il trade-off è che la logica server-side è impossibile, ma per questo caso d'uso, non serve. AsteroidChecker su Streamlit paga il prezzo del cold start ma guadagna in flessibilità computazionale: Pandas e NumPy per l'analisi dati sono molto più potenti di quello che si può fare in JavaScript.

Su WebAssembly. neo-wasm è il caso studio più interessante per chi vuole capire quando WASM ha senso. La risposta breve: quando hai logica computazionale intensiva che non può aspettare il GC di JavaScript. Per interfacce semplici, il costo di setup di Emscripten non si ripaga. Per pipeline di dati ad alta frequenza, la differenza è misurabile.

🏆 Il verdetto

Non c'è una soluzione "migliore" in senso assoluto. C'è la soluzione più coraggiosa (Gleamfall), la più performante (neo-wasm), la più analiticamente ricca (AsteroidChecker), e tre dashboard React che dimostrano quanto la stessa base tecnica possa portare a prodotti molto diversi a seconda delle scelte di UX e visualizzazione.

Quello che colpisce è la varietà di approcci su un brief identico 🚀

Questa è la cosa più sana che una community tech possa fare: non convergere sulla soluzione "ovvia", ma esplorare lo spazio di possibilità. Anche quando quello spazio include linguaggi che quasi nessuno usa, o compilatori C++ per il browser.

"Il coraggio tecnico non è scegliere lo stack più difficile. È scegliere quello che ritieni sia più giusto per il problema, anche quando è scomodo."

Ringraziamo tutti i partecipanti 💚

Avete preso dati di asteroidi e li avete trasformati in software.