search

Palus-Somni-Team / shikicinema-server

2 stars 0 forks source link

Requests API #94

Closed Smarthard closed 3 months ago

Smarthard commented 1 year ago

Часть ониона https://github.com/Palus-Somni-Team/shikicinema-server/issues/1

Клиентское API:

Админское API

BasicEC commented 1 year ago

@Smarthard Есть предложение. Это ведь реквесты на изменение видосов. Может поместим их по пути /api/v2/videos/requests? А то появяться потом еще какие-нибудь реквесты

Smarthard commented 1 year ago

@Smarthard Есть предложение. Это ведь реквесты на изменение видосов. Может поместим их по пути /api/v2/videos/requests? А то появяться потом еще какие-нибудь реквесты

Это запросы не только на изменение видосов, зачем их размазывать по всем контроллерам?

BasicEC commented 1 year ago

Разделяй и властвуй:) dto будут строгих типов, меньше условий в сервисе будет по тому как эти запросы обрабатывать. А что еще можно попросить изменить? Мы вроде дополнительно только авторов храним, но не уверен что кто-то отдельно будет просить их менять.

Smarthard commented 1 year ago

А что еще можно попросить изменить?

Да хз, что угодно на самом деле: смержить нескольких авторов например, пожаловаться на пользователя, токены отозвать

Smarthard commented 1 year ago

Идея была в том, чтобы все запросы лежали в одном месте и можно было отобразить их нужному пользователю

BasicEC commented 1 year ago

Попахивает супер контроллеров, как-то не по ООПшному

Smarthard commented 1 year ago

Тогда мб наоборот, не videos/requests, а requests/videos? Чтобы хотя бы номинально общая связь была. Ну и в базе я бы это всё равно одной таблицей хранил, как мне кажется, чтобы сервис унифицировать.

Smarthard commented 1 year ago

Попахивает супер контроллеров, как-то не по ООПшному

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

Smarthard commented 1 year ago

Возможно стоит завтра собраться и архитектуру подробнее продумать?

BasicEC commented 1 year ago

@Smarthard обновил issue:

Smarthard commented 1 year ago

@BasicEC похоже на то, что надо 👍

Smarthard commented 1 year ago

Реализовано частично, поэтому переоткрываю

BasicEC commented 7 months ago

@Smarthard Мы дошли до самого сложного. Операция approve. По ней есть вопросы.

  1. Есть запрос на удаление видео. Если мы его удаляем, то сейчас вместе с ним каскадно удалится и запрос и кажется такого быть не должно. Варианты вижу такие: 1.1 Убрать foreign key, удалять видео из бд. Запрос при этом в бд останется, но ссылка на видео протухнет. В админке мы больше не увидим что это бы за видео. 1.2 Сделать колонку is_deleted для видео. Видео остается в бд и не рушит связи, но пользователю не показывается. В админке можно посмотреть информацию о видео которое удалили. Когда/если захотим удалить видео, то будем удалять вместе с запросом. К тому моменту пользователь уже должен будет получить обновление статуса и забыть обо всем. 1.3 Совместить пункт 1 и 2. Запросы с нами навсегда, а видео умеем и прятать от пользователя и удалять.
  2. Что делать с другими запросами относящимися к тому же видео? Хотим ли мы какой-нибудь авто реджект для запросов которые стали неактуальны (поля в запросе стали совпадать с полями видео)? Или пусть админы сами с этим разбираются.
Smarthard commented 7 months ago

@BasicEC по первому пункту, тут всё просто думаю: soft-delete (т.е. то, что ты описал в пункте 1.2). Наверное, у typeorm или nestjs даже что-то такое готовое есть.

По второму: мб сделать отдельное boolean поле а-ля closeRelated, которое по-дефолту false? А на фронте можно будет остальное уже на контент-админов оставить.

Smarthard commented 7 months ago

soft-delete для typeorm: https://orkhan.gitbook.io/typeorm/docs/decorator-reference#deletedatecolumn