
FastFood
FastFood è una piattaforma completa per ordinare cibo, costruita attorno a due esperienze collegate. Un'app web per il cliente permette di scoprire i ristoranti vicini, sfogliare i menu con dettagli e allergeni dei piatti, comporre un ordine in un carrello vivo e concludere scegliendo il metodo di pagamento, e poi di seguire l'ordine lungo tutto il suo percorso, in tempo reale. Una console di gestione permette al ristoratore di curare il menu, far avanzare gli ordini in arrivo lungo la loro filiera di stati e seguire l'andamento su un cruscotto di analisi. LilyByte ha progettato e costruito l'intero prodotto da capo a fondo (frontend Next.js, API Express/MongoDB) come progetto proprio.
I due ruoli sono mossi da un sistema solo: un unico modello di account con un interruttore cliente/ristorante, un ordine solo che entrambe le parti vedono e su cui possono agire, e un motore di scoperta consapevole della posizione che lega i menu a una mappa.
La sfida
Un mercato per ordinare cibo è in realtà due prodotti che devono darsi ragione a vicenda. Costruirli bene entrambi, insieme, era la sfida centrale.
Due pubblici, un solo modello dati. Il cliente vuole velocità: trovare qualcosa di buono lì vicino e ordinarlo in pochi tocchi. Il ristorante vuole controllo e visione: gestire il menu, lavorare gli ordini in arrivo, capire come va. Entrambi sono mossi dagli stessi ristoranti, menu e ordini.
Scoperta consapevole della posizione. La scoperta funziona solo se rispetta dove sei e cosa ti piace: interrogazioni geospaziali vere per i ristoranti vicini a un indirizzo, insieme alle preferenze di cucina e ai vincoli sugli allergeni.
Un ciclo dell'ordine condiviso e dal vivo. Un ordine attraversa gli stati ordinato, in preparazione, pronto o in consegna, e completato. Lo stesso dato alimenta la finestra di tracciamento del cliente e la bacheca operativa del ristorante, quindi lo stato deve restare coerente su entrambi i lati.
Un imbuto d'ordine completo. Dal piatto sfogliato alla sua scheda, poi al carrello vivo, poi alla conferma con dettagli e metodo di pagamento: tutto il percorso doveva sembrare una vera app per ordinare, non un modulo da riempire.
Visione operativa. Al ristoratore servivano analisi vere (andamento di incassi e ordini, piatti che vendono di più e di meno, confronti fra periodi) presentate con chiarezza.
La soluzione
FastFood unisce un frontend Next.js moderno a un backend geospaziale Express/MongoDB, tenuti insieme da uno strato di autenticazione consapevole dei ruoli.
001
Un frontend Next.js consapevole dei ruoli
Il client è costruito su Next.js 15 (App Router, Turbopack) con il sistema di componenti HeroUI e Tailwind CSS. I gruppi di rotte separano l'app del cliente dalla console del ristorante, e una guardia di autenticazione porta ogni utente sulla superficie giusta. Chart.js muove le analisi, e lo stato di carrello e ordine è tenuto con il context di React, così il flusso sopravvive a tutto il percorso di acquisto.
002
Un'API geospaziale per gli ordini
Il backend è un'API REST Express 5 su MongoDB via Mongoose, protetta con JWT (bcrypt), validata con Joi, documentata con Swagger, e con le immagini dei menu gestite da Multer. La scoperta si appoggia agli indici 2dsphere di MongoDB e a pipeline $geoNear che ordinano i ristoranti per distanza e filtrano i piatti per cucina e allergeni; Nominatim di OpenStreetMap geocodifica gli indirizzi e OSRM stima i tempi di consegna.
003
Un ciclo dell'ordine, due viste
Una sola collezione di ordini è la spina dorsale dell'app: alimenta la finestra di stato dal vivo del cliente, la bacheca di gestione del ristorante e le aggregazioni del cruscotto per incassi, numero di ordini, andamento delle vendite e popolarità dei prodotti.
Funzioni chiave
Autenticazione e ruoli
Un'unica registrazione con un interruttore Utente/Ristorante porta ogni persona sull'esperienza giusta; le sessioni usano JWT.
Scoperta e ricerca
La home è personalizzata per gusto e posizione; una pagina di ricerca dedicata aggiunge un carosello di categorie, preferenze di cucina, esclusione degli allergeni e un filtro «aperto ora» sopra l'ordinamento geospaziale.
Il percorso d'ordine
Il cuore dell'app cliente è un imbuto d'ordine completo. Dalla pagina di un ristorante, un piatto apre una scheda con foto, etichette, allergeni e ingredienti; aggiungendo piatti si riempie un carrello vivo con quantità e totale corrente; e la conferma raccoglie i dettagli dell'ordine e il metodo di pagamento prima dell'invio.
Tracciamento dell'ordine
Il cliente segue ogni ordine lungo il suo percorso in una finestra di stato in tempo reale (da «In attesa di conferma» a «In preparazione», «Pronto per il ritiro» e «Completato») con l'ordine dettagliato e l'avanzamento. Il ristorante fa avanzare lo stesso ordine dalla sua console.
Area cliente
Il cliente gestisce profilo, indirizzi di consegna e carte salvate da un'area dedicata.
Console ristorante: cruscotto di analisi
Il cruscotto del gestore trasforma il flusso degli ordini in visione: schede di indicatori per ordini e incassi (oggi, settimana, mese, con scarti sul periodo precedente e scontrino medio), un grafico configurabile dell'andamento delle vendite, una tabella dei piatti più e meno venduti e un flusso dal vivo degli ordini recenti.
Console ristorante: menu e ordini
Il ristoratore cura il catalogo con la gestione completa dei piatti (aggiungendone uno nuovo o scegliendone uno esistente) e lavora gli ordini in arrivo su una bacheca ricercabile e paginata, facendo avanzare lo stato di ciascuno da una finestra.
Tecnologie
001
Frontend
- Next.js 15: App Router with Turbopack; role-based route groups and an auth guard
- React 18 + TypeScript
- HeroUI component system + Tailwind CSS for a consistent, responsive design
- Chart.js analytics · Framer Motion · react-beautiful-dnd · Axios · js-cookie
- React context for cart & auth state that persists across the ordering flow
002
Backend e API
- Node.js with Express 5: REST API
- MongoDB with Mongoose ODM
- JWT authentication with bcrypt-hashed credentials; role-based access
- Joi validation · Multer image uploads · Swagger (OpenAPI) docs
003
Geospaziale e dati
- MongoDB 2dsphere indexes and $geoNear aggregation for “near me” discovery
- Preference- and allergen-aware feeds and search via aggregation pipelines
- OpenStreetMap Nominatim geocoding + OSRM routing for delivery-time estimates
- Server-side analytics aggregations for revenue, orders and product trends
Aree di lavoro
Il lavoro ha coperto l'intero ciclo di vita del prodotto, su questi fronti:
001
Design di prodotto — flussi e interfaccia per due ruoli sotto un solo sistema di design.
002
Sviluppo frontend — client Next.js, percorso d'ordine con stato e visualizzazione dei dati.
003
Backend e API — servizi REST in Express, validazione e documentazione.
004
Dati e geospaziale — schema MongoDB, indici 2dsphere e aggregazioni.
005
Auth e sicurezza — sessioni JWT, hashing delle password e instradamento per ruolo.
006
DevOps e rilascio — piano di messa in produzione (qui sotto).
Produzione e scala (previste)
FastFood è un prototipo completo di funzioni che non è ancora stato pubblicato. Qui sotto la strada prevista verso la produzione e gli obiettivi che le sono stati posti.
001
Architettura di rilascio
Il frontend andrebbe su Vercel con cache al bordo e ottimizzazione delle immagini, mentre l'API Express girerebbe come servizio containerizzato (Render / Fly.io / AWS ECS) dietro un bilanciatore. I dati passerebbero su MongoDB Atlas conservando gli indici geospaziali, con backup automatici; le immagini dei menu sarebbero servite da archiviazione a oggetti (S3) tramite una CDN (CloudFront) invece che dalla cartella locale. Una pipeline GitHub Actions si occuperebbe di CI/CD, e l'impianto sarebbe strumentato con log strutturati, tracciamento degli errori (Sentry) e monitoraggio della disponibilità.
002
Irrobustimento per il traffico vero
Prima del lancio la piattaforma aggiungerebbe limitazione delle richieste e sanificazione degli input al bordo dell'API, cookie di sessione sicuri e non leggibili da JavaScript, moderazione delle immagini caricate, una conferma d'ordine idempotente appoggiata a un vero fornitore di pagamenti (Stripe) e notifiche push ed email sui cambi di stato. Una cache Redis starebbe davanti alle interrogazioni di scoperta più frequenti, e la filiera degli ordini passerebbe ai websocket per aggiornamenti davvero dal vivo su entrambi i lati.

Obiettivi attesi
Gli obiettivi della messa in produzione sono stati posti come traguardi concreti, non come risultati misurati:

~50
Ristoranti al lancio
Portare a bordo un primo gruppo di circa 50 ristoranti partner in una sola città, al lancio.
<300ms
Risposta della ricerca geospaziale
Tempo di risposta mediano sotto i 300 ms per le interrogazioni di scoperta geospaziale a carico nominale.
100s
Sessioni contemporanee per istanza
Reggere centinaia di sessioni d'ordine contemporanee su una sola istanza dell'API, prima di crescere in orizzontale.
99.9%
Disponibilità, con ripristino automatico
99,9% di disponibilità attesa, con backup automatici e ritorno indietro in un clic.
<24h
Dalla registrazione al primo ordine
Imbuto del ristoratore: dalla registrazione al primo menu pubblicato al primo ordine lavorato in meno di un giorno.
Nota: questo progetto non è stato pubblicato in produzione; l'architettura di rilascio e i numeri di questa sezione sono l'impianto previsto e gli obiettivi posti, non risultati misurati.
Prossimi lavori



