Comments by "" (@moodcraft8198) on "Архитектура БД сервиса users | Django Rest | Михаил Омельченко" video.

  1. вы разделяете кастомера и геймдев юзера, зачем? а если геймдев захочет купить игру как кастомер ему еще один аккаунт заводить? зачем делать 2 аккаунта на одном проекте? не проще ли сделать булевое поле is_developer с False по умолчанию? тем самым покроется кейс наличия двух непонятно зачем регистраций и разделения кастомера и девелопера. и у девелопера останется пространство стать кастомером с этого же аккаунта
    1
  2. "если плохое может случиться, то оно случиться" слушайте, с таким аргументом конечно трудно спорить, но если вы так рассуждаете, то если случится так что злоумышленник получит секретный ключ которым вы парсите токены и достаете пермишены, то он нарисует вам любые плохие события, но давайте будем честны, таких "плохих" событий может быть масса и в таком контексте у вас миллион уязвимостей предлагаю подключать криптографа который настроит цепочку шифрования ключей .env файла, а то плохое произойдет и будет ай яй яй предлагаю пойти дальше. чтобы злоумышленник случайно не получил доступы к докер образам и на подкорректировал код, предлагаю настроить тройную обфускацию исходного кода с компиляцией байткода питона в бинарный код, чтобы точно никому не оставить шансов
    1
  3. если GameDev юзер может не быть владельцем компании а лишь участником, зачем автоматически создават ему компанию и требовать с него проходить комплаенс?
    1
  4. GameDev это и юзер и компания но при этом есть отдельная таблица Company. всё мировое джанго комьюнити щас пробило голову от фейспалмов
    1
  5. 22:55 - "тут я еще сам не знаю че делать" дальше можно не продолжать. проект обречен на "костыль на костыле" вот как должно быть - берем и используем обычного джанговского юзера (так уж и быть будем наследоваться от него) - суперюзеру задаем is_superuser (внезапно) - все наследуются от BaseUser что позволяет использовать стандартные джанговские пермишены и не собирать зоопарк кастомных совершенно не нужных пермишенов все, вопрос пермишенов закрыт
    1
  6. здесь очень сильно попахивает multi tenant архитектурой о которой помоему никто не сказал ни слова, хотя без нее, ваша база со временем положит весь сервак по таймауту
    1
  7. Госпади, какой кошмар, 15 минута и человек сам говорит что ест нарушение логики и будет сложно разобраться но давайте придерживаться этого. зачем? вы сами себе стреляете в ногу из двухстволки и в добавок стреляете в юзеров с базуки в упор. уже на этом этапе проект в корне не верен. боюсь представить что будет дальше
    1
  8. до этого момента я думал что слово "архитектура" это не пустой звук
    1
  9. Один разработчик не может одновременно принимать участие в разработке игр в Rockstar и Rockstart north. Просто нельзя и все. потому что потому.
    1
  10. - почему зарегистирировать новый профиль в качестве компании это проще чем перейти на поддомен developer.* ? - почему создать еще один профиль с вероятно, такими же данными юзера это лучше чем иметь один профиль на все случаи кроме суперюзера? есть понимаение что это жесточайшее нарушение нормализации таблиц? кто вам писал это тз? - зачем нужно автоматические создание компании для девелоперов? почему нет пространства для девелоперов без создания компании? в том же стиме steamworks api доступно любому девелоперу без какого либо прохождения комплаенса. - почему нельзя сделать возможность создания N компаний на одного девелопера? если один и тот же девелопер хочет иметь N компаний с разделениями игр по любому признаку, ему нужно иметь N девелоперских аккаунтов и проходить N комплаенсов? вы понимаете что это абсолютно useless ?
    1
  11. то есть если у вас OneToOne от BaseUser к трем возможным моделям, это значит, что в случае регистрации в трех ролях, вы будете дублировать данные юзера в 3 таблицы? - какое функциональное назначение такой жесточайшей денормализации? - какую роль тогда играю пермишены если у вас такое строгое разделение юзеров?
    1