Как сохранить приложения без сохранения состояния

97

Это может быть запутанный вопрос, но я пытаюсь лучше понять безгражданство.

Исходя из того, что я прочитал, веб-приложения должны быть без сохранения состояния, то есть каждый запрос рассматривается как независимая транзакция. В результате следует избегать сеанса и файлов cookie (так как они оба с состоянием). Лучшим подходом является использование токенов, которые не сохраняют состояния, поскольку на сервере ничего не хранится.

Поэтому я пытаюсь понять, как веб-приложения могут быть без сохранения состояния, когда для моего сеанса хранятся данные (например, элементы в корзине)? Хранятся ли они где-то в базе данных, а затем периодически удаляются? Как это работает, когда вы используете токен вместо куки?

И затем, в качестве связанного вопроса, являются ли главные сайты (Amazon, Google, Facebook, Twitter и т. Д.) Фактически без гражданства? Они используют токены или куки (или оба)?


источник
38
Я видел и говорил с разработчиками в последнее время, которые одержимы безгражданством до безумия. Приятно иметь безгражданство для повторного использования, но нереально достигать этой цели в любой ситуации по сравнению с любой другой, если у вас нет тонны ресурсов для этого по какой-то причине, например, масштабирования.
Марк Роджерс
4
@MarkRogers Почему? Безгражданство не имеет ничего общего с возможностью повторного использования. А отсутствие гражданства не приводит к более высоким усилиям.
Павел Василевский
3
@PaulWasilewski: А безгражданство не требует больших усилий. => да, с приложением с сохранением состояния вы храните все в памяти, привязанное к сеансу. Это не хорошо масштабируется, хотя работает с закреплением сессии, но это ОЧЕНЬ просто. Когда серверы должны начать обмениваться информацией между собой, начинаются проблемы.
Матье М.
6
Посмотрев на amazon, вы заметите, что ваша корзина остается, даже если вы меняете компьютер, поэтому она хранится не в cookie, а в базе данных.
njzk2
20
Если вы не удосужились прочитать мой ответ. Вот короткая версия: веб-запросы по своей сути не имеют состояния. Веб- приложений нет. (Неважно, что говорят вам некоторые догматики из «сети без гражданства»!)
svidgen

Ответы:

95

«Веб-приложения должны быть без состояния» следует понимать как «веб-приложения должны быть без состояния, если только для этого нет веских оснований» . «Корзина для покупок» - это особенность, созданная по замыслу, и отрицание этого весьма непродуктивно. Весь смысл шаблона корзины покупок заключается в сохранении состояния приложения между запросами.

Альтернативой, которую я мог бы представить как веб-сайт без состояния, который реализует корзину покупок, было бы одностраничное приложение, которое сохраняет корзину покупок полностью на стороне клиента, извлекает информацию о продукте с помощью вызовов AJAX и затем сразу отправляет ее на сервер, когда пользователь делает заказ. Но я сомневаюсь, что когда-либо видел, чтобы кто-то действительно делал это, потому что он не позволяет пользователю использовать несколько вкладок браузера и не сохраняет состояния, когда они случайно закрывают вкладку. Конечно, есть обходные пути, такие как использование localalstorage, но тогда у вас снова будет состояние, только на клиенте, а не на сервере.

Всякий раз, когда у вас есть веб-приложение, которое требует сохранения данных между просмотрами страниц, вы обычно делаете это, вводя сеансы. Сеанс, к которому принадлежит запрос, может быть идентифицирован с помощью файла cookie или параметра URL, который вы добавляете в каждую ссылку. Куки должны быть предпочтительнее, потому что они делают ваши URL более удобными и предотвращают случайное использование пользователем вашего URL с идентификатором сессии. Но наличие URL-маркеров в качестве запасного варианта также крайне важно для пользователей, которые отключают файлы cookie. Большинство каркасов веб-разработки имеют систему обработки сеансов, которая может сделать это «из коробки».

На стороне сервера информация о сеансе обычно хранится в базе данных. Кэширование в памяти на стороне сервера необязательно. Это может значительно улучшить время отклика, но не позволит вам переносить сеансы между разными серверами. Таким образом, вам понадобится постоянная база данных в качестве запасного варианта.

основные веб-сайты (Amazon, Google, Facebook, Twitter и т. д.) фактически не имеют статуса? Они используют токены или куки (или оба)?

Они позволяют вам войти? Когда вы закрываете вкладку и снова посещаете сайт, вы все еще вошли в систему? Если да, то они используют куки для сохранения вашей личности между сессиями.

Philipp
источник
46
Я думаю, что одно из недоразумений здесь - это различие между «веб-приложением» в широком смысле с точки зрения пользователя и «веб-приложением» в узком смысле «кода, работающего на веб-сервере». Это последнее, что часто утверждают, что оно не имеет гражданства, а не первое. Как вы говорите, для первого не имеет смысла вообще оставаться без гражданства, так как государство обычно является частью бизнес-логики. Чтобы последний не имел состояния, просто означает, что состояние должно храниться на клиенте или на сервере базы данных или на обоих, а не на веб-сервере.
Дерек Элкинс,
16
«[...] но тогда у вас снова будет состояние, только на клиенте, а не на сервере». Речь идет об отсутствии состояния на стороне сервера для достижения лучшей масштабируемости и доступности. Если состояние хранится на стороне клиента, не имеет значения.
Павел Василевский
5
@ njzk2, можешь ли ты уточнить, чтобы это не звучало абсурдно? Пользователи не идут в Amazon, чтобы купить больше имен. И после того, как они совершают покупку, что-то исчезает, что существовало только во время покупок. Если это что-то не «состояние приложения», то что это? Если у приложений нет состояния, что они имеют?
3
@nocomprende: Я думаю, что основная суть njzk2 заключается в том, что содержимое вашей корзины, как и ваше полное имя, - это данные, которые веб-приложение сохраняет на стороне сервера. Когда люди говорят, что «веб-приложения должны быть без сохранения состояния», они обычно имеют в виду нечто иное, чем «веб-приложения не должны обращаться к базе данных, содержащей ваше полное имя, связанное с вашим именем пользователя». Именно то , что они действительно подразумевают под «без гражданства» , возможно , не тривиально определен, так как только у вас есть эта база данных есть все виды глупости , которые вы могли бы сохраниться там, чтобы поддерживать чрезмерно сложное состояние приложения, но не должны ;-)
Steve Джессоп
4
@nocomprende: расшифруйте яйцо, откатив базу данных: поскольку наше веб-приложение не имеет состояния, оно может возобновить работу, как и раньше ;-)
Стив Джессоп,
56

Это правда, что веб-приложения не должны иметь состояния. Однако переменные сеанса, файлы cookie и токены не нарушают этого, когда все они хранятся на клиенте (веб-браузер). Они могут быть параметрами в запросе.

Вот упрощенная модель:

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

Это может работать для разработки программного обеспечения стека обмена . Этот ответ, который я печатаю, является частью состояния моего веб-браузера. Пока это единственное место, где оно есть, оно не доступно никому, кроме меня. Но как только я нажимаю, Post your Answerмой браузер отправляет его на веб-сервер. Веб-сервер обрабатывает сообщение, не используя свое собственное состояние. Он узнает, кто я, из моего браузера и из базы данных. Как только он закончит проверку моего сообщения и добавит его в базу данных, веб-сервер быстро забудет обо мне.

Вот что значит безгражданство. Сервер не несет ответственности за запоминание всего этого. Это не его работа.

Делать это имеет много преимуществ. Если у веб-сервера есть утечка памяти, это можно обнаружить, так как его объем памяти не должен расти. Если веб-сервер падает, моя личность не идет с этим. Если кто-то пытается выполнить атаку типа «отказ в обслуживании», он не может использовать для этого ресурсы состояния веб-сервера, потому что веб-сервер не выделяет ему состояния между сеансами. Все это направлено на то, чтобы сделать веб-сервер стабильным. Таким образом, когда он начинает работать, он продолжает работать.

Теперь, конечно, я использую ресурсы в базе данных, но эти ресурсы сначала были проверены с учетом моих допусков с помощью чего-то стабильного, на что мы можем рассчитывать, чтобы защитить базу данных от дикого и неуклюжего веба: веб-сервер, обеспечивающий соблюдение бизнес-правил без сохранения состояния.

candied_orange
источник
8
Я не знаю ... Этот ответ звучит как сказать: « Excel не хранит вашу электронную таблицу, а дисковод хранит!» Ха-ха, разве это не часть базы данных веб-сервера, насколько это касается большинства людей? Очевидно, что состояние не сохраняется в процессоре или коде сервера, и хранить все это в памяти довольно глупо.
7
@nocomprende Нет, база данных обычно не является частью вашего веб-сервера. Да, сохранение состояния в базе данных вполне возможно ограничивает масштабируемость всего приложения, но существует относительно немного приложений, которые могут разгрузить все свое состояние (или даже все состояние «на пользователя») на клиент. Серверы баз данных специально разработаны для масштабируемой обработки состояния и, как упоминает CandiedOrange, обычно они лучше защищены, подготовлены и проверены, чем веб-серверы. Возможность легко масштабировать веб-серверы имеет преимущества, хотя и не решает всех проблем масштабируемости.
Дерек Элкинс
9
@nocomprende: Смысл в том, что база данных не является частью веб-сервера, состоит в том, что вы можете иметь одну базу данных (или кластер базы данных) для 1, 2, 3, .... веб-серверов. Вот как отсутствие состояния означает увеличение масштабируемости: вы можете независимо масштабировать кластер базы данных и количество веб-серверов.
Матье М.
6
«Это правда, что веб-приложения не должны иметь состояния». Нет, это полная чушь.
svidgen
4
Этот ответ мне нравится больше всего, потому что он наилучшим образом иллюстрирует использование «без сохранения состояния» в веб-разработке. Сервер не поддерживает состояние между запросами. Все состояния должны исходить от клиента (то есть, часть запроса) или из базы данных (вероятно, на основе запроса). Кроме того, в веб-приложении часто присутствует какое-то состояние (например, статические экземпляры содержимого), но в целом вы бы хотели, чтобы все было без сохранения состояния. Этот ответ кажется лучше, чем общепринятый, для лучшего объяснения идеи безгражданства.
Кат
30

веб-приложения должны быть без сохранения состояния

Бред какой то. Веб- запросы должны быть без сохранения состояния. Точнее, веб-запросы не сохраняют состояния.

Но говорить, что все приложение должно быть без сохранения состояния, - полная чушь.

каждый запрос рассматривается как независимая транзакция.

Да, точно . Точнее да, обязательно . По HTTP каждый запрос по своей природе не зависит от всех других запросов. Для добавления «состояния» в HTTP требуется, чтобы вы явно идентифицировали, хранили и извлекали «состояние» для каждого «запроса с состоянием». И это требует усилий, снижает производительность и добавляет сложности.

И по этим причинам каждый запрос, который может быть без сохранения состояния «должен быть» без сохранения состояния.

В результате следует избегать сеанса и файлов cookie (так как они оба с состоянием). Лучше всего использовать токены

Несколько вещей: токены также могут быть привязаны к хранилищу сессии. Cookies не нужно привязывать к хранилищу сессии. Токены часто хранятся в файлах cookie. И иногда сессия - это просто правильный инструмент для работы.

Это означает, что, по крайней мере, иногда сеансы и файлы cookie так же «лучше», как токены!

[Токены] не имеют состояния, потому что на сервере ничего не хранится.

Ну вот и все. Вот о чем действительно догмат "безгражданства". Хотя, чтобы было ясно, речь идет не о хранении «ничего» на сервере, а о том, чтобы не хранить состояние сеанса на сервере.

Например, мой почтовый ящик Gmail находится в состоянии. И черт побери, лучше хранить на сервере! Но это не состояние сеанса .

Таким образом, вместо того, чтобы иметь серверы, которые могут взять небольшой идентификатор и выяснить, кто вы и т. Д., Приложения без сохранения состояния хотят напоминать, кто вы и что вы делаете с каждым кровавым запросом. Состояние приложения все еще существует, клиент просто отвечает за его удержание.

Теперь, если это состояние маленькое, это, вероятно, нормально. В некоторых случаях это очень хорошо.

И затем, конечно, есть вещи, которые мы просто ожидаем, чтобы быть с состоянием ...

Как веб-приложения могут быть без сохранения состояния, если для моего сеанса хранятся данные (например, элементы в корзине)? Хранятся ли они где-то в базе данных, а затем периодически удаляются?

Два варианта. Либо у вас есть сеанс, либо вы отрицаете!

... Но серьезно. Обычно вы не храните корзину в cookie. Что-то вроде корзины покупок будет либо сохранено в «традиционном» сеансе, либо будет сохранено как Cartобъект с каким-то идентификатором, который сервер использует для перетаскивания его в последующие запросы. Вроде как .. э-э-э ... эээ ... сессия.

По-настоящему серьезно: в значительной степени «состояние» - это именно то, что мы называем, когда два взаимодействующих агента могут контекстуализировать сообщения в разговоре. Традиционно понимаемый сеанс - это то, что мы обычно называем механизмом, посредством которого это происходит.

Я бы сказал, что независимо от того, используете ли вы токены или «сеансы» для каждого запроса, который обрабатывает ваш сервер, вам нужно либо контекстуализировать этот запрос для его выполнения, либо нет. Если контекст не нужен, не выбирайте его. Если контекст является необходимым, то лучше иметь его рядом!

И затем, в качестве связанного вопроса, являются ли главные сайты (Amazon, Google, Facebook, Twitter и т. Д.) Фактически без гражданства? Они используют токены или куки (или оба)?

Вероятно, оба. Но, вообще говоря, они делают именно то, что вы делаете: они устанавливают файлы cookie для идентификации записей «состояния» в больших «сессионных» базах данных.

Я подозреваю, что, когда это возможно, они помещают базовые утверждения личности в недолговечные «токены», чтобы избежать ненужных конфликтов в централизованном хранилище. Но тот факт, что многие из этих сервисов позволяют мне «выходить из всех других местоположений», является хорошим индикатором того, что, если они вообще используют токены, они, по крайней мере, «поддерживаются» полу-традиционной моделью сеанса ,

svidgen
источник
3
Согласен. Это напоминает мне идею «неизменных данных». Если он неизменен, вырежьте его в скале, не тратьте компьютер на это. Пусть компьютеры разбираются с данными! Вот почему мы их построили! Приложения работают с данными. Данные, которые являются постоянными, бесполезны.
@nocomprende К вашему сведению, я сделаю дополнение к этому позже. Я чувствую, что в моем ответе отсутствует часть основного вопроса ОП. Потому что, там есть законная озабоченность плавающая за идеей «лицо без применения». Но ответ заключается в том, что когда люди говорят, что они не имеют состояния, они хотят сказать , что они «минимально зависят от сеансов на стороне сервера».
svidgen
4
@nocomprende: неизменяемые структуры данных - это нечто иное, это инструмент, используемый для управления жизненными циклами объектов памяти.
whatsisname
1
Любите свою первую линию объяснения. Когда мы что-то обсуждаем, каждое сделанное нами словесное утверждение мгновенно умирает. Но каким-то образом мы все еще можем вести разговор, а? Это магия!
1
@nocomprende Это интересное обсуждение, но я думаю, что мы не должны продолжать его здесь.
Пабрамс
14

Statefulness не обязательно плохая вещь, но вы должны понимать разницу между приложениями с состоянием и приложениями без сохранения состояния. Короче говоря, приложения с отслеживанием состояния хранят информацию о текущем сеансе, а приложения без сохранения состояния - нет. Информация, хранимая постоянно как часть учетной записи пользователя, может храниться или не сохраняться в сеансе, но хранение информации, связанной с учетной записью пользователя, само по себе не делает приложение сохраняющим состояние. Statefulness требует, чтобы сервер поддерживал информацию о сеансе текущего пользователя помимо того, что поддерживает браузер клиента. Например, клиент может пройти аутентификацию и получить cookie-файл JSESSIONID, который он затем отправляет на сервер с каждым запросом. Если сервер начинает хранить содержимое в области сеанса приложения на основе этого JSESSIONID, он становится состоящим.

безгражданство

Под сохранением состояния мы подразумеваем, что сервер и клиент не поддерживают текущую информацию о сеансе пользователя. Клиент и сервер могут использовать токен некоторой формы для обеспечения аутентификации между запросами, но другая текущая информация не сохраняется. Типичным вариантом использования такого решения может быть новостной сайт, где большинство пользователей (новых потребителей) потребляют информацию, но не производят информацию, которая возвращается на сайт. В таких случаях сайту не нужно хранить какую-либо информацию о текущем сеансе пользователя. Обратите внимание, что сайт может по-прежнему использовать куки для идентификации пользователя и хранить информацию об использовании сайта этим пользователем, но это все равно может рассматриваться как не сохраняющее состояния, поскольку все записанное может быть транзакционным, например, по той ссылке, по которой щелкнул пользователь, которая может быть записана сервер, но не поддерживается в пользовательском сеансе.

Statefulness на сервере

На сервере приложение с сохранением состояния сохраняет информацию о состоянии текущих пользователей. Этот подход обычно включает использование файлов cookie для идентификации системы пользователя, чтобы можно было поддерживать состояние на сервере между запросами. Сеансы могут или не могут быть аутентифицированы, в зависимости от контекста приложения. Серверные приложения с сохранением состояния предлагают преимущество кэширования информации о состоянии пользователя на сервере, ускорения поиска и времени отклика страницы. С другой стороны, хранение информации в области сеанса является дорогостоящим, а в масштабе это становится очень ресурсоемким. Это также создает потенциальный вектор атаки для хакеров, пытающихся перехватить идентификаторы сеансов и украсть сеансы пользователей. Серверные приложения с отслеживанием состояния также сталкиваются с проблемой защиты пользовательских сеансов от непредвиденных прерываний обслуживания, например сбоя сервера.

Statefulness на клиенте

Используя JavaScript и современные браузерные технологии, такие как sessionStorage, приложение теперь может легко сохранять информацию о состоянии сеанса пользователя на устройстве этого пользователя. В целом, приложение все еще может считаться состоящим из состояния, но работа по поддержанию состояния была перенесена на клиента. Этот подход имеет большое преимущество (для сопровождающего веб-приложения) по сравнению с поддержанием состояния на сервере в том смысле, что каждый пользователь, по сути, поддерживает свое собственное состояние, и нет никакой нагрузки на инфраструктуру сервера. В масштабах сети такой архитектурный выбор имеет огромные последствия для затрат на оборудование и электроэнергию. Поддержание состояния сервера может буквально стоить миллионы долларов в год. Переход на систему, поддерживающую состояние клиента, может сэкономить миллионы долларов в год.

Жетоны против печенья

Cookies действуют как идентификаторы для клиентских устройств / браузеров. Они могут использоваться для хранения всевозможных вещей, но обычно они хранят некоторую форму идентификатора, такую ​​как CFID / CFTOKEN в приложениях CFML. Куки-файлы могут быть настроены на длительное использование в браузере пользователя, что позволяет выполнять такие вещи, как поддержание аутентификации в приложении между сеансами браузера. Куки-файлы также могут быть установлены только для памяти, поэтому они истекают, когда пользователь закрывает браузер.

Токены, как правило, являются своего рода идентифицирующей информацией о пользователе, которая генерируется на сервере (с использованием шифрования для шифрования информации), передается клиенту и возвращается на сервер с последующим запросом. Они могут быть переданы в заголовке запроса и ответа, что является общим шаблоном в одностраничных приложениях. В идеале каждый запрос / ответ приводит к генерации нового токена, поэтому токены не могут быть перехвачены и использованы злоумышленником позднее.

Одностраничные приложения и состояние клиента

С помощью SPA информация о состоянии загружается в браузер клиента и сохраняется там. Когда состояние изменяется, например, вы публикуете обновление для своей учетной записи в социальной сети, клиент передает эту новую транзакцию на сервер. В этом случае сервер сохраняет это обновление в постоянном хранилище данных, таком как база данных, и передает клиенту любую информацию, необходимую для синхронизации с сервером, на основе обновления (например, идентификатор для обновления).

Обратите внимание, что этот шаблон хранения состояния на клиенте предлагает преимущества для онлайн / офлайнового взаимодействия в том, что вы можете быть отключены от сервера, оставаясь при этом несколько пригодным для использования приложением. Twitter является хорошим примером этого случая, когда вы можете просмотреть все загруженные клиентские части в своем фиде Twitter, даже если вы отключены от приложения сервера Twitter. Этот шаблон также создает сложность в синхронизации между сервером и клиентом, что является отдельной темой. Сложности решения являются компромиссом для возможности поддерживать состояние на клиенте.

Statefulness на клиенте заставляет веб-приложения чувствовать и вести себя как традиционные настольные приложения. В отличие от настольных приложений, вы обычно не загружаете всю информацию своей учетной записи в сеанс клиента в браузере. Это во многих случаях было бы нецелесообразным и приводило к плохому опыту. Можете ли вы представить себе попытку загрузить весь ящик Gmail в браузер? Вместо этого клиент хранит информацию, например, какую метку / папку вы просматриваете и где в списке писем в этой папке вы просматриваете. Балансирование того, какую информацию о состоянии поддерживать и что запрашивать по мере необходимости, является еще одной инженерной задачей этого шаблона, и опять же, он представляет собой компромисс между практичностью и предоставлением хорошего пользовательского опыта.

Тележки для покупок и тому подобное

Что касается специфики, например, корзин для покупок, то это действительно зависит от решения. Корзина для покупок может храниться в базе данных на сервере, она может храниться только в объеме сеанса на сервере или даже может храниться на клиенте. Amazon имеет постоянные корзины покупок для зарегистрированных пользователей и «временные» корзины для анонимных пользователей, хотя эти корзины в некоторой степени постоянны.

Когда вы говорите о чем-то вроде Google, который на самом деле представляет собой набор различных приложений, принадлежащих одному бренду, они, вероятно, не разделяют общую архитектуру, и каждое из них построено так, чтобы наилучшим образом удовлетворить потребности своих пользователей. Если вы хотите узнать, как создается сайт, откройте инструменты разработчика в своем браузере и посмотрите на него. Проверьте наличие файлов cookie, просмотрите сетевой трафик и посмотрите, как он работает.

Извините, если этот ответ немного гремит, но полнота - сложная тема.

Роберт Манн
источник
6

Не следует избегать сессий и файлов cookie. Вы все еще можете иметь их с веб-приложениями без сохранения состояния.

Существует большая разница между Java и Ruby on Rails. Приложения Java сохранят сеанс в памяти, используя ключ сеанса, сохраненный в файле cookie. Это быстро восстановить состояние пользователя и корзину. Однако вы всегда должны использовать один и тот же сервер во время сеанса.

Приложения Rails хранят идентификатор пользователя в подписанном зашифрованном файле cookie. Это не может быть подделано. Когда вы загружаете страницу, веб-приложение выбирает ваше состояние, пользователя и корзину из базы данных. Это медленнее, но главное, вы можете поразить любой экземпляр ! Это позволяет вам перезапускать, масштабировать, выключать экземпляры по желанию. Очень удобно. Это также можно сделать быстрее с помощью общей, находящейся в памяти, кеш-базы данных, такой как Redis. Или вы можете сохранить корзину покупок в файле cookie, если он достаточно мал.

Таким образом, вы можете достичь безгражданства с помощью умных методов и добавить возможность масштабирования по желанию.

Хлоя
источник
5

Протокол является лицом без гражданства.

Но из этого не обязательно следует, что приложения, использующие протокол, не должны иметь состояния.

Вот несколько связанных ответов StackOverflow, которые хорошо объясняют разницу:

sideshowbarker
источник
5

Когда речь идет о состоянии без состояния - например, в RESTful HTTP Service - это поможет избежать сохранения состояния на стороне сервера. В лучшем случае это также позволяет избежать сохранения какого-либо состояния в базе данных или других постоянных хранилищах на сервере. Чтобы было понятно, я говорю о состоянии, а не о данных в целом. Кажется, что некоторые парни все путают.

Связь без сохранения состояния имеет несколько преимуществ, особенно в отношении масштабируемости и доступности.

Лучшим подходом является использование токенов, которые не сохраняют состояния, поскольку на сервере ничего не хранится.

Это правда (для определенных протоколов аутентификации и авторизации). Токены могут (но не сами по себе) предоставлять всю информацию в запросе, которая необходима для аутентификации пользователя или авторизации действия. Для примера взгляните на JWT .

Поэтому я пытаюсь понять, как веб-приложения могут быть без сохранения состояния, когда для моего сеанса хранятся данные (например, элементы в корзине)? Хранятся ли они где-то в базе данных, а затем периодически удаляются? Как это работает, когда вы используете токен вместо куки?

Что касается примера корзины. Нет проблем хранить все элементы корзины на стороне клиента без использования сеанса или файлов cookie. Вы можете найти пример на smashingmagazine.com . Но также возможно реализовать корзину покупок без сохранения состояния с cookie-файлами (по крайней мере, если ваш ассортимент не такой большой и вам достаточно 4 КБ).

Не поймите меня неправильно, это не значит, что вы должны внедрить корзину покупок без сохранения состояния любой ценой. Amazon или другие крупные платформы для онлайн-покупок используют реализации корзины с отслеживанием состояния, потому что для них важнее пользовательский опыт и удобство использования, чем соответствие техническим нефункциональным требованиям, таким как масштабируемость.

Как правило, токены не используются для хранения информации, такой как элементы корзины. Они используются для аутентификации и авторизации без сохранения состояния.

И затем, в качестве связанного вопроса, являются ли главные сайты (Amazon, Google, Facebook, Twitter и т. Д.) Фактически без гражданства? Они используют токены или куки (или оба)?

Если вы спрашиваете, используют ли они куки или токены для аутентификации, ответ - оба. Для пользователей в основном куки для технических клиентов в основном используются токены.

Павел Василевский
источник
-2

ОК, правило, которое вы цитируете, технически неверно. Все слои веб-приложения имеют состояние.

Целью правила является «не держать на стороне сервера состояния сеанса».

То есть переменные сеанса в ASP , которые обычно использовались для таких вещей, как элементы в корзине / имя пользователя и т. Д.

Причина в том, что вам не хватит памяти на сервере, поскольку ваше приложение набирает больше пользователей. Перемещение хранилища в базу данных или общий кэш не решает проблему, поскольку у вас все еще есть узкое место.

Чтобы поддерживать состояние приложения для пользователя без решения этой проблемы, переместите состояние на сторону клиента. Например, поместите элементы корзины в файл cookie или в более сложное хранилище на стороне клиента.

Поскольку количество клиентов зависит от количества пользователей, ваше приложение в целом не будет иметь узких мест и будет хорошо масштабироваться.

Ewan
источник
2
Хотя утечки памяти и проблемы отказа в обслуживании были фактором, я думаю, что более важным фактором в настоящее время является эластичность и устойчивость к отказу веб-сервера, что, конечно же, также связано с масштабируемостью. Идея состоит в том, что если сервер перегружен или даже дает сбой, я могу просто перенаправить будущие запросы (и с большей осторожностью, даже переиграть неудавшиеся запросы) на новые веб-серверы без координации или потери состояния (как видит пользователь).
Дерек Элкинс
хм вроде. Если у вас есть информация о пользователе на сервере, даже если она распределена, у вас все еще есть проблема с масштабируемостью.
Эван
Вы можете многое сделать, если извлечение данных с диска является узким местом, например, кеширование.
JeffO
нет, есть внутренняя проблема, если вы храните данные для каждой сессии. либо вы перемещаете его с веб-сервера в свою собственную систему высокой доступности, либо избавляетесь от всего этого вместе, перемещая его клиенту
Ewan
1
Вся эта дискуссия о попытке избежать горячей картошки действительно озадачивает меня. Что случилось со старой поговоркой «Доллар здесь останавливается»? Что-то должно управлять данными, мой банк не хотел бы, чтобы я хранил всю информацию о моих финансовых транзакциях только на своем ноутбуке. Почему все убегают, крича от данных? Вот почему у нас есть компьютеры! Псих.