Сергей Соловьев

Почитал лицензионное соглашение (яндекс переводчик)

4. Запрещается разрабатывать какие-либо производные версии, модифицированные версии или версии сторонних производителей для распространения на основе DESTOON полностью или в любой части.

Я не юрист, поэтому как понял: Будешь распространять - накажут.

Это надо делать на бэке по разным причинам. Как минимум одну ты уже сказал - не надо палить секретный ключ.

Можно придумать 2 причину - отвал клиента: представь, что после оплаты клиент отвалился. Что будет?
- Токен подтверждения оплаты потерян
- После перезагрузки кэш браузера очистился

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

Если бы это сервер обрабатывал, то можно было бы какой-нибудь trace id сохранить в БД и быть уверенным, что даже если отвалишься, то в будущем сможешь проверить статус оплаты.

Как понял схема данных следующая:
- Есть замер времени - отедльный объект со своим ID
- У каждого замера времени есть список штампов - конкретного времени
- Эти штампы создают пользователи - отправляют запросы

Для данного кейса мне видится такое решение:
- Используем Redis в качестве БД
- Для ID замеров используем snowflake
- Тип данных Redis для замеров - list (список)
- В каждом списке храним эти штампы - строка или unix timestamp (неважно)

Таким образом, на каждый запрос просто добавляем новый элемент в этот список.

Redis хорошо выдерживает высокую нагрузку + его можно масштабировать.
Благодаря snowflake можно горизонтально мастшабировать свои сервисы.
Также, ты указал websocket - здесь как хочешь. Но в .NET есть реализация Redis которая использует мультиплексирование - здесь он будет уместен.

нормально себя чувствует.

Работает и не трогай

Зависит от многих факторов:
1. Если это полноценное офлайн приложение:
- Если необходима полноценная СУБД (SQL Server, Postgres, MySql) - то нет. Мало кто захочет дополнительно себе устанавливать такие тяжелые зависимости, они всегда могут ее удалить и тогда уже не восстановить, обновления ПО либо не будут возможны, либо трудны
- Если это встраиваемая СУБД (SQLite) - то вполне да, так многие приложения делают (на андроиде слышал SQLite часто используют)
2. Если это онлайн приложение в браузере:
- localStorage - это key/value хранилище
- web sql - устаревшая технология
- куки - могут пропасть в любое время
3. Если это корпоративные клиенты, то можно навязать им свои требования по необходимости запуска СУБД на каждой машине

Тут все зависит от того, что под БД подразумевается и для каких целей это нужно

UPD: SQL запросы из клиента напрямую в БД - очень плохая идея, не надо так (обновления, безопасность, гибкость и т.д. - все постарадает)

Верстальщик-дизайнер