AURA&CO: Progettazione di uno Storefront Fashion Multi-Regione su Medusa

Piattaforma

Medusa 2.18

Storefront

Next.js 15 · React 19

Data layer

PostgreSQL · Redis · Meilisearch

Regioni

India (₹) e Stati Uniti ($)

Sito online

Storefront AURA&CO

Medusa fornisce i primitivi commerce — prodotti, varianti, carrelli, ordini, inventario, pagamenti, regioni — come moduli dietro un'API, e si ferma volutamente lì. Non include tutto ciò che un retailer moda considera il negozio: mega menu a tre livelli, attributi filtrabili per capi, guide alle taglie, sezioni editoriali in home page, verifica stock in negozio, recensioni. AURA&CO è il nostro riferimento per colmare proprio questa lacuna: un catalogo moda, casa e bambini a cinque reparti su due regioni, dove ogni funzione retail è un modulo scritto da noi, non un plugin da sperare che continui a funzionare.

Perché scegliere Medusa per un retailer con catalogo ampio

La logica di Medusa è la proprietà senza partire da zero. Una piattaforma SaaS offre un checkout intoccabile e un modello dati a cui adattare il proprio catalogo. Un framework offre tutto da costruire. Medusa sta nel mezzo: il core commerce è reale, testato e la manutenzione resta a terzi, mentre ogni esigenza di dominio diventa un modulo — con tabelle, migrazioni e servizio propri — che il sistema tratta come parte integrante.

Questa distinzione è l'architettura di tutto il progetto. Sette moduli personalizzati coprono le esigenze tipiche di un retailer moda di media dimensione, senza dover mai modificare o patchare Medusa.

Backend: sette moduli che gestiscono le funzioni retail

Catalogo: attributi, faccette e guide alle taglie

I prodotti moda hanno attributi su cui Medusa non si esprime — vestibilità, scollo, lunghezza manica, lunghezza capo, materiale, fantasia, occasione, sostenibilità. Li abbiamo modellati con un sistema attributi simile all'EAV di Magento: una definizione con codice tecnico, tipo di input e valori, collegata ai prodotti e alle categorie.

Centralizzarli serve a gestire tre aree distinte con una sola definizione. Un flag decide se un attributo appare in un accordion sulla pagina prodotto (e quale — descrizione, materiali o dettagli), un secondo se compare come faccetta nelle pagine categoria, un terzo se entra nell'indice di ricerca. Aggiungendo "Scollo" una sola volta, compare in tutti e tre i punti, senza duplicazioni o incoerenze.

• Faccette per categoria — i filtri su Abiti non sono quelli su Biancheria, perché gli attributi sono legati alle categorie e non applicati globalmente
• Guide alle taglie — tabelle di misure come righe, collegate per categoria, visibili dalla pagina prodotto
• Override per prodotto — valori attributo liberi nei casi in cui un elenco fisso non basta

Contenuti e navigazione: le aree gestite dai merchandiser

Esistono due moduli per consentire a chi gestisce il negozio di non dover mai coinvolgere uno sviluppatore per una modifica stagionale. Il modulo contenuti modella una pagina come un elenco ordinato di sezioni tipizzate — barra annunci, slider principale, teaser promozionale, teaser di categoria, carosello prodotti, griglia banner, tile di categoria, testo descrittivo, strip USP, newsletter. Ogni sezione include una configurazione JSON, una finestra di pubblicazione opzionale e un eventuale vincolo geografico, così ad esempio un banner per il Diwali può essere preparato in anticipo, limitato alla regione India, e apparirà o verrà rimosso automaticamente.

Le configurazioni delle sezioni sono in JSON e non in colonne perché dieci tipi di sezione condividono pochissimi campi. Il compromesso — nessuna validazione a livello di schema — viene gestito su entrambi i lati: un form tipizzato per ogni tipo di sezione nell’area amministrativa, un renderer tipizzato per ogni tipo di sezione nello storefront.

Il modulo navigazione gestisce il mega menu come un albero a tre livelli: reparto principale, intestazione della colonna, link. I link possono puntare a una categoria o a un URL libero, ogni nodo può essere evidenziato con il colore di accento e il pannello immagine promozionale a destra di ogni menu fa parte dello stesso dato — immagine, titolo e call-to-action.

Wishlist, recensioni e disponibilità reale in negozio

I moduli restanti risolvono ciascuno un problema che sembra minore finché non si affronta l’implementazione.

• Wishlist — funziona anche per ospiti tramite un token anonimo, poi si unisce alla lista del cliente al momento dell’accesso. Senza questa fusione, tutto ciò che viene salvato prima della registrazione si perde silenziosamente proprio quando chi acquista si registra.
• Recensioni — sono associate al prodotto e non alla variante, così cinque recensioni non si disperdono su cinque taglie. Le nuove recensioni sono in attesa e arrivano nello storefront solo dopo l’approvazione di un moderatore; il badge acquirente verificato viene controllato rispetto allo storico ordini al momento dell’invio e memorizzato, così un rimborso successivo non può modificarlo.
• Store locator — ogni punto vendita è collegato a una location di stock Medusa, così la funzione “trova in negozio” legge gli stessi livelli di inventario riservati dal checkout, invece di una seconda tabella di stock che rischia di divergere.

Gli indici del database confermano quanto fa il codice: le recensioni sono indicizzate sul percorso critico dello storefront (recensioni approvate per un prodotto), sulla coda di moderazione e con un indice univoco parziale che consente una recensione per cliente per prodotto, lasciando però gli ospiti senza vincoli — perché non hanno un’identità su cui applicare restrizioni.

Storefront: struttura e routing

Lo storefront utilizza Next.js 15 con App Router, con rendering lato server di default. Ogni route è annidata sotto un segmento paese, così regione, valuta e metodi di pagamento disponibili sono determinati dall’URL invece che da un cookie che un crawler non imposterà mai — /in/ prezzi in rupie, /us/ in dollari, entrambi completamente indicizzabili.

Gli URL delle categorie sono volutamente piatti: /ladies-dresses.html, non /categories/ladies-dresses. Una route catch-all li risolve dopo le route nominate, così /cart e /account hanno comunque la precedenza. I prodotti sono presenti solo nelle categorie foglia, quindi l’elenco di un reparto aggrega tutto il suo sottoalbero — l’albero viene ricostruito dall’elenco piatto delle categorie, perché l’API popola solo le relazioni figlio di primo livello.

• Home — sezioni composte dall’amministratore, ordinate e programmate
• Elenco reparti e categorie — 36 per pagina, con facet, tile di sottocategoria e testo SEO
• Pagine prodotto — selezione variante e taglia, guida alle taglie, accordéon attributi, valutazioni e recensioni, trova in negozio, "altri hanno acquistato anche", visualizzati di recente
• Ricerca — pagina risultati completa più autocomplete nell’header
• Preferiti, negozi e pagine CMS — store locator, wishlist e contenuti editoriali
• Carrello, checkout in tre step e account — indirizzi, storico ordini, dettaglio ordine e trasferimento ordini tra account

I contenuti sono memorizzati in cache e serviti staticamente, poi invalidati tramite tag: un subscriber backend invia una notifica allo storefront quando un amministratore salva, e i tag interessati vengono eliminati. Senza questo collegamento, un merchandiser salva un banner e la pagina continua a mostrare la versione precedente — che per lui significa "la mia modifica non ha avuto effetto".

Ricerca, facet e merchandising

Elenco e ricerca utilizzano la stessa chiamata verso un indice Meilisearch. Le card vengono renderizzate direttamente dai documenti restituiti, così una pagina da 36 prodotti richiede una sola richiesta invece di una ricerca seguita da una fetch per ogni card, e i conteggi dei facet arrivano insieme ai risultati senza necessità di una seconda aggregazione. Prezzi per entrambe le valute, stock per taglia, raggruppamento per colore, etichette e valutazioni sono tutti presenti nel documento; l’ordinamento per valutazione funziona perché i prodotti senza recensioni sono indicizzati a zero e finiscono in fondo in modo naturale, senza bisogno di filtri.

La rail di raccomandazione è l’elemento a cui prestiamo più attenzione. "Altri hanno acquistato anche" viene calcolato dalla reale cronologia ordini — si cercano gli ordini che contengono il prodotto, si conta cos’altro era presente, si ordina per frequenza. Quando la cronologia è scarsa, la lista viene integrata dalla stessa categoria, e l’API indica quali articoli provengono da quale fonte, così lo storefront può etichettare la rail in modo trasparente invece di attribuire dati di acquisto che non possiede. Una rail "novità di categoria" presentata come raccomandazione è una forzatura nel titolo.

Performance: cosa offre l’architettura

Pagine renderizzate lato server, una sola richiesta di ricerca per elenco, ottimizzazione immagini al limite del framework e assenza di waterfall dati lato client producono risultati misurabili. Misurato sulla home page con Google PageSpeed Insights:

Un valore zero di Cumulative Layout Shift su una home page moda ricca di immagini non è casuale — ogni slot media ha le dimensioni riservate prima che l’immagine venga caricata. Un Total Blocking Time di 40 ms su un Android di fascia media limitato è il risultato del rendering lato server: resta pochissimo JavaScript da eseguire, perché la pagina non arriva come un guscio vuoto in attesa di hydration. Questo approccio è lo stesso che adottiamo nei progetti di ottimizzazione della velocità su ogni piattaforma.

Cosa ottiene davvero il team amministrativo

I moduli personalizzati valgono poco se per gestirli serve SQL. Ogni modulo dispone di un'interfaccia amministrativa integrata direttamente nella dashboard di Medusa, senza strumenti esterni: gestione di attributi e guide alle taglie con selezione delle faccette per categoria, builder di sezioni per comporre e programmare home page e landing page, albero di navigazione ordinabile tramite drag & drop, coda di moderazione delle recensioni e gestione dello store.

Le pagine prodotto e categoria includono widget direttamente nella pagina: valori degli attributi sul prodotto, configurazione di contenuti e faccette sulla categoria. Il lavoro si svolge dove l'utente già opera. Questo è il vero test di una soluzione composable: il team acquisti modifica lo shop senza aprire ticket, e il team tecnico non è il collo di bottiglia per un banner.

I compromessi da considerare

Composable non è gratuito. Si è responsabili dei moduli sviluppati, delle relative migrazioni e degli aggiornamenti. Redis diventa indispensabile oltre il singolo processo: cache, event bus e motore di workflow si spostano su Redis, perché le impostazioni in memoria perdono eventi quando server e worker sono separati. La ricerca richiede un secondo sistema da gestire e reindicizzare. Il ranking di co-acquisto viene calcolato in memoria su una scansione limitata degli ordini recenti: è la scelta giusta con questo volume di catalogo, ma non lo sarebbe con un volume dieci volte superiore, dove andrebbe precomputato al completamento dell’ordine.

Tutto ciò non è una critica allo stack. È il motivo per cui si deve partire con i costi operativi ben chiari, come facciamo per ogni progetto di headless commerce.

Sta valutando Medusa per il suo catalogo?

Se sta confrontando una soluzione composable con il mantenimento su SaaS, la domanda utile non riguarda la piattaforma, ma quali parti della logica commerciale sono davvero specifiche e quali sono standard. Contatti il nostro team tecnico: entro un giorno lavorativo riceverà una valutazione chiara su ambito, sequenza e costi.