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

В ООП временные данные - это состояние объектов, которые получают на вход данных из источников долговременного хранения, и до момента выдачи результата сохраняют свое состоение. В ФП программирование временные данные - это состояние переменных, которые используются внутри функции.

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

Схемы хранения состояния сеанса:

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

Варианты клиентов:

• толстый клиент (в основном мобильные приложения)
• тонкий клиент (мобильные и десктопные реализации)

Форматы данных:

• бинарные
• XML
• JSON

Для корректной работы следует сразу предусмотреть версионирование.

Организация серверного хранения состояния наиболее простое и быстрое решение, которое используется для создания небольших приложений и MVP.

Основные характеристики:

• Монолитное приложение
• Временные данные хранятся:
  • БД
  • файловая структура
• Хранения сеансов
  • Сериализация данных - текстовая или бинарная
  • Табличный формат - под каждый объект своя таблица
  • Стейтлесс объекты с хранением данных в БД

Достоинства:

• простота
• высокая скорость на старте - можно быстро получить MVP, довольно быстро внедряются новые фичи
• возможность масштабирования за счет СУБД

Недостатки:

• ограниченная масштабируемость (наиболее часто ограничено возможностью шардинга БД);
• сложные механизмы сериализации

Проблема законченных и потерянных сеансов

Состояние сеанса не должно храниться вечно, поэтому при реализации серверного хранения стейта нужно предусмотреть возможность ограничить срок хранения данных сеанса, а так же возможность досрочно очистить состояние сеанса.

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

Сериализация

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

- Частичная сериализация состояния объекта;
- Полная сериализация объекта.

Частичная сериализация состояния объекта

Подход при котором программист сам решает какие данные должны быть сериализованны, для этого есть два варианта:

    - объект сам реализует методы сериализации (по сути это реализация 
    сохранения и восстановления стейта объекта), данный подход нарушает
    SOLID поэтому используется редко
    - сериализация публичного состояния объекта (обычно сериализуется 
    начальное состояние объекта, а при восстановлении состояния объект
    должен повторно выполнить все расчеты)

Преимущества:

• явная схема сериализации
• небольшой объем данных
• контроль со стороны разработчика

Недостатки:

• ошибки при восстановлении стейта
• сложно сопровождать

Полная сериализация объекта

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

Достоинства:

- простота

Недостатки:

- большой объем данных;
- низкий контроль;
- сложно делать сериализацию иерархии объектов.

Сериализованный крупный объект

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

Важно! Для корректного восстановления объектов нужно контролировать 
структуры сохраняемых данных с помощью версионирования.

Структура таблица БД может состоять из двух полей: идентификатор сессии и сериализованные данные, допускается дублирование данных для разных идентификаторов сессий.

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

Примечание.
Клиент-серверные приложения работающие через Интернет
все чаще стали называть "веб-приложениями", более корректно
было бы называть веб-приложениями, только ту часть приложений,
которые работают через браузер (тонкий клиент).
Я буду использовать термин "веб-приложение" в более общем современном смысле.

Достоинства:

• возможность распределенной обработки и масштабирования
• клиентские ресурсы "бесплатны"
• экономия ресурсов за счет отсутствия лишней "сериализации"
• возможность раздельного тестирования
• разделение обязанностей
• низкое зацепление клиента на сервер (по сути требуется только API нужно версии)

Недостатки:

• Безопасность (данные нужно проверять, перед тем как использовать)
• Необходимость разделение команды на "фронт" и "бэк"
• Более сложная архитектура решения
• Разные реализации для мобильного и десктопного приложения

Основной проблемой является проблема безопасности.

Примечание.
Для решения вопросов безопасности используется шифрование,
хэширование, цифровые подписи.

Варианты реализации

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

Толстый клиент

- собственные структуры
- DTO
- Models

Тонкий клиент

SPA (динамические):

- URL (около 4 тыс. знаков)
- Local Storage
- JavaScript объекты

HTML (статические):

- URL (около 4 тыс. знаков)
- Cookie
- Формы (скрытые поля)

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

В данной схеме как правило используются разные схемы распределения нагрузки между серверами. И уходят от монолитной архитектуры серверной части.

Достоинства:

• обработка большого объема данных
• масштабирование серверной части

Недостатки:

• сложная архитектура
• сложное согласование и выпуск новых релизов

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