Sessione HTTP o approccio al database

Vado a cercare una soluzione in cui un ID univoco viene assegnato a tutti i visitatori quando colpiscono per la prima volta il sito. Non importa se sono anonimi o autenticati. Quando gli utenti anonimi si registrano, conserva l'ID univoco.

Salva il carrello della spesa nel database. Lo storage è economico e non dovrebbe essere un problema in termini di prestazioni fare una query per il carrello di tanto in tanto.

La domanda sta assumendo che tu abbia bisogno di sessioni che nel mio mercato di clienti non sono necessarie. Mi capita di eseguire diverse centinaia di siti web eCommerce e una manciata di loro stanno diventando ad alto traffico. Non usiamo mai le sessioni poiché non sono scalabili a meno che non vengano estirpate, quindi sono solo più lente o richiedono più setup. Le sessioni utilizzano la memoria e il recupero del database dello stato della sessione è molto lento e richiede più parti mobili.

Al contrario, utilizziamo HTML5 sessionStorage per mantenere qualsiasi informazione dell'utente che è necessario estrarre ancora e ancora, ma senza la necessità di un rountrip dei cookie ogni volta per aumentare la larghezza di banda. Questo è IE8 + e tutti gli altri browser e dispositivi mobili moderni sono compatibili con questa tecnologia. MA si potrebbe semplicemente memorizzare il carrello in un cookie come fallback come questo è quello che abbiamo fatto in precedenza. Ecco un buon carrello dei biscotti: link

Quando gli utenti eseguono l'accesso o effettuano il login, utilizziamo un cookie crittografato con un timestamp cotto in.

Stiamo anche adottando ApplicationCache, ove applicabile, che ridurrà ulteriormente il traffico Web come una nota a margine poiché è possibile precaricare le risorse e persino catalogare i dati in modo che il punto di vista dell'utente sia un sito di caricamento super veloce e anche i dispositivi mobili funzioneranno offline (meno transazioni). Ovviamente devi fare attenzione ad aggiornare il manifest quando i prodotti cambiano, ecc.

Entrambi i metodi hanno vantaggi e svantaggi, ma il modo in cui lo vedo, l'archiviazione del database ha due vantaggi piuttosto grandi.

1. Reporting. Non puoi fare rapporto su carrelli abbandonati, tassi di conversione, ecc. Se i dati sono nella sessione.
2. Timeout della sessione. Sarei seccato se andassi a cenare e tornassi a trovare il mio carrello svuotato perché la sessione è scaduta. Immagino che neanche al rivenditore piacerebbe. Vogliamo spingere l'utente all'acquisto, non verso l'abbandono e l'abbandono.

Si presume che l'archiviazione di sessione e l'archiviazione del database siano esclusivi. Non lo sono. Ma iniziamo assumendo che lo sono.

Il vantaggio dell'archiviazione della sessione è triplice:

1. Non è necessario inserire esplicitamente i dati nel database. Basta semplicemente impostare una variabile di sessione e il gioco è fatto. Semplice e a basso rischio dal punto di vista funzionale.
2. Non è necessario gestire il ciclo di vita di una visita utente e di un carrello della spesa in quanto contenitori / framework lo fanno per te
3. Di solito la pulizia automatica delle vecchie sessioni di inattività è fatta per te.

Svantaggi dell'archiviazione delle sessioni:

1. Affinità di sessione, a meno che tu non indaghino sulla replica
2. Nessun failover, a meno che tu non indaghino sulla replica o sulla persistenza manuale dello stato della sessione su disco, il che può complicare.
3. Tutte le sessioni devono essere memorizzate. Questo è amplificato se usi la replica.

Vantaggi dell'archiviazione del database:

1. Non è necessario preoccuparsi dell'affinità di sessione o della replica dello stato. Puoi round-robin tutte le richieste.
2. Minore sovraccarico di memoria nell'applicazione.
3. Se l'ordine è completato, tutto finisce comunque nel database, quindi questo potrebbe rendere il completamento facile perché i dati sono già presenti.

Svantaggi dell'archiviazione del database:

1. Carrelli abbandonati: alcuni utenti anonimi hanno aggiunto un articolo al carrello e sono scomparsi. I dati restano immutati per sempre, a meno che tu non abbia un qualche tipo di processo di scadenza.
2. Devi trovare un modo per monitorare gli utenti e capire se, per una determinata richiesta, questo rappresenta una sessione di navigazione esistente o nuova. (sì, questo è probabilmente facile se usi un cookie, ma come fai a garantire che due utenti non finiscano con lo stesso id?).
3. Altro codice

Non hai menzionato quale piattaforma stai usando. Cercherò un approccio che utilizzi una sessione supportata da database in cui i dati di sessione sono disponibili solo in memoria durante la vita di un ciclo di richiesta / risposta, caricandolo dal database e salvandolo nel database. Questo mi ha servito bene in passato.

Vantaggi di una sessione supportata da database:

1. Nessuna necessità di affinità con il server.
2. Facile nella memoria del server delle app
3. I dati di sessione inutilizzati / abbandonati vengono eliminati automaticamente.
4. Il ciclo di vita della prima visita dell'utente, la visita ripetuta, la fine della sessione sono tutti pensati per te.
5. Facile da codificare

Svantaggi di una sessione supportata da database:

1. Configurazione: devi investigare sul tuo contenitore, che si tratti di PHP, Java EE (Tomcat, Jetty, JBoss, ecc.), node.js + express.js o cosa non lo supporta e fornisci la configurazione corretta.
2. Potrebbe essere necessario caricare questo test poiché si aggiungono 2 operazioni del database per richiesta.

C'è una terza possibilità, che qualcuno ha toccato prima. Puoi saltare completamente l'uso delle sessioni e utilizzare l'archiviazione lato client inserendo tutto in un cookie o in una memoria locale html.

Lascerò i pro / contro di ciò come un esercizio per te, ma ti darò un suggerimento che per l'archiviazione html5, la compatibilità del browser potrebbe essere qualcosa da rivedere attentamente.

Ho delineato i fatti per te. Spero che questo ti aiuti a prendere la decisione giusta per la tua situazione.

Consideriamo i due casi d'uso che hai menzionato

User is not logged in and adding product to cart (Anonymous user)

In questo caso, si vuole assolutamente salvare le informazioni sul carrello dell'utente in una sessione per servire bene l'utente durante la sua sessione. Se decide di accedere / creare un account, è possibile gestirlo in base al caso d'uso successivo. Se non esegue il login, non è necessario riempire il database con le informazioni di questo utente ospite poiché è stato utilizzato solo per servire l'ospite durante la sessione. Questi dati possono essere gestiti su base stateless, ad esempio, non lo stato non viene salvato da una sessione all'altra.

User is logged in and adding product to cart.

In questo caso, puoi gestirlo come sopra (siti di e-commerce della vecchia scuola) e anche aggiungere queste informazioni al database e associarle all'utente. Viene utilizzato principalmente per fornire informazioni stateful (state salvate da sessione a sessione) come "Cronologia esplorazione prodotto", "Consigli" ecc., Simile ad Amazon.com.

Cose a cui pensare:

• È necessario salvare i dati?
• In caso affermativo, quali sono i dati più importanti da salvare per servire meglio l'utente?
• Scalabilità + archiviazione dei dati - Come salverete le informazioni sul carrello per una rapida ricerca nel vostro database per supportare molti utenti?

Vai alla sessione quando l'utente non ha effettuato l'accesso. Anche se connesso, crea prima il carrello nella sessione e lo mantieni nel database solo quando l'utente si disconnette o la sessione scade.

È necessario mantenere un controllo sul numero di carrelli creati durante la sessione.