Un travel planner con AI che trasforma una destinazione e qualche preferenza in un itinerario giorno per giorno, con dati di volo reali alle spalle.
Atlas è una piattaforma full-stack per pianificare viaggi che ho progettato e costruito dall'inizio alla fine. Scegli una destinazione, imposti date e preferenze e Atlas genera un itinerario completo con l'AI, poi ci sovrappone dati di volo reali perché il piano sia qualcosa che puoi davvero prenotare.
Ho seguito tutto il prodotto: il front-end React, la REST API in Java Spring Boot, il database PostgreSQL su Supabase, l'autenticazione con JWT e Google OAuth e la pipeline AI. È nato come un modo per capire fin dove potessi spingere gli LLM dentro un'applicazione vera, ed è diventato il progetto in cui ho imparato di più sulla performance.
Pianificare un viaggio è frammentato: i voli su un sito, le idee sparse tra blog e mappe, e nessun posto che trasformi un'idea vaga in un piano concreto. L'obiettivo era costruire quel posto. La parte difficile è stata rendere la generazione AI abbastanza veloce da sembrare una funzionalità di prodotto e non una demo.
Il primo stack AI impiegava oltre cinque minuti per generare un singolo itinerario
I dati di volo dovevano essere reali, tramite l'API Amadeus, con il suo flusso di autenticazione e i suoi rate limit
L'accesso doveva funzionare sia con email e password sia con Google OAuth, su un progetto portato avanti da sola e senza budget
Ho mappato il percorso prima di scrivere codice: accesso, scelta della destinazione, regolazione delle preferenze, generazione, rifinitura. Ogni schermata risponde a una domanda sola, così il passaggio AI non sembra mai una scatola nera.
Il back-end Spring Boot espone una REST API per utenti, viaggi e itinerari, con PostgreSQL su Supabase. Le ricerche voli tramite Amadeus vivono in un servizio a parte, isolate dalle chiamate AI, così ogni integrazione può cambiare senza toccare l'altra.
La prima versione girava in Python con Ollama e un modello Mistral locale. Funzionava, ma un itinerario richiedeva più di cinque minuti. Ho spostato l'inferenza su Groq e OpenAI e ho rivisto i prompt di conseguenza, portando il tempo di risposta a pochi secondi.
Perché
L'inferenza locale era gratuita ma troppo lenta per un flusso interattivo. I modelli ospitati hanno reso la generazione quasi istantanea e mi hanno permesso di scegliere il modello giusto per ogni passaggio.
Compromesso
Ora l'app dipende da provider esterni e paga a richiesta.
Perché
Email e password con JWT mantengono la API stateless, mentre Google OAuth toglie attrito a chi vuole solo provare l'app.
Compromesso
Due strade di accesso significano il doppio dei casi limite da gestire e testare.
Perché
Un itinerario è utile solo se puoi agirci. I dati di volo in tempo reale rendono il piano prenotabile invece che un elenco di ipotesi.
Compromesso
Un'integrazione in più da mantenere, con rate limit e un'autenticazione propria.
5 min → secondi
Generazione AI dell'itinerario, prima e dopo il passaggio a Groq e OpenAI
2
Metodi di accesso: email e password con JWT, e Google OAuth
Reali
Dati di volo dall'API Amadeus dentro ogni piano
La performance è una funzionalità di prodotto. Un'attesa di cinque minuti faceva sembrare l'AI rotta anche quando il risultato era buono; pochi secondi hanno reso lo stesso risultato immediato.
Tenere ogni servizio di terze parti dietro il proprio livello ha ripagato nel momento in cui ho cambiato provider AI. La prossima volta definirei la forma dei dati dell'itinerario prima di scrivere il primo prompt, così front-end e modello vanno d'accordo dal primo giorno.
