1. Регистрация нового пользователя (вызов метода Reg)
Фронт отправляет POST запрос с данными, которые нужно записать в таблицу Members, сгенерив предварительно UID и повестив его вместе с данными в эту таблицу, а также сделать запись в Redis. В ответ сервер отдает UID
2. Авторизация пользователя (вызов метода Login)
Фронт отправляет запрос c данными для авторизации, сервер идет в таблицу Members, берет данные, в частности uid, генерит новый, заменяет старый в Members, а также обновляет его в Redis. Возвращает данные пользователей вместе с UID
3. Запись прогресса
Фронт отправляет запрос с UID. Сервер проверяет его в Redis, если он валидный, делает запрос в таблицу Members, обновляет соответствующие данные, а также перезаписывает UID и обновляет его в Redis
4. Запрос списка наград
Фронт отправляет UID и CONTEST_ID. Сервер проверяет валидность UID в Redis, если валидный идет в таблицу Rewards и берет все награды для Campaign_ID, а также проверяет какие награды получал пользователь в таблице Members -> Progress.
ЧТО ВИДНО ИЗ КЕЙСОВ
- Практически во всех методах идет обращение в таблицу members
- UID проверяется на валидность до момента обработки основного запроса
- Обновляем UID при POST/PUT/DELETE запросах в таблице Redis/PostgreSQL + TTL в Redis
ВОПРОС, НУЖЕН ЛИ НАМ REDIS И ПОЧЕМУ?
С одной стороны у нас появляется дополнительная прослойка
С другой стороны это прослойка уменьшает объем запросов в основную БД при условии, что будет достаточное кол-во не валидных запросов со старыми токенами. Но какой их процент в реальности?
Если действовать только на базе PostgreSQL, у нас добавляется логика обработки срока жизни токена. Т.е. нужно добавить поля когда выдан и сколько действует uid. Возможно проверка увеличит скорость обработки запроса
RidgeA, спасибо за уточнение. У нас нет жёсткой привязки к эластике, нам главное быстро формировать отчеты, работать с фильтрацией данных, их выгрузкой. А почему бигдата, потому что объёмы данных большие и с ними надо работать. Но на самом деле нам без разницы как это можно назвать, главное кейс исполнить
Json нужен для чтения с последующей логикой обработки. Т.е. сортировать данные, искать по данным внутри мы не будем. Прочитали всю строку, обработали данные и после воспроизвели логику на базе полученных данных. Результат записали в другую таблицу.
K0DiBEN: есть приложение, которое мы ранее опубликовали в AppStore/GooglePlay. Создали игру на базе Unity3D. Хотим интегрировать игру в наше приложение. Как это сделать?
Мы генерит DKIM/SPF записи, указываем их на сервере и вносим соответствующие (теже DKIM/SPF) TXT записи у регистратора. Далее паркуем домен у нас на сервере, прописываем DNS записи у регистратора. Все верно?
Как сгенерировать SPF? По DKIM понял, можно здесь dkimcore.org/tools
С нашего сервера (почтовая очередь) через smtp mailgun.com будут отправлять письма от домена sub.example.ru (support@sub.example.ru) email письма. Нужна помощь в настройки TXT записей, генерации DKIM/SPF и общим рекомендациям по настройки отправки емейл писем.
UserCases
1. Регистрация нового пользователя (вызов метода Reg)
Фронт отправляет POST запрос с данными, которые нужно записать в таблицу Members, сгенерив предварительно UID и повестив его вместе с данными в эту таблицу, а также сделать запись в Redis. В ответ сервер отдает UID
2. Авторизация пользователя (вызов метода Login)
Фронт отправляет запрос c данными для авторизации, сервер идет в таблицу Members, берет данные, в частности uid, генерит новый, заменяет старый в Members, а также обновляет его в Redis. Возвращает данные пользователей вместе с UID
3. Запись прогресса
Фронт отправляет запрос с UID. Сервер проверяет его в Redis, если он валидный, делает запрос в таблицу Members, обновляет соответствующие данные, а также перезаписывает UID и обновляет его в Redis
4. Запрос списка наград
Фронт отправляет UID и CONTEST_ID. Сервер проверяет валидность UID в Redis, если валидный идет в таблицу Rewards и берет все награды для Campaign_ID, а также проверяет какие награды получал пользователь в таблице Members -> Progress.
ЧТО ВИДНО ИЗ КЕЙСОВ
- Практически во всех методах идет обращение в таблицу members
- UID проверяется на валидность до момента обработки основного запроса
- Обновляем UID при POST/PUT/DELETE запросах в таблице Redis/PostgreSQL + TTL в Redis
ВОПРОС, НУЖЕН ЛИ НАМ REDIS И ПОЧЕМУ?