Sviluppare un e-commerce da zero con integrazione logistica: i cinque livelli e in che ordine si costruiscono

«Voglio un negozio online fatto da zero» di solito significa «voglio un negozio che faccia ciò che i template non fanno». E ciò che i template non fanno è quasi sempre lo stesso: dialogare con chi produce, con chi spedisce e con chi incassa, senza che una persona copi i dati da una schermata all'altra. Questo articolo spiega come strutturiamo quel lavoro in cinque livelli, cosa contiene ciascuno e in che ordine si costruiscono. Gli esempi vengono da eclipseando.com, un nostro negozio in produzione, e dai connettori per vettori che abbiamo pubblicato per Odoo.

I cinque livelli di un negozio

Livello 1: i dati vivono in un solo posto

Prima di disegnare una schermata bisogna decidere dove vive il catalogo. Se il cliente ha Odoo, la risposta è Odoo: prodotti, prezzi, giacenza e ordini sono lì e il sito li legge, non li copia. Se non ce l'ha, il negozio ha bisogno di un proprio database, che conviene sia piccolo e noioso. Su eclipseando.com è SQLite, in un file, con backup. Ciò che non può succedere è che il prezzo stia sul sito, e anche in un foglio di calcolo, e anche nell'ERP: dopo due mesi sono tre prezzi diversi.

Livello 2: il checkout non si fida del browser

Due regole non negoziabili. La prima: il prezzo si calcola sul server, con il catalogo in vigore, nel momento in cui si crea la sessione di pagamento. Il browser può conservare il carrello, ma non può dire quanto costa. La seconda: un ordine è pagato quando il gateway lo conferma con un webhook firmato, non quando il cliente atterra sulla pagina di ringraziamento. Con Stripe è checkout.session.completed con la firma verificata; con altri gateway ha un altro nome e la stessa logica. E se, alla ricezione del webhook, il passaggio successivo fallisce, si risponde con un errore perché il gateway riprovi, e si salva l'identificativo di sessione per non produrre due volte.

Livello 3: ogni fornitore parla come può

Qui «integrazione logistica» smette di essere una parola e diventa lavoro. Un fornitore con API e webhook (una tipografia on demand, un grande vettore) si integra nei due sensi: gli si crea l'ordine al momento dell'incasso e si ascolta il suo avviso di «spedito» per passare il tracking al cliente. Uno con API di dropshipping si integra in un senso e si interroga nell'altro: prima dell'incasso, la disponibilità reale per paese; dopo, l'ordine. E uno senza API, che ce ne sono e tanti, si integra riducendo il lavoro umano a un clic: il sistema produce esattamente l'e-mail o il CSV di cui il fornitore ha bisogno e, se i suoi pacchi partono con un vettore che manda e-mail, quelle e-mail vengono lette e trasformate in stati.

Due dettagli che si imparano solo con ordini reali. Uno: il tracking va per spedizione, non per ordine, perché un ordine con due prodotti di due fornitori sono due pacchi. Due: i tempi indicati nella documentazione del fornitore non sono quelli che rispetta; si misurano creando ordini di prova e leggendo ciò che restituisce, e sono quelli che si mostrano al cliente prima del pagamento. Quando il fornitore è un vettore e il negozio usa Odoo, tutto questo è già risolto nei connettori per vettori che pubblichiamo: etichetta, tracciamento, manifesto e reso dentro il prelievo.

Livello 4: ciò che gira da solo e ciò che si ritenta

Un negozio ha del lavoro che non può dipendere dal fatto che qualcuno se ne ricordi: svuotare la coda delle e-mail, ritentare gli ordini pagati che non sono arrivati al fornitore, leggere la casella del vettore, sincronizzare la giacenza con i marketplace. Ognuno è un'attività pianificata con un intervallo e un registro. La regola di progettazione è che nessuna chiami un servizio esterno nel percorso di una richiesta dell'utente: la pagina legge ciò che l'attività ha lasciato in cache. Così, se il fornitore va giù alle tre di notte, il negozio continua a servire pagine e gli ordini vengono ritentati quando torna.

Livello 5: il frontend, alla fine e veloce

Con i quattro livelli sottostanti risolti, il frontend è la parte più gratificante. Preferiamo siti statici generati in fase di build (Astro su eclipseando.com) serviti da nginx o Caddy: si caricano in un attimo, non hanno un database da attaccare e costano quanto un piccolo server. Le parti dinamiche (carrello, pagamento, stato dell'ordine) passano da un'API a parte. Il multilingua si fa con un URL per lingua e testi propri, non con un traduttore automatico sopra, e si verifica con test che controllano che ogni template esista in tutte le lingue. E la velocità si misura prima di pubblicare: peso della pagina, immagini nella dimensione in cui vengono mostrate, niente che blocchi il primo rendering.

L'ordine conta: dall'interno verso l'esterno

L'errore più costoso che vediamo è partire dal livello 5. Si mostra un sito bellissimo alla seconda settimana, il cliente si entusiasma e i livelli da 1 a 4 si improvvisano sotto, di fretta. Il risultato funziona fino al primo ordine con due fornitori, o fino al primo webhook perso. Noi costruiamo al contrario: prima i dati e il checkout con i loro test, poi le integrazioni con ordini di prova reali, poi le attività pianificate e il frontend alla fine, quando si sa esattamente cosa deve mostrare. Ci mette lo stesso tempo. Si rifà molto meno.

Domande frequenti

Link utili dentro FlexigoTech

Cosa facciamo in merito