Юра
Там не всегда используются эти данные. Если всем юзера создавать будет много ненужных данных
Юра
Поэтому типо сделано лэйзи
Юра
Не все так просто)
Sanan
Но чисто интуитивно когда я вижу ГЕТ запрос я не ожидаю что там под капотом происходит создание чего-то в базе
верно, не нужно через гет че то создавать, сегодня вы через гет создавать че то будете, а завтра... тут можно подставить все что угодно
Sanan
с другой стороны, если на проекте во всем остальном все ок, и там есть четкие правила и соглашения - можно сделать исключение где в каком то конкретном месте использовать гет для создания, и как то это аргументировать, чтобы не придраться. А то вероятность того, что в будущем решат так еще че то сделать криво-косо, будут смотреть на этот гет.
Юра
Я это называю раскидывать грабли
Юра
Зачем если можно сделать пост или патч или любой другой и забыть про этот вопрос
Sanan
А вообще чем больше об этом думаю - тем больше кажется это нормальной темой.
Допустим есть ютуб. Предположим что до 2010 года для того, что бы грузить видосы надо было регистрировать специальный аккаунт. Но после 2010 бизнес подумал "а пусть у нас все пользаки могут загружать видосы"
Что имеем как программисты.
1) Нужно создать таблицу и сущность для "Студии"
2) При регистрации нового пользователя автоматом создавать "Студию" пользователю
Но что делать если у нас сотни миллионов уже существующих пользаков. Делать всё на фронте (на GET студии возвращать 404 и тогда пусть фронт отправит POST на создание студии) или сразу на GET создавать студию
в описанном кейсе, если уже есть куча юзеров, у которых тоже должна быть "студия" это делается вообще не через запросы с фронта (браузера), а пишется консольная утилита которая в цикле будет прогонять пользователей, у которых нет студии, и создавать им ее. это можно распаралелить, брать в одну пачку например по тысяче юзеров, и параллельно запускать.
Sanan
например крон тыкает или еще что то
Sanan
чтобы в итоге быстрей все сделать
Юра
Ещё такой вариант. Вместо
GET /self/achievements
Сделать
PUT /self/assign-achievements
Который либо вернет уже существующие либо создаст новые и вернёт их
Юра
Сам эндпоинт уже намекает как бы что там что-то происходит и это хорошо
Sanan
тут еще можно ин мемори что то прикрепить, чтобы айди уже созданных туда писалось, и при паралельных запросах из базы их уже не дергать. можно через редис с крикручиванием туда записи на диск, чтобы в случае перезапуска все подтянулось
Юра
например крон тыкает или еще что то
Там не очень получится потому что не у всех юзеров это нужно
Sanan
ну надо определить кому надо
Юра
Это типо лэйзи функционал
Юра
А вот надо тому кто запросил с фронта)
Юра
Такая бизнес логика была заапрувлена
Юра
У меня тоже была первая мысль по крону или событию какому-то, но не подходит
Sanan
ну не совсем так делать лучше, имею ввиду чтобы при запросе с фронта сразу идти создавать. лучше тык клиента "а нужна ли тебе студия?" писалась в какую то очередь, а очередь потом где то консюмером обрабатывалась и пачками создавалось, а не так чтобы на каждый запрос создавать. чтобы не перегружать кучей запросов, а сократить количество соединений и запросов за один раз
Sanan
и сказать там еще юзеру типа иди кофе попей, мы задачу поставили сделать тебе студию, скоро будет готово
Sanan
типа нахера юзеру прям в моменте сразу эту студию получать? он ей собирается пользоваться долго и в перспективе, поэтому подождать создания какое то время, думаю не страшно
Юра
Что за студия
Sanan
ну это из примера
Sanan
просто некий функционал условно
Юра
Там не студия. Представь что есть страница с ачивками. Пользователь заходит (далеко не каждый) и ему показываются ачивки. Ачивки занимают место в БД поэтому всем их делать заранее не вариант
Sanan
там был выше пример со студией ютуба
Юра
Ну со студией может да
Юра
А тут нужно сразу показать
Sanan
типа эти ачивки существуют не со старта проекта а их потом ввели, и уже есть пользаки которым тоже надо?
Sanan
условно
Юра
Ну типо того
Юра
Там немного не так но подробнее не могу )
Sanan
ну так все равно. таким юзерам писать, мол иди погуляй, мы потом твои ачивки загрузим
Sanan
либо жестко всем эти ачивки сделать при обновлении прода когда эта фича выкатывается, чтобы у всех уже она была даже у старых
Юра
Юзера миллион
Юра
Или больше
Sanan
вариант с жестким пушем ачивок лушче при выкатывании фичи
Юра
Всем ачивки заранее раздавать слишком расточительно строчки зрения бд и нагрузки
Sanan
ну надо сделать так, чтобы было менее расточительно)
Юра
Так как только допустим десять процентов их реально получат
Nikolay
Так как только допустим десять процентов их реально получат
Так это только для старых пользователей костыль?
Sanan
капец есть же сотни игр где функционал вводят, и там тоже миллионы юзеров, им всем в моменте выкатки фичи уже все отображается как надо
Sanan
они же как то пушат бд свою
Sanan
это в геймдеве ваще частая практика насколько я знаю
Nikolay
Если это только для старых, то делается миграция/одноразовая команда и все
Sanan
Если это только для старых, то делается миграция/одноразовая команда и все
ну это тоже, кстати, миграции
Sanan
тоже как вариант
Михаил
в описанном кейсе, если уже есть куча юзеров, у которых тоже должна быть "студия" это делается вообще не через запросы с фронта (браузера), а пишется консольная утилита которая в цикле будет прогонять пользователей, у которых нет студии, и создавать им ее. это можно распаралелить, брать в одну пачку например по тысяче юзеров, и параллельно запускать.
Ну я бы даже сказал что это делается одним запросом, но нет - то что ты сказал это очень плохо. Уридж правильно говорит про lazy
Sanan
Ну я бы даже сказал что это делается одним запросом, но нет - то что ты сказал это очень плохо. Уридж правильно говорит про lazy
круто говорить что то не так никак это не аргументируя) ситуации разные бывают, где то может быть и норм, где то плохо и тд
Михаил
Юзера миллион
Да всё вы правильно делаете. Помимо продакшен бд, у вас будет ещё и stage и бэкапы.
Не комментаторам тут менеджить эти гигабайты данных. Не комментаторам тут пытаться ужиться с разбухшими индексами. Делай так, как оптимально для вашего случая
Самое забавное, будь у вас rpc - никто бы и ухом не повёл
Михаил
Михаил
Там не студия. Представь что есть страница с ачивками. Пользователь заходит (далеко не каждый) и ему показываются ачивки. Ачивки занимают место в БД поэтому всем их делать заранее не вариант
Слушай а вообще нужно разделять сущности и персистент
Сущность ачивки - вещь кодовая. То есть ты где-то в коде уже назвал эти ачивки, добавил триггеры, условия. А запись в бд - просто персистент. (user_id, achievement_key, created_at)
Соответственно ты можешь возвращать пользователю статичные данные (просто массив ачивок) и обогощать их данными из бд по achievement_key (добавлять допустим дату прохождения или процент заполнения)
Разве не?
Михаил
Тогда если у пользователя нет ачивок в бд то ты просто возвращаешь статичные данные
А если есть то вот этими некоторыми данными обоготишь статичный view
Павел
Ну я бы даже сказал что это делается одним запросом, но нет - то что ты сказал это очень плохо. Уридж правильно говорит про lazy
@zim_it А вы Уридж или Юрий ?)) У меня чет даже мысли не было про Уриджа, а дейсвтительно... ))
Михаил
Там не студия. Представь что есть страница с ачивками. Пользователь заходит (далеко не каждый) и ему показываются ачивки. Ачивки занимают место в БД поэтому всем их делать заранее не вариант
или сделай так чтоб названия и описания ачивок были в одной таблице (achievements) а данные о прохождения ачивок были в таблице (user_achievements) и пусть user_achievements ссылается на achievements
А дальше просто делай
SELECT * FROM achievements a LEFT JOIN user_achievements ua ON ... WHERE ua.user_id = $1
И даже если у пользака нет ачивок - то вернётся массив пустых ачивок
The Ant
Вроде вопрос про гет запрос был. А уже на советовали как делать 😄
Тут просто хз. Можно и урл просто дёрнуть гет запросом. Для создания ачивки. Чтобы не мучаться с cors. Это ведь настоящая проблема для устройств. Если не знаешь откуда будет запрос это нормальное решение.
The Ant
Мучался одно время с sendbeacon, ппц гемор с корс. Всякие фетчи с keep-alive тоже не всегда и везде срабатывают. И корс настроить под них та ещё задница. + К этому лишний options запрос. Если есть сессия тоже какая-то хрень там.
Крч как обычно, зависит от ситуации. М.б. в вашем случае проще гет, и пофиг что там лучших рекомендациях рестфул
Михаил
Вроде вопрос про гет запрос был. А уже на советовали как делать 😄
Тут просто хз. Можно и урл просто дёрнуть гет запросом. Для создания ачивки. Чтобы не мучаться с cors. Это ведь настоящая проблема для устройств. Если не знаешь откуда будет запрос это нормальное решение.
так да, мы ответили про get запрос. Просто в довесок накинули как это ещё и окольными путями можно решить
хотя самого бесит, когда задаю вопрос про А, а отвечают "а зачем тебе А, а не лучше ли сделать Б")
Vite4eg
Приветствую. Вот такой вопрос: у меня есть выгрузка сделки в 1С. За один раз пишется несколько записей в лог. За другой раз по этой сделке тоже пишется несколько записей. А как потом такие записи лога группироавть?
Nikolay
Vite4eg
Генерировать на страте какой-то уникальный id, и прокидывать его в payload какждой записи?
Vite4eg
Ну чтоб потом понимать, по какой выгрузке что-то пошло не так
Nikolay
Ну чтоб потом понимать, по какой выгрузке что-то пошло не так
Идентификатор сделки добавить или другую инфу
Vite4eg
Если сделка за день несколько раз выгружалась - то просто id ничего не даст
Михаил
Приветствую. Вот такой вопрос: у меня есть выгрузка сделки в 1С. За один раз пишется несколько записей в лог. За другой раз по этой сделке тоже пишется несколько записей. А как потом такие записи лога группироавть?
Сделай trace id
Если выгрузка идёт в рамках процесса то просто генерируй trace id на основе id процесса
Михаил
Вадим
привет!
Есть класс Response с полем array<Place> $result
Есть json массив мест который надо десериализовать.
Можно ли как-то сказать сериализатору чтобы он положил массив мест в $result? Как SerializedPath только наоборот
Роман
В конструкторе или в свойстве или сеттере в докблоке укажи
Place[]
CaptchaBot
Warning: This is the fifth time that @Shirley_Joyneryn75 has tried to join the group and failed to solve the captcha. "User" was banned. To let him/her enter again, an Admin has to manually remove the restrictions of this "user".
Сергей
Привет, как правильно валидировать и отдавать ошибки в Vue из REST? Данные принимаются через #[MapRequestPayload] в DTO, потом в UseCase обрабатываются.
The Ant
Привет, как правильно валидировать и отдавать ошибки в Vue из REST? Данные принимаются через #[MapRequestPayload] в DTO, потом в UseCase обрабатываются.
Мап реквест валидирует входящие данные, возвращает стандартный ответ валидатора. Изучи это.
Из юзкейса бросаешь исключения, которые ловишь в контроллере и превращаешь их в хттп исключения. Которые симфони ловит и точно также стандартно обрабатывает. Почитай в документации про обработчик ошибок.
В вуе смотря как делаешь запросы. Вариантов масса. Но самый распространенный это с помощью аксиос. в блоке .catch обрабатываешь ошибку. Через портянку ифов можно резолвить тип ошибки.
Как вариант ещё повесить интерцептор в аксиосе, для стандартной обработки 500, 401, 403 и т.д., чтобы показать соответствующий экран.
Сергей
Спасибо!
Denis
Коллеги, может кто подскажет по Symfony 7 + Messanger (rabbitmq)
https://stackoverflow.com/questions/79514207/how-do-i-split-queues-in-symfony-messenger
Никак не могу понять почему очереди/поток не разделяются
Павел
Коллеги, может кто подскажет по Symfony 7 + Messanger (rabbitmq)
https://stackoverflow.com/questions/79514207/how-do-i-split-queues-in-symfony-messenger
Никак не могу понять почему очереди/поток не разделяются
Настройте очереди (у вас только эксченжеры в конфиге) ещё +дропните эксченжеры и очереди в кролике. Возможно пока тестировали авто настройка роутинга настроилась криво
Павел
Ещё можете тип эксчендера указать direct, по умолчанию fanout стоит
Denis
MATHEU
Has anyone managed to use tailwindcss v3 + webpack?
Михаил
someone maybe yes
Михаил
and naturally there are those who don’t