WEBM likes and dislikes

[bushig]

Should be endpoint GET /check/{md5}/like and /check/{md5}/dislike. Store likes as simple counter. Track person who liked by IP address. On frontend store info in cookies.

[Tehtehteh]

Предлагаю хранить юзеров как MD5 (user_agent + IP), я уже это заимплементил, но не оформил пулл реквест. Как тебе идея?

[bushig]

Не думаю что имеет смысл держать информацию о пользователях в бд, так как она может быстро забиться. Я хотел хранить в таблице WEBM поля с количеством лайков и дизлайков, а отслеживать того кто уже лайкнул WEBM через Redis, которую можно чистить раз в несколько месяцев. Я кстати не уверен, что стоит хранить user_agent, ведь версия браузера может измениться. Если что потом можно будет ввести регистрацию (генерация пасскода), чтобы отслеживать просмотренные пользователем вебм, его лайки и т.д.

[Tehtehteh]

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

[bushig]

Проблема в том что у многих пользователей динамические адреса + user agent меняется даже при обновлении браузера, поэтому нет никакого смысла держать базу пользователей, если пользователь потом не может залогиниться. Тут остается либо делать комментарии анонимными, либо прикручивать регистрацию. Моя почта: azerot966@gmail.com

[Tehtehteh]

Конкретно id пользователя будет использоваться как один из параметров составного первичного ключа по лайкам. Чтоб нельзя было релоднуть страницу и накликать ещё лайков.

[bushig]

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

[Tehtehteh]

Немного не согласен с логикой. Ты хочешь использовать редис как ещё одну БД для количества лайков, а, по-моему, его стоит использовать исключительно как кеш. Предлагаю продекорировать on_get метод вьюхи, отвечающую за инфу по вебмкам. Пытаемся получить данные из кеша, если их нету - делаем запрос в БД. Если делаем запрос в БД - записываем в кеш.

[bushig]

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

[Tehtehteh]

Всё правильно. Очистил кеш - сохранил как числовое поле. Далее те же юзеры могут опять накрутить лайки. Поэтому я и предлагаю их хранить как отдельную сущность с уникальным ключем по юзеру. При том, неизвестно что может случится с редисом, а в базу записал, закомитил и спокоен. Насчёт просмотров - как вариант, писать в редис с expiration time. Прошло 10 минут - можно снова инкрементировать view count. Как одна из идей.

[bushig]

Не составляет никакого труда подделать user agent или сменить IP, так что от накруток это не поможет. Поэтому информация о том с какого айпи лайкнули не важна. К тому же редис сохраняет дамп на диск с некоторой периодичностью, так что все данные врятли пропадут. Думаю пока стоит допилить то что есть, провести тестирование и собрать отзывы и пожелания пользователей, а там уже решать как реализовывать лайки/комментарии.