Sei applicazioni, un backend, nessuna logica duplicata
Euroingro è un marketplace all'ingrosso con più tipi di utente: chi compra, chi fornisce, chi amministra. Ognuno ha bisogno di uno strumento diverso, ma i prezzi, le disponibilità e i permessi devono essere gli stessi ovunque.
Risultati misurati
40
moduli nel backend, da carrello a magazzino
17
lingue tradotte, dall'italiano al cinese
6
applicazioni: web, console e mobile
9
repository coordinati nello stesso ecosistema
01 — Contesto
Una piattaforma che cresceva per aggiunte
Il primo storefront era un'applicazione Angular Universal con Ionic e Capacitor: un solo pacchetto che doveva servire web e mobile, e che a ogni funzione nuova diventava più difficile da rilasciare.
Nel frattempo erano nate esigenze diverse fra loro: i fornitori avevano bisogno di una console per i propri cataloghi, l'amministrazione di strumenti di controllo, il team tecnico di vedere in un punto solo lo stato dei servizi.
02 — Approccio
Prima il contratto, poi le interfacce
La scelta di fondo è stata separare il backend dalle facce: il monolite Django espone `api/v2`, documentata, e ogni interfaccia diventa un repository per conto suo che consuma quel contratto senza conoscerne l'interno.
Così il negozio è stato riscritto in Next.js con rendering sul server — meglio per chi arriva da una ricerca — mentre le console sono React con Vite, veloci da costruire, e le due app sono in Flutter. Nessuna riscrive le regole di prezzo: le chiede.
03 — Soluzione
Le applicazioni della piattaforma
Storefront
Il negozio in Next.js App Router con rendering sul server: home, catalogo, scheda prodotto e pagine azienda.
Console fornitori e acquirenti
Gestione cataloghi, candidatura pubblica per nuovi fornitori e pannello acquirente, in React e Vite.
Superadmin e stato dei servizi
Due console interne: amministrazione avanzata e inventario delle API con lo stato dei siti in tempo reale.
App mobile
Due applicazioni Flutter — redazione dei contenuti e vetrina — costruite sullo stesso contratto API.
04 — Dentro il codice
Quarantamila righe di regole, divise per mestiere
Il backend non è un negozio con qualche aggiunta: sono quasi quattromila file, in maggioranza Python, divisi in una quarantina di moduli che hanno ognuno un mestiere. Carrello, ordini, spedizioni e fatturazione stanno accanto a cose che di solito si comprano da fuori — un motore di raccomandazioni, gli indici di ricerca sui prodotti, un forum, una chat fra utenti, le notifiche push, la newsletter.
Le traduzioni sono diciassette: oltre all'italiano e all'inglese ci sono tedesco, spagnolo, francese, olandese, portoghese, russo, svedese, norvegese, finlandese, greco, turco, irlandese e cinese semplificato. Per un ingrosso che vende all'estero non è un vezzo: è il motivo per cui un rivenditore straniero riesce a ordinare da solo.
Delle API convivono tre versioni — v2, v3 e v4 — e non è disordine: è come si cambia un contratto senza rompere chi lo sta usando. Le applicazioni nuove nascono sull'ultima, quelle esistenti migrano quando possono, e nel frattempo nessuno resta fermo.
05 — Risultato
Cosa cambia con questa separazione
Ogni interfaccia si rilascia per conto suo: correggere il negozio non tocca le console, e una console nuova nasce senza rimettere le mani nel backend. Il contratto API è il punto in cui si concordano le modifiche, ed è l'unico posto dove le regole di prezzo e i permessi vivono davvero.
