Come mantenere le applicazioni senza stato

Questa potrebbe essere una domanda contorta, ma sto cercando di capire meglio l'apolidia.

Sulla base di ciò che ho letto, le applicazioni Web dovrebbero essere apolidi, il che significa che ogni richiesta viene trattata come una transazione indipendente. Di conseguenza, Sessione e Cookie dovrebbero essere evitati (poiché entrambi sono dichiarati). Un approccio migliore consiste nell'utilizzare i token, che sono apolidi perché nulla è archiviato sul server.

Quindi sto cercando di capire, come possono le applicazioni web essere apolidi quando ci sono dati che vengono conservati per la mia sessione (come gli articoli in un carrello)? Questi vengono effettivamente archiviati in un database da qualche parte e quindi periodicamente eliminati? Come funziona quando si utilizza un token anziché i cookie?

E poi come domanda correlata, i principali siti Web (Amazon, Google, Facebook, Twitter, ecc.) Sono effettivamente apolidi? Usano token o cookie (o entrambi)?

"Le applicazioni Web dovrebbero essere apolidi" dovrebbe essere inteso come "le applicazioni Web dovrebbero essere apolidi a meno che non ci siano ottime ragioni per avere uno stato" . Un "carrello della spesa" è una caratteristica stateful di progettazione e negare che è abbastanza controproducente. Il punto centrale del modello del carrello è preservare lo stato dell'applicazione tra le richieste.

Un'alternativa che potrei immaginare come un sito Web senza stato che implementa un carrello sarebbe un'applicazione a pagina singola che mantiene il carrello completamente lato client, recupera le informazioni sul prodotto con le chiamate AJAX e quindi le invia al server tutte in una volta quando l'utente fa un checkout. Ma dubito di aver mai visto qualcuno farlo davvero, perché non consente all'utente di utilizzare più schede del browser e non mantiene lo stato quando chiude accidentalmente la scheda. Certo, ci sono soluzioni alternative come usare localstorage, ma poi hai di nuovo lo stato, solo sul client anziché sul server.

Ogni volta che si dispone di un'applicazione Web che richiede di conservare i dati tra le visualizzazioni di pagina, di solito lo si fa introducendo sessioni. La sessione a cui appartiene una richiesta può essere identificata da un cookie o da un parametro URL aggiunto a ciascun collegamento. I cookie dovrebbero essere preferiti perché mantengono gli URL più a portata di mano e impediscono all'utente di condividere accidentalmente un URL con il proprio ID di sessione al suo interno. Ma avere token URL come fallback è vitale anche per gli utenti che disattivano i cookie. La maggior parte dei framework di sviluppo web ha un sistema di gestione delle sessioni che può fare questo immediatamente.

Sul lato server, le informazioni sulla sessione vengono generalmente archiviate in un database. La memorizzazione nella memoria cache lato server è facoltativa. Può migliorare notevolmente i tempi di risposta, ma non consente di trasferire sessioni tra server diversi. Quindi sarà necessario un database persistente come fallback.

i principali siti Web (Amazon, Google, Facebook, Twitter, ecc.) sono effettivamente apolidi? Usano token o cookie (o entrambi)?

Ti consentono di accedere? Quando poi chiudi la scheda e visiti nuovamente il sito, hai ancora effettuato l'accesso? In tal caso, utilizzano i cookie per preservare la tua identità tra le sessioni.

È vero che le applicazioni web dovrebbero essere apolidi. Tuttavia, variabili di sessione, cookie e token non violano questo quando sono tutti memorizzati sul client (browser web). Possono essere parametri nella richiesta.

Ecco un modello semplificato:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

Questo potrebbe funzionare per lo scambio di stack di ingegneria del software . Questa risposta che sto scrivendo fa parte dello stato del mio browser web. Finché è l'unico posto dove si trova, non è accessibile a nessuno tranne a me. Ma non appena premo il Post your Answermio browser lo invia al server web. Il web server elabora la posta senza alcuno stato. Impara chi sono dal mio browser e dal database. Una volta terminato il controllo del mio post e l'aggiunta al database, il server Web dimentica prontamente di me.

Questo è ciò che significa apolide. Il server non è responsabile per ricordare nulla di tutto ciò. Non è il suo lavoro.

In questo modo ha molti vantaggi. Se il web server presenta una perdita di memoria, è rilevabile poiché la sua impronta di memoria non dovrebbe aumentare. Se il web server si arresta in modo anomalo, la mia identità non è compatibile. Se qualcuno tenta di eseguire un attacco denial of service, non può utilizzare le risorse di stato del server Web per farlo, poiché il server Web non assegna alcuno stato tra di loro per le sessioni. Tutto ciò ha lo scopo di rendere stabile il web server. In questo modo, quando inizia a funzionare, rimane in esecuzione.

Ora certo, sto consumando risorse nel database, ma quelle risorse sono state prima verificate contro la mia indennità da qualcosa di stabile su cui possiamo contare per proteggere il database dal web selvaggio e lanoso: il web server stateless, che impone regole aziendali.

le applicazioni Web dovrebbero essere apolidi

Senza senso. Le richieste Web devono essere apolidi. O più precisamente, le richieste Web sono apolidi.

Ma dire che un'intera applicazione dovrebbe essere apolide è una totale assurdità.

ogni richiesta viene trattata come una transazione indipendente.

Sì esatto . O più precisamente, sì, necessariamente . Su HTTP, ogni richiesta è intrinsecamente indipendente da tutte le altre richieste. Per aggiungere "statefulness" a HTTP è necessario identificare, archiviare e recuperare esplicitamente "state" per ogni richiesta "stateful". E questo richiede uno sforzo, riduce le prestazioni e aggiunge complessità.

E, per questi motivi, ogni richiesta che può essere apolide "dovrebbe" essere apolide.

Di conseguenza, Sessione e Cookie dovrebbero essere evitati (poiché entrambi sono dichiarati). Un approccio migliore consiste nell'utilizzare i token

Alcune cose: i token possono essere collegati anche all'archiviazione delle sessioni. I cookie non devono essere associati all'archiviazione della sessione. I token sono spesso memorizzati nei cookie. E a volte una sessione è semplicemente lo strumento giusto per il lavoro.

Ciò significa che almeno a volte , sessioni e cookie sono altrettanto "migliori" dei token!

[Token] sono apolidi perché nulla è archiviato sul server.

Bene, tutto qui. Questo è il dogma dell '"apolidia". Tuttavia, per essere chiari, non si tratta di archiviare "nulla" sul server, ma di non memorizzare lo stato della sessione sul server.

La mia posta in arrivo di Gmail è in uno stato, ad esempio. E dannatamente meglio che sia archiviato sul server! Ma non è lo stato della sessione .

Quindi, invece di avere un server in grado di prendere un piccolo identificatore e capire chi sei e così via, le applicazioni senza stato vogliono essere ricordate chi sei e cosa stai facendo con ogni sanguinosa richiesta. Lo stato dell'applicazione esiste ancora, il client è solo responsabile del mantenimento.

Ora, se quello stato è piccolo, probabilmente va bene. In alcuni casi è molto buono.

E poi, naturalmente, ci sono cose che ci aspettiamo semplicemente che siano stateful ...

come possono le applicazioni web essere apolidi quando ci sono dati che vengono conservati per la mia sessione (come articoli in un carrello)? Questi vengono effettivamente archiviati in un database da qualche parte e quindi periodicamente eliminati?

Due opzioni. O hai una sessione o stai negando!

... Ma sul serio. Normalmente non immagazzineresti un carrello in un cookie. Qualcosa come un carrello della spesa verrà archiviato in una sessione "tradizionale" o verrà archiviato come Cartoggetto, con un tipo di ID che il server utilizza per estrarlo nelle richieste successive. Un po 'come una ... uhh ... ... err ... sessione.

Davvero sul serio: c'è un grande grado in cui la "statualità" è proprio ciò che chiamiamo quando due agenti comunicanti possono contestualizzare i messaggi in una conversazione. E una sessione, tradizionalmente compresa, è proprio quello che in genere chiamiamo il meccanismo con cui ciò avviene.

Direi che, indipendentemente dal fatto che tu usi token o "sessioni", per ogni richiesta gestita dal tuo server, o devi contestualizzare quella richiesta per soddisfarla, oppure no. Se il contesto non è necessario, non recuperarlo. Se il contesto è necessario, è meglio averlo vicino!

E poi come domanda correlata, i principali siti Web (Amazon, Google, Facebook, Twitter, ecc.) Sono effettivamente apolidi? Usano token o cookie (o entrambi)?

Probabilmente entrambi. Ma, in generale, fanno esattamente quello che fai: impostano i cookie per identificare i record di "stato" in enormi database di "sessione".

Quando possibile, sospetto che inseriscano le rivendicazioni di identità di base in "token" di breve durata per evitare contese inutili sullo storage centralizzato. Ma il fatto che molti di questi servizi mi permettano di "disconnettermi da tutte le altre posizioni" è un buon indicatore del fatto che, se usano dei token, sono almeno "supportati" da un modello di sessione semi-tradizionale .

La condizione di stato non è necessariamente una cosa negativa, ma è necessario comprendere la differenza tra app con stato e senza stato. In breve, le app con stato mantengono le informazioni sulla sessione corrente e le app senza stato no. Le informazioni memorizzate in modo permanente come parte di un account utente possono o meno essere archiviate in una sessione, ma la memorizzazione di informazioni relative a un account utente non rende di per sé l'applicazione stateful. La condizione di stato richiede che il server mantenga le informazioni sulla sessione dell'utente corrente oltre a ciò che sta gestendo il browser client. Ad esempio, un client potrebbe autenticare e ricevere un cookie JSESSIONID, che quindi invia al server con ogni richiesta. Se il server inizia a memorizzare elementi nell'ambito della sessione dell'applicazione in base a questo JSESSIONID, diventa stateful.

apolidia

Per apolide, intendiamo che il server e il client non mantengono le informazioni correnti sulla sessione dell'utente. Il client e il server possono utilizzare una qualche forma di token per fornire l'autenticazione tra le richieste, ma non vengono memorizzate altre informazioni correnti. Un tipico caso d'uso di tale soluzione potrebbe essere un sito di notizie in cui la maggior parte degli utenti (nuovi consumatori) consuma informazioni ma non produce informazioni che risalgono al sito. In tali casi, il sito non deve conservare alcuna informazione sulla sessione dell'utente corrente. Si noti che il sito può ancora utilizzare i cookie per identificare l'utente e archiviare informazioni sull'uso del sito da parte di tale utente, ma ciò può comunque essere considerato apolide poiché tutto ciò che è stato registrato potrebbe essere transazionale, ad esempio il collegamento su cui l'utente ha fatto clic, che potrebbe essere registrato da il server, ma non gestito in una sessione utente.

Statefulness sul server

Sul server, un'app stateful salva le informazioni sullo stato degli utenti attuali. Questo approccio prevede generalmente l'uso di cookie per identificare il sistema dell'utente in modo che lo stato possa essere mantenuto sul server tra le richieste. Le sessioni possono essere autenticate o meno, a seconda del contesto dell'applicazione. Le app server con stato offrono il vantaggio di memorizzare nella cache le informazioni sullo stato degli utenti sul server, accelerando le ricerche e i tempi di risposta della pagina. Sul lato negativo, la memorizzazione delle informazioni nell'ambito della sessione è costosa e su vasta scala diventa molto dispendiosa in termini di risorse. Inoltre, crea un potenziale vettore di attacco per gli hacker per provare a dirottare identificatori di sessione e rubare sessioni utente. Le app server con stato hanno anche la sfida di proteggere le sessioni utente da interruzioni impreviste del servizio, ad esempio un errore del server.

Statefulness sul client

Utilizzando JavaScript e le moderne tecnologie del browser come sessionStorage, l'applicazione ora può facilmente memorizzare informazioni sullo stato di una sessione utente sul dispositivo dell'utente. Nel complesso, l'applicazione può ancora essere considerata con stato, ma il compito di mantenere lo stato è stato spostato sul client. Questo approccio ha un grande vantaggio (per il manutentore dell'app Web) rispetto al mantenimento dello stato sul server in quanto ciascun utente, in effetti, mantiene il proprio stato e non vi sono oneri per l'infrastruttura del server. Su scala web, questo tipo di scelta architettonica ha enormi ripercussioni sui costi di hardware ed elettricità. Potrebbe letteralmente costare milioni di dollari all'anno per mantenere lo stato sul server. Passare a un sistema che mantiene lo stato sul client potrebbe quindi risparmiare milioni di dollari all'anno.

Token v. Cookies

I cookie fungono da identificatori per dispositivi / browser client. Possono essere utilizzati per archiviare ogni genere di cose, ma generalmente memorizzano una qualche forma di identificatore, come CFID / CFTOKEN nelle app CFML. I cookie possono essere impostati per vivere a lungo nel browser dell'utente, rendendo possibile fare cose come mantenere l'autenticazione su un'app tra le sessioni del browser. I cookie possono anche essere impostati solo in memoria in modo che scadano quando un utente chiude il browser.

I token sono generalmente un tipo di informazioni identificative sull'utente che vengono generate sul server (usando la crittografia per mescolare le informazioni), passate al client e restituite al server con la richiesta successiva. Possono essere passati nell'intestazione della richiesta e della risposta, che è un modello comune nelle applicazioni a pagina singola. Idealmente, ogni richiesta / risposta comporta la generazione di un nuovo token, quindi i token non possono essere intercettati e utilizzati in seguito da un attaccante.

App a pagina singola e stato del client

Con le SPA, le informazioni sullo stato vengono caricate nel browser client e mantenute lì. Quando lo stato cambia, ad esempio quando pubblichi un aggiornamento sul tuo account di social media, il client inoltra la nuova transazione al server. In questo caso, il server salva quell'aggiornamento in un archivio dati persistente come un database e inoltra al client qualsiasi informazione che deve sincronizzare con il server in base all'aggiornamento (ad esempio un ID per l'aggiornamento).

Si noti che questo modello di memorizzazione dello stato sul client offre vantaggi per le esperienze online / offline in quanto è possibile disconnettersi dal server pur avendo ancora un'applicazione utilizzabile. Twitter è un buon esempio di questo caso, in cui è possibile rivedere qualsiasi lato client caricato nel proprio feed Twitter anche se si è disconnessi dall'app del server Twitter. Questo modello crea anche complessità nella sincronizzazione tra server e client, che è un argomento a sé stante. Le complessità della soluzione sono un compromesso per poter mantenere lo stato sul client.

La dignità sul client rende le app Web più simili alle app desktop tradizionali. A differenza delle app desktop, in genere non tutte le informazioni dell'account verranno caricate nella sessione client in un browser. In tal caso, in molti casi sarebbe impraticabile e produrrebbe brutte esperienze. Riesci a immaginare di provare a caricare un'intera casella di Gmail nel browser? Al contrario, il client mantiene informazioni come l'etichetta / cartella che stai visualizzando e dove nell'elenco di e-mail in quella cartella che stai visualizzando. Equilibrare quali informazioni sullo stato mantenere e cosa richiedere in base alle esigenze è un'altra sfida ingegneristica di questo modello e, di nuovo, rappresenta un compromesso tra praticità e fornire buone esperienze utente.

Carrelli della spesa e simili

Per quanto riguarda i dettagli come i carrelli della spesa, dipende davvero dalla soluzione. Un carrello della spesa può essere archiviato in un database sul server, può essere archiviato solo nell'ambito della sessione sul server o può anche essere archiviato nel client. Amazon ha carrelli acquisti persistenti per gli utenti che hanno effettuato l'accesso e carrelli "temporanei" per utenti anonimi, sebbene questi carrelli siano persistenti in una certa misura.

Quando parli di qualcosa come Google, che in realtà è un gruppo di applicazioni diverse che vivono con lo stesso marchio, probabilmente non condividono un'architettura comune e ognuna è costruita nel modo che soddisfa meglio le esigenze dei suoi utenti. Se vuoi sapere come viene costruito un sito, apri gli strumenti di sviluppo nel tuo browser e guardalo. Verifica la presenza di cookie, controlla il traffico di rete e guarda come funziona.

Scusate se questa risposta è un po 'sconnessa, ma lo stato è un argomento complesso.

Sessioni e cookie non devono essere evitati. Puoi ancora averli con applicazioni web senza stato.

C'è una grande differenza tra Java e Ruby on Rails. Le app Java memorizzeranno la sessione in memoria utilizzando una chiave di sessione memorizzata in un cookie. Questo è veloce per recuperare lo stato dell'utente e il carrello. Tuttavia, devi sempre colpire lo stesso server con la tua sessione.

Le app Rails memorizzano l'ID utente in un cookie crittografato e firmato. Non può essere manomesso. Quando si carica una pagina, l'app Web recupera lo stato, l'utente e il carrello da un database. Questo è più lento, ma la chiave è che puoi colpire qualsiasi istanza ! Ciò consente di riavviare, ridimensionare, arrestare le istanze a piacimento. Molto conveniente. Può anche essere reso più veloce con un database cache condiviso, in memoria come Redis. Oppure puoi conservare il carrello nel cookie, a condizione che sia abbastanza piccolo.

In questo modo puoi ottenere l'apolidia, attraverso tecniche intelligenti, e aggiungere la capacità di scalare a piacimento.

Il protocollo è senza stato.

Ma da ciò non segue necessariamente che le applicazioni che utilizzano il protocollo dovrebbero essere apolidi.

Ecco un paio di risposte StackOverflow correlate che spiegano bene la differenza:

• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34678600#34678600
• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34677668#34677668

Quando si fa riferimento a apolidi - ad esempio in un servizio HTTP RESTful - sta per evitare di memorizzare lo stato sul lato server. Nella migliore delle ipotesi, ciò include anche evitare di archiviare qualsiasi stato in un database o altri archivi persistenti sul back-end. Per chiarire, sto parlando di uno stato e non di dati in generale. Sembra che alcuni ragazzi stiano mescolando le cose.

Una comunicazione senza stato presenta numerosi vantaggi, in particolare per quanto riguarda la scalabilità e la disponibilità.

Un approccio migliore consiste nell'utilizzare i token, che sono apolidi perché nulla è archiviato sul server.

Questo è vero (per alcuni protocolli di autenticazione e autorizzazione). I token possono (ma non di per sé) fornire tutte le informazioni all'interno della richiesta necessarie per autenticare un utente o autorizzare un'azione. Per un esempio, dai un'occhiata a JWT .

Quindi sto cercando di capire, come possono le applicazioni web essere apolidi quando ci sono dati che vengono conservati per la mia sessione (come gli articoli in un carrello)? Questi vengono effettivamente archiviati in un database da qualche parte e quindi periodicamente eliminati? Come funziona quando si utilizza un token anziché i cookie?

Per quanto riguarda l'esempio del carrello. Non è un problema archiviare tutti gli articoli del carrello sul lato client senza utilizzare una sessione o cookie. Puoi trovare un esempio su smashingmagazine.com . Ma è anche possibile realizzare un carrello senza stato con i cookie (almeno se il tuo assortimento non è così grande e lo spazio di archiviazione di 4kb è sufficiente per te).

Non fraintendetemi, ciò non significa che dovreste implementare un carrello senza stato a qualsiasi prezzo. Amazon o altre grandi piattaforme di shopping online utilizzano implementazioni con carrello dello shopping stateful perché l'esperienza dell'utente e l'usabilità sono più importanti per loro che soddisfare requisiti tecnici non funzionali come la scalabilità.

In genere, i token non vengono utilizzati per memorizzare informazioni come gli articoli del carrello. Sono utilizzati per un'autenticazione e un'autorizzazione senza stato.

E poi come domanda correlata, i principali siti Web (Amazon, Google, Facebook, Twitter, ecc.) Sono effettivamente apolidi? Usano token o cookie (o entrambi)?

Se stai chiedendo se utilizzano i cookie o i token per l'autenticazione, la risposta è che usano entrambi. Per gli utenti vengono utilizzati principalmente cookie per clienti tecnici principalmente token.

OK, la regola che citi non è tecnicamente corretta. Tutti i livelli di un'applicazione Web hanno stato.

L'intento della regola è "non reggere il lato server per sessione".

Cioè, variabili di sessione in ASP , che erano comunemente usate per fare cose come articoli nel carrello / nome utente, ecc.

Il motivo è che la memoria del server si esaurirà man mano che l'applicazione acquisirà più utenti. Lo spostamento dell'archiviazione in un database o cache condivisa non risolve il problema poiché hai ancora un collo di bottiglia.

Per mantenere lo stato dell'applicazione per utente senza colpire questo problema, spostare lo stato sul lato client. Ad esempio, inserisci gli articoli del carrello in un cookie o in un archivio client più avanzato.

Poiché il numero di client si ridimensiona con il numero di utenti, l'applicazione nel suo insieme non avrà un collo di bottiglia e si ridimensionerà bene.