Cómo mantener las aplicaciones sin estado

97

Esta puede ser una pregunta complicada, pero estoy tratando de comprender mejor la apatridia.

Según lo que he leído, las aplicaciones web no deberían tener estado, lo que significa que cada solicitud se trata como una transacción independiente. Como resultado, se deben evitar la sesión y las cookies (ya que ambas tienen estado). Un mejor enfoque es usar tokens, que no tienen estado porque no hay nada almacenado en el servidor.

Así que estoy tratando de entender, ¿cómo pueden las aplicaciones web no tener estado cuando hay datos que se guardan para mi sesión (como artículos en un carrito de compras)? ¿Se almacenan realmente en una base de datos en algún lugar y luego se purgan periódicamente? ¿Cómo funciona esto cuando estás usando un token en lugar de cookies?

Y luego, como pregunta relacionada, ¿son los principales sitios web (Amazon, Google, Facebook, Twitter, etc.) realmente apátridas? ¿Utilizan tokens o cookies (o ambos)?


fuente
38
Últimamente he visto y hablado con desarrolladores que están obsesionados con la apatridia hasta el punto de distracción. Es bueno tener apatridia para la reutilización, pero no es realista perseguir ese objetivo en cada situación por encima de cualquier otro objetivo a menos que tenga una tonelada de recursos para hacerlo por alguna razón, como el escalado.
Mark Rogers
44
@MarkRogers ¿Por qué? La apatridia no tiene nada que ver con la reutilización. Y ser apátrida no lleva a un mayor esfuerzo.
Paul Wasilewski
3
@PaulWasilewski: Y ser apátrida no lleva a un mayor esfuerzo. => lo hace, con una aplicación con estado mantienes todo en la memoria vinculado a la sesión. Esto no escala bien, aunque funciona con la fijación de sesión, pero es MUY simple. Cuando los servidores necesitan comenzar a intercambiar información entre ellos, comienzan los problemas.
Matthieu M.
66
Al mirar Amazon, notará que su carrito permanece incluso si cambia de computadora, por lo que no se almacena en una cookie, sino en una base de datos.
njzk2
20
Si no puedes leer mi respuesta. Aquí está la versión corta: las solicitudes web son inherentemente sin estado. Las aplicaciones web no lo son. (¡No importa lo que te
digan

Respuestas:

95

"las aplicaciones web deben estar sin estado" deben entenderse como "las aplicaciones web deben estar sin estado a menos que haya una muy buena razón para tener estado" . Un "carrito de compras" es una característica con estado por diseño, y negar eso es bastante contraproducente. El objetivo del patrón del carrito de compras es preservar el estado de la aplicación entre solicitudes.

Una alternativa que podría imaginar como un sitio web sin estado que implementa un carrito de compras sería una aplicación de una sola página que mantiene el carrito de compras completamente del lado del cliente, recupera información del producto con llamadas AJAX y luego la envía al servidor de una vez cuando El usuario realiza un pago. Pero dudo que haya visto a alguien realmente hacer eso, porque no permite al usuario usar múltiples pestañas del navegador y no conserva el estado cuando cierra accidentalmente la pestaña. Claro, existen soluciones alternativas como el uso de almacenamiento local, pero luego tiene estado nuevamente, solo en el cliente en lugar del servidor.

Siempre que tenga una aplicación web que requiera conservar datos entre páginas vistas, generalmente lo hace introduciendo sesiones. La sesión a la que pertenece una solicitud se puede identificar mediante una cookie o mediante un parámetro de URL que agregue a cada enlace. Deben preferirse las cookies porque mantienen sus URL más útiles y evitan que su usuario comparta accidentalmente una URL con su ID de sesión. Pero tener tokens de URL como alternativa también es vital para los usuarios que desactivan las cookies. La mayoría de los marcos de desarrollo web tienen un sistema de manejo de sesión que puede hacer esto de forma inmediata.

En el lado del servidor, la información de la sesión generalmente se almacena en una base de datos. El almacenamiento en caché en memoria del lado del servidor es opcional. Puede mejorar enormemente el tiempo de respuesta, pero no le permitirá transferir sesiones entre diferentes servidores. Por lo tanto, necesitará una base de datos persistente como alternativa.

¿Son los principales sitios web (Amazon, Google, Facebook, Twitter, etc.) realmente apátridas? ¿Utilizan tokens o cookies (o ambos)?

¿Te permiten iniciar sesión? Cuando cierra la pestaña y vuelve a visitar el sitio, ¿todavía está conectado? Si es así, están utilizando cookies para preservar su identidad entre sesiones.

Philipp
fuente
46
Creo que una de las confusiones aquí es la distinción entre una "aplicación web" en el sentido amplio de la perspectiva del usuario y la "aplicación web" en el sentido estricto del "código que se ejecuta en el servidor web". Es lo último lo que a menudo se argumenta como apátrida, no lo primero. Como usted dice, no tiene sentido que el primero sea apátrida en general, ya que el estado generalmente es parte de la lógica empresarial. Para que este último no tenga estado simplemente significa que ese estado debe almacenarse en el cliente o en el servidor de la base de datos o en ambos y no en el servidor web.
Derek Elkins
16
"[...] pero luego tienes estado nuevamente, solo en el cliente en lugar de en el servidor". Se trata de no tener estado en el lado del servidor, para lograr una mejor escalabilidad y disponibilidad. Si un estado se almacena en el lado del cliente, no importa.
Paul Wasilewski
55
@ njzk2, ¿puedes elaborar para que esto no suene absurdo? Los usuarios no van a Amazon para comprar más nombres. Y, después de hacer su compra, algo desaparece que solo existía mientras estaban comprando. Si ese algo no es "el estado de la aplicación", entonces ¿qué es? Si las aplicaciones no tienen estado, ¿qué tienen?
3
@nocomprende: Creo que la esencia general de njzk2 es que el contenido de su carrito, como su nombre completo, son datos que una aplicación web persiste en el lado del servidor. Cuando la gente dice, "las webapps no deberían tener estado", generalmente significan algo diferente de "las webapps no deberían acceder a una base de datos que contenga su nombre completo asociado con su nombre de usuario". Precisamente lo que no quieren decir con "sin estado", tal vez no esté definida trivialmente, ya que una vez que tenga esa base de datos hay todo tipo de tonterías que se podía persistir en ese país, para apoyar la aplicación del estado excesivamente complejo, pero no debe ;-)
Steve Jessop
44
@nocomprende: descifre un huevo haciendo retroceder la base de datos: dado que nuestra aplicación web no tiene estado puede reanudarse como antes;
Steve Jessop
56

Es cierto que las aplicaciones web deberían ser apátridas. Sin embargo, las variables de sesión, las cookies y los tokens no violan esto cuando se almacenan en el cliente (navegador web). Pueden ser parámetros en la solicitud.

Aquí hay un modelo simplificado:

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

Esto podría funcionar para el intercambio de pila de ingeniería de software . Esta respuesta que estoy escribiendo es parte del estado de mi navegador web. Mientras ese sea el único lugar donde esté, no es accesible para nadie más que para mí. Pero tan pronto como llego a Post your Answermi navegador, lo envía al servidor web. El servidor web procesa la publicación sin ningún estado propio. Aprende quién soy desde mi navegador y desde la base de datos. Una vez que haya terminado de revisar mi publicación y agregarla a la base de datos, el servidor web se olvida rápidamente de mí.

Eso es lo que significa apátrida. El servidor no es responsable de recordar nada de esto. Ese no es su trabajo.

Hacer esto tiene muchas ventajas. Si el servidor web tiene una pérdida de memoria, es detectable ya que su huella de memoria no debería estar creciendo. Si el servidor web falla, mi identidad no va con él. Si alguien intenta hacer un ataque de denegación de servicio, no puede usar los recursos de estado del servidor web para hacerlo, porque el servidor web no les asigna ningún estado entre sesiones. Todo esto tiene como objetivo hacer que el servidor web sea estable. De esa manera, cuando comienza a funcionar, permanece en funcionamiento.

Ahora claro, estoy consumiendo recursos en la base de datos, pero esos recursos se han verificado primero con mi asignación por algo estable con el que podemos contar para proteger la base de datos de la web salvaje y laberíntica: el servidor web sin estado que hace cumplir las reglas comerciales.

naranja confitada
fuente
8
No sé ... Esta respuesta suena un poco como decir: "¡ Excel no almacena su hoja de cálculo, la unidad de disco sí lo hace!" Ja, ja, ¿no es la base de datos parte del servidor web, en lo que respecta a la mayoría de las personas? Obviamente, el estado no se almacena en la CPU o el código del servidor, y mantenerlo todo en la memoria es bastante tonto.
77
@nocomprende No, la base de datos generalmente no forma parte de su servidor web. Sí, almacenar el estado en una base de datos posiblemente limita la escalabilidad de la aplicación general, pero hay relativamente pocas aplicaciones que pueden descargar todo su estado (o incluso todo el estado "por usuario") en el cliente. Los servidores de bases de datos están diseñados específicamente para manejar el estado de forma escalable y, como menciona CandiedOrange, generalmente están mejor protegidos, aprovisionados y examinados que los servidores web. Hay beneficios de poder escalar fácilmente los servidores web aunque eso no resuelva todos los problemas de escalabilidad.
Derek Elkins
99
@nocomprende: El punto de decir que la base de datos no es parte del servidor web es que puede tener una única base de datos (o grupo de bases de datos) para 1, 2, 3, ... servidores web. Así es como estar sin estado significa aumentar la escalabilidad: puede escalar el clúster de la base de datos y la cantidad de servidores web de forma independiente.
Matthieu M.
66
"Es cierto que las aplicaciones web deberían ser apátridas". No. Esto no tiene sentido.
svidgen
44
Esta respuesta es la que más me gusta porque ilustra mejor el uso de "sin estado" en el desarrollador web. El servidor no mantiene el estado entre las solicitudes. Todo el estado debe provenir del cliente (es decir, parte de la solicitud) o de la base de datos (probablemente basada en la solicitud). Por otro lado, a menudo hay algún estado en la aplicación web (por ejemplo, instancias estáticas de cosas), pero en general, desearía diseñar cosas para que no tengan estado. Esta respuesta parece mejor que la aceptada para explicar mejor la idea de la apatridia.
Kat
30

las aplicaciones web deben ser apátridas

Disparates. Las solicitudes web deben ser apátridas. O más exactamente, las solicitudes web no tienen estado.

Pero decir que toda una aplicación debería ser apátrida no tiene sentido.

cada solicitud se trata como una transacción independiente.

Si exactamente . O más exactamente, sí, necesariamente . Sobre HTTP, cada solicitud es inherentemente independiente de todas las demás solicitudes. Agregar "estado" a HTTP requiere que identifique, almacene y recupere explícitamente el "estado" para cada solicitud "con estado". Y eso requiere esfuerzo, disminuye el rendimiento y agrega complejidad.

Y, por esas razones, cada solicitud que puede ser apátrida "debería" ser apátrida.

Como resultado, se deben evitar la sesión y las cookies (ya que ambas tienen estado). Un mejor enfoque es usar tokens

Algunas cosas: los tokens también pueden vincularse al almacenamiento de la sesión. Las cookies no necesitan estar vinculadas al almacenamiento de la sesión. Los tokens a menudo se almacenan en cookies. Y, a veces, una sesión es simplemente la herramienta adecuada para el trabajo.

¡Eso significa que al menos a veces , las sesiones y las cookies son tan "mejores" como los tokens!

[Los tokens] no tienen estado porque no hay nada almacenado en el servidor.

Bueno, eso es todo. De eso se trata realmente el dogma de la "apatridia". Sin embargo, para ser claros, no se trata de almacenar "nada" en el servidor, se trata de no almacenar el estado de la sesión en el servidor.

Mi bandeja de entrada de Gmail está en un estado, por ejemplo. ¡Y es mejor que se almacene en el servidor! Pero, no es estado de sesión .

Por lo tanto, en lugar de tener un servidor que pueda tomar un pequeño identificador y descubrir quién es, etc., las aplicaciones sin estado desean que se les recuerde quién es usted y qué está haciendo con cada solicitud sangrienta. El estado de la aplicación aún existe, el cliente solo es responsable de retenerlo.

Ahora, si ese estado es pequeño, probablemente esté bien. En algunos casos es muy bueno.

Y luego, por supuesto, hay cosas que simplemente esperamos que tengan estado ...

¿Cómo pueden las aplicaciones web ser apátridas cuando hay datos que se guardan para mi sesión (como artículos en un carrito de compras)? ¿Se almacenan realmente en una base de datos en algún lugar y luego se purgan periódicamente?

Dos opciones. ¡O tienes una sesión, o estás en negación!

... Pero en serio. Normalmente no almacenarías un carrito en una galleta. Algo así como un carrito de compras se almacenará en una sesión "tradicional", o se almacenará como un Cartobjeto, con algún tipo de identificación que el servidor usa para atraerlo a solicitudes posteriores. Algo así como una ... uhh ... ... err ... sesión.

Realmente en serio: hay un gran grado en que la "capacidad de estado" es exactamente lo que llamamos cuando dos agentes comunicantes pueden contextualizar los mensajes en una conversación. Y una sesión, entendida tradicionalmente, es justo lo que típicamente llamamos el mecanismo por el cual esto ocurre.

Yo diría que, independientemente de si usa tokens o "sesiones", para cada solicitud que maneja su servidor, debe contextualizar esa solicitud para cumplirla o no. Si el contexto no es necesario, no lo traigas. Si el contexto es necesario, ¡ es mejor que lo tenga cerca!

Y luego, como pregunta relacionada, ¿son los principales sitios web (Amazon, Google, Facebook, Twitter, etc.) realmente apátridas? ¿Utilizan tokens o cookies (o ambos)?

Probablemente ambos. Pero, en términos generales, hacen exactamente lo que usted hace: establecen cookies para identificar registros de "estado" en bases de datos masivas de "sesión".

Cuando es posible, sospecho que colocan las afirmaciones básicas de identidad en "tokens" de corta duración para evitar una contención innecesaria en el almacenamiento centralizado. Pero el hecho de que muchos de estos servicios me permitan "cerrar sesión en todas las demás ubicaciones" es un buen indicador de que, si están usando tokens, al menos están "respaldados" por un modelo de sesión semi-tradicional .

svidgen
fuente
3
De acuerdo. Me recuerda la idea de "datos inmutables". Si es inmutable, tallarlo en una roca, no desperdicie una computadora para hacer eso. ¡Deje que las computadoras hagan cosas con datos! ¡Por eso los construimos! Las aplicaciones funcionan con datos. Los datos que son constantes son inútiles.
@nocomprende FYI, haré una adición a esto más tarde. Siento que a mi respuesta le falta parte de la pregunta subyacente del OP. Porque, no es una preocupación legítima flotando detrás de la idea de "aplicación sin estado". Pero, la respuesta está en la línea de, cuando la gente dice "sin estado", lo que quieren decir es "depende mínimamente de las sesiones del lado del servidor".
svidgen
44
@nocomprende: las estructuras de datos inmutables es algo diferente y es una herramienta utilizada para administrar los ciclos de vida de los objetos de memoria.
whatsisname
1
Amo tu primera línea de explicación. Cuando discutimos algo, cada declaración verbal que hacemos instantáneamente desaparece en el olvido. Pero de alguna manera, todavía podemos mantener una conversación, ¿eh? Es magia!
1
@nocomprende Esta es una discusión interesante, pero creo que no deberíamos continuar aquí.
pabrams
14

La capacidad de estado no es necesariamente algo malo, pero debe comprender la diferencia entre las aplicaciones con estado y sin estado. En resumen, las aplicaciones con estado mantienen información sobre la sesión actual, y las aplicaciones sin estado no. La información almacenada permanentemente como parte de una cuenta de usuario puede o no almacenarse en una sesión, pero el almacenamiento de información relacionada con una cuenta de usuario no hace que la aplicación tenga estado. La capacidad de estado requiere que el servidor mantenga información sobre la sesión del usuario actual más allá de lo que mantiene el navegador del cliente. Por ejemplo, un cliente podría autenticarse y recibir una cookie JSESSIONID, que luego envía al servidor con cada solicitud. Si el servidor comienza a almacenar cosas en el alcance de la sesión de la aplicación en función de este JSESSIONID, se vuelve con estado.

Apatridia

Por apátrida, queremos decir que el servidor y el cliente no mantienen información actual sobre la sesión del usuario. El cliente y el servidor pueden usar alguna forma de token para proporcionar autenticación entre solicitudes, pero no se almacena ninguna otra información actual. Un caso de uso típico para una solución de este tipo podría ser un sitio de noticias donde la mayoría de los usuarios (nuevos consumidores) consumen información pero no producen información que regrese al sitio. En tales casos, el sitio no necesita mantener ninguna información sobre la sesión de usuario actual. Tenga en cuenta que el sitio aún puede usar cookies para identificar al usuario y almacenar información sobre el uso del sitio por parte de ese usuario, pero aún puede considerarse como apátrida ya que todo lo registrado podría ser transaccional, por ejemplo, en qué enlace hizo clic el usuario, que podría registrar el servidor, pero no se mantiene en una sesión de usuario.

Statefulness en el servidor

En el servidor, una aplicación con estado guarda información de estado sobre los usuarios actuales. Este enfoque generalmente implica el uso de cookies para identificar el sistema del usuario para que el estado se pueda mantener en el servidor entre las solicitudes. Las sesiones pueden o no ser autenticadas, dependiendo del contexto de la aplicación. Las aplicaciones de servidor con estado ofrecen la ventaja de almacenar en caché la información del estado del usuario en el servidor, acelerando las búsquedas y el tiempo de respuesta de la página. En el lado negativo, el almacenamiento de información en el alcance de la sesión es costoso y, a escala, requiere muchos recursos. También crea un potencial vector de ataque para que los hackers intenten secuestrar identificadores de sesión y robar sesiones de usuario. Las aplicaciones de servidor con estado también tienen el desafío de proteger las sesiones de los usuarios contra interrupciones inesperadas del servicio, por ejemplo, una falla del servidor.

Statefulness en el cliente

Mediante el uso de JavaScript y tecnologías de navegador modernas como sessionStorage, la aplicación ahora puede almacenar fácilmente información de estado sobre una sesión de usuario en el dispositivo de ese usuario. En general, la aplicación aún puede considerarse con estado, pero el trabajo de mantener el estado se ha trasladado al cliente. Este enfoque tiene una gran ventaja (para el responsable del mantenimiento de la aplicación web) sobre el mantenimiento del estado en el servidor, ya que cada usuario mantiene, en efecto, su propio estado y no supone una carga para la infraestructura del servidor. A escala web, ese tipo de elección arquitectónica tiene enormes repercusiones para los costos de hardware y electricidad. Literalmente, podría costar millones de dólares al año mantener el estado en el servidor. Pasar a un sistema que mantenga el estado del cliente podría ahorrar millones de dólares al año.

Tokens v. Cookies

Las cookies actúan como identificadores para los dispositivos / navegadores del cliente. Se pueden usar para almacenar todo tipo de cosas, pero generalmente almacenan algún tipo de identificador, como CFID / CFTOKEN en aplicaciones CFML. Las cookies se pueden configurar para que vivan en el navegador del usuario durante mucho tiempo, lo que permite hacer cosas como mantener la autenticación en una aplicación entre las sesiones del navegador. Las cookies también se pueden configurar en memoria solamente para que caduquen cuando un usuario cierra el navegador.

Los tokens son generalmente algún tipo de información de identificación sobre el usuario que se genera en el servidor (utilizando cifrado para codificar la información), se pasa al cliente y se devuelve al servidor con la solicitud posterior. Se pueden pasar en el encabezado de la solicitud y la respuesta, que es un patrón común en aplicaciones de una sola página. Idealmente, cada solicitud / respuesta da como resultado la generación de un nuevo token, por lo que los tokens no pueden ser interceptados y utilizados más tarde por un atacante.

Aplicaciones de página única y estado del cliente

Con los SPA, la información de estado se carga en el navegador del cliente y se mantiene allí. Cuando el estado cambia, por ejemplo, publica una actualización en su cuenta de redes sociales, el cliente transmite esa nueva transacción al servidor. En este caso, el servidor guarda esa actualización en un almacén de datos persistente como una base de datos y retransmite cualquier información al cliente que necesita sincronizar con el servidor en función de la actualización (por ejemplo, una ID para la actualización).

Tenga en cuenta que este patrón de estado de almacenamiento en el cliente ofrece ventajas para las experiencias en línea / fuera de línea, ya que puede desconectarse del servidor mientras aún tiene una aplicación algo utilizable. Twitter es un buen ejemplo de este caso, donde puedes revisar cualquier cosa cargada del lado del cliente en tu feed de Twitter, incluso si estás desconectado de la aplicación del servidor de Twitter. Este patrón también crea complejidad en la sincronización entre el servidor y el cliente, que es un tema completamente propio. Las complejidades de la solución son una compensación para poder mantener el estado del cliente.

La capacidad de representación en el cliente hace que las aplicaciones web se sientan y se comporten más como las aplicaciones de escritorio tradicionales. A diferencia de las aplicaciones de escritorio, normalmente no tendrá toda la información de su cuenta cargada en su sesión de cliente en un navegador. Hacerlo en muchos casos sería poco práctico y produciría malas experiencias. ¿Te imaginas intentar cargar un cuadro completo de Gmail en el navegador? En cambio, el cliente mantiene información como qué etiqueta / carpeta está mirando y en qué parte de la lista de correos electrónicos de esa carpeta está mirando. Equilibrar qué información de estado mantener y qué solicitar según sea necesario es otro desafío de ingeniería de este patrón, y nuevamente, representa una compensación entre la practicidad y la provisión de buenas experiencias de usuario.

Carritos de compras y similares

En cuanto a detalles como los carritos de compras, realmente depende de la solución. Un carrito de compras puede almacenarse en una base de datos en el servidor, puede almacenarse solo en el alcance de la sesión en el servidor, o incluso puede almacenarse en el cliente. Amazon tiene carritos de compra persistentes para usuarios registrados y carritos "temporales" para usuarios anónimos, aunque estos carritos son persistentes en cierta medida.

Cuando se habla de algo como Google, que en realidad es un conjunto de aplicaciones diferentes que viven bajo la misma marca, probablemente no comparten una arquitectura común, y cada una está construida de la manera que mejor satisfaga las necesidades de sus usuarios. Si desea aprender cómo se construye un sitio, abra las herramientas de desarrollador en su navegador y mírelo. Compruebe si hay cookies, observe el tráfico de la red y vea cómo se ejecuta.

Lo siento si esta respuesta divaga un poco, pero la afirmación es un tema complejo.

Robert Munn
fuente
6

No es necesario evitar las sesiones y las cookies. Todavía puede tenerlos con aplicaciones web sin estado.

Hay una gran diferencia entre Java y Ruby on Rails. Las aplicaciones Java almacenarán la sesión en la memoria utilizando una clave de sesión almacenada en una cookie. Esto es rápido para recuperar el estado del usuario y el carrito de compras. Sin embargo, siempre debe presionar el mismo servidor con su sesión.

Las aplicaciones de Rails almacenan la identificación del usuario en una cookie firmada y encriptada. No puede ser manipulado. Cuando carga una página, la aplicación web obtiene su estado, usuario y carrito de compras de una base de datos. ¡Esto es más lento, pero la clave es que puedes golpear cualquier instancia ! Esto le permite reiniciar, escalar, cerrar instancias a voluntad. Muy conveniente. También se puede hacer más rápido con una base de datos de caché compartida en memoria como Redis. O puede almacenar el carrito de compras en la cookie, siempre que sea lo suficientemente pequeño.

Para que pueda lograr la apatridia, a través de técnicas inteligentes, y agregar la capacidad de escalar a voluntad.

Chloe
fuente
5

Cuando se hace referencia a sin estado, por ejemplo, en un servicio HTTP RESTful, se trata de evitar almacenar el estado en el lado del servidor. En el mejor de los casos, eso incluye también evitar el almacenamiento de cualquier estado en una base de datos u otros almacenamientos persistentes en el back-end. Para que quede claro, estoy hablando de un estado, no de datos en general. Parece que algunos chicos están mezclando cosas.

Una comunicación sin estado tiene varios beneficios, especialmente con respecto a la escalabilidad y la disponibilidad.

Un mejor enfoque es usar tokens, que no tienen estado porque no hay nada almacenado en el servidor.

Eso es cierto (para ciertos protocolos de autenticación y autorización). Los tokens pueden (pero no per se) proporcionar toda la información dentro de la solicitud que se necesita para autenticar a un usuario o autorizar una acción. Por ejemplo, eche un vistazo a JWT .

Así que estoy tratando de entender, ¿cómo pueden las aplicaciones web no tener estado cuando hay datos que se guardan para mi sesión (como artículos en un carrito de compras)? ¿Se almacenan realmente en una base de datos en algún lugar y luego se purgan periódicamente? ¿Cómo funciona esto cuando estás usando un token en lugar de cookies?

En cuanto al ejemplo del carrito de compras. No es ningún problema almacenar todos los artículos del carrito en el lado del cliente sin usar una sesión o cookies. Puede encontrar un ejemplo en smashingmagazine.com . Pero también es posible realizar un carrito de compras sin estado con cookies (al menos si su surtido no es tan grande y 4kb de almacenamiento es suficiente para usted).

No me malinterpreten, eso no significa que deba implementar un carrito de compras sin estado a cualquier precio. Amazon u otras grandes plataformas de compras en línea están utilizando implementaciones de carrito de compras con estado porque la experiencia del usuario y la usabilidad son más importantes para ellos que el ajuste de requisitos técnicos no funcionales como la escalabilidad.

En general, los tokens no se usan para almacenar información como artículos de carrito. Se utilizan para una autenticación y autorización sin estado.

Y luego, como pregunta relacionada, ¿son los principales sitios web (Amazon, Google, Facebook, Twitter, etc.) realmente apátridas? ¿Utilizan tokens o cookies (o ambos)?

Si está preguntando si están usando cookies o tokens para la autenticación, la respuesta es que usan ambos. Para los usuarios, en su mayoría se utilizan cookies para clientes técnicos, en su mayoría tokens.

Paul Wasilewski
fuente
-2

OK, la regla que cita es técnicamente incorrecta. Todas las capas de una aplicación web tienen estado.

La intención de la regla es "no mantener el lado del servidor de estado por sesión".

Es decir, variables de sesión en ASP , que se usaban comúnmente para hacer cosas como elementos en la cesta / nombre de usuario, etc.

La razón es que se quedará sin memoria en el servidor a medida que su aplicación gane más usuarios. Mover el almacenamiento a una base de datos o caché compartida no resuelve el problema, ya que todavía tiene un cuello de botella.

Para mantener el estado de la aplicación por usuario sin encontrar este problema, mueva el estado al lado del cliente. Por ejemplo, coloque los elementos de la cesta en una cookie o en un almacenamiento más avanzado del lado del cliente.

Debido a que el número de clientes aumenta con el número de usuarios, su aplicación en su conjunto no tendrá un cuello de botella y se escalará bien.

Ewan
fuente
2
Si bien las pérdidas de memoria y los problemas de denegación de servicio fueron un factor, creo que un controlador más importante hoy en día es la elasticidad y la solidez ante fallas de un servidor web que, por supuesto, también está relacionado con la escalabilidad. La idea es que si un servidor se sobrecarga o incluso falla, simplemente puedo redirigir futuras solicitudes (y con un poco más de cuidado, incluso reproducir solicitudes fallidas) a nuevos servidores web sin coordinación o pérdida de estado (como el usuario lo ve).
Derek Elkins
hmm tipo de Si tiene información por usuario en el servidor, incluso si está distribuida, todavía tiene un problema de escalabilidad.
Ewan
Hay muchas cosas que puede hacer si extraer datos del disco es el cuello de botella, como el almacenamiento en caché.
JeffO
no, hay un problema inherente si mantiene esos datos por sesión. o lo mueves del servidor web a su propio sistema de alta disponibilidad o lo eliminas todo al moverlo al cliente
Ewan
1
Toda esta discusión sobre tratar de evitar la papa caliente realmente me desconcierta. ¿Qué pasó con el viejo dicho, "El dinero se detiene aquí"? Algo tiene que administrar los datos, a mi banco no le gustaría que guarde toda la información de mis transacciones financieras solo en mi computadora portátil. ¿Por qué todos huyen gritando de los datos? ¡Es por eso que tenemos computadoras! Loca.