Павел
Хувость кода отражается проблемами которые он приносит или принесет, остальное болтология
The Ant
Как все сложно то...
Павел
Как все сложно то...
Меньше заморачивайся, живется проще) думаешь что пишешь гавно? Но оно же работает, может не такое уж и гавно))
Павел
Решение хорошее или плохое выражается только конкретным профитом и проблемами
Павел
А не абстрактным "хороший и плохой код"
The Ant
Да все по пидорски как-то и переусложнено. Ещё эти решения сраный принимать, и жить с ними
Павел
Да все по пидорски как-то и переусложнено. Ещё эти решения сраный принимать, и жить с ними
Сделай не попидарски полегче)
The Ant
Дык вот вопрос как. Мне по сути нужен 1 сервис, который даст ответ какой щас язык у юзера. И какой дефолтный. И это как-то невероятно сложно решить с миллиардом ограничений
The Ant
Юзать риквест контекст и мозги не канифолить, чо думать. Фрейм юзает и ничо, я чем хуже? Тем более умнее все равно никто ничего не предложил, да? 😄
Павел
Юзать риквест контекст и мозги не канифолить, чо думать. Фрейм юзает и ничо, я чем хуже? Тем более умнее все равно никто ничего не предложил, да? 😄
Ну реквест я бы не юзал в том виде везде, а под своей оберткой, с 2 методами, как я выше написал - это маленький кусок гавнеца и похер )
Основная проблема тут не сколько сам реквест, сколько прокидывание такой гибкой зависимости через конструктор.
Например у тебя будет сервис письма разослать пользователям а у пользователей разный язык, и ты в жопке.
Но опять же просто будешь юзать уже не этот сервис а другой подход
The Ant
Ну реквест я бы не юзал в том виде везде, а под своей оберткой, с 2 методами, как я выше написал - это маленький кусок гавнеца и похер )
Основная проблема тут не сколько сам реквест, сколько прокидывание такой гибкой зависимости через конструктор.
Например у тебя будет сервис письма разослать пользователям а у пользователей разный язык, и ты в жопке.
Но опять же просто будешь юзать уже не этот сервис а другой подход
Тоже верно... Предлагаешь репу прокидывать с языками, и также аргументом в каждом контроллере локаль?
Павел
Павел
Я про твой самый первый вариант, только его подрехтовать
The Ant
Ну а какие ещё варианты, если брать настройки юзера из бд? Остаётся только по месту из этой бд доставать и подсовывать
Павел
Опять же, у вас много локалей? Или 4 и ты там что то ишешь? Может просто статик маппинг без БД?
Павел
Павел
У тебя же вроде по урлу
The Ant
Опять же, у вас много локалей? Или 4 и ты там что то ишешь? Может просто статик маппинг без БД?
Пока 4 😄 но будет больше, штук 7-8. При том что это не 1 сайт. На разных по разному, + фронт должен это учитывать, т.е. иметь ендпоинт для загрузки меню
The Ant
Урл, настройки мемберв, заголовок акцепт лангвейдж, и ещё какой-то заголовок, не помню, куки. Сессий нет )
Павел
Ну смотри, имхо, если не лень, лучше конечно в конкретные сервисы локаль передавать через метод, так проще потом не влететь. Потому что можешь вызывать сервисы одним инстаном с разными локалями
Павел
Если нет высокой слоистости, и это не проблема, то пробрасывай локаль так. Сделай дто, с локалью и дефолтной локалью и везде ее используй
Павел
А снаружи уже пофиг, свой сервис которых ходит куда угодно, или аргументрезолвер. У тебя будут чистые хэндлеры/фетчеры работающие с локалью, но не зависящие от гавнеца определения локали
Павел
Захотел по урлу, захотел по юзеру, захотел по реквест контексту - твои сервисы об этом не знаю
The Ant
Ну вот щас так, но меня напрягает этот аргумент почти везде )
Павел
Ну вот щас так, но меня напрягает этот аргумент почти везде )
Ну смотри, он либо как аргумент метода, либо как аргумент конструктора :) Ну не шибко разница большая)
Павел
Ну вот щас так, но меня напрягает этот аргумент почти везде )
Короче норм вариант, по крайней мере со стороны зависимостей
The Ant
Если как конструктор, это уже стейтфул
The Ant
Как же хорошо работать в конторе формошлепом, за тебя все придумают... Остаётся тока код набрать 😄
Павел
Как же хорошо работать в конторе формошлепом, за тебя все придумают... Остаётся тока код набрать 😄
Ну у них свои проблемы, шлепать по 5 проектов в месяц на потоке клацая по клавишам 8 часов в день)
The Ant
И люди ещё не хотят делится опытом :( или нет подобного опыта ни у кого? 😄
Юра
Поднять пять микросервисов с ИИ которые будут отдавать вероятность локали, и брать самую вероятную.
Павел
Поднять пять микросервисов с ИИ которые будут отдавать вероятность локали, и брать самую вероятную.
Так через метод, резолвер или конструктор? С ИИ все понятно, все легко
Юра
Ещё не забываем про то что в симфе можно определить сервис какой-то чтобы он биндился по типу и названию переменной и сделать этому сервису фабрику
Юра
И можно игджектить просто string $userLocale, который вернёт фабрика которая может зависеть там от чего хочет уже
The Ant
Не, ну это точно лишнее. Надо избегать такого
Юра
Хз. Я так делал с другими значениями. Работает
The Ant
Понятно что работает. Надо делать всё проще. Чем проще тем лучше.
Юра
А что сложного то. Не сложнее аргумент резолвера какого-то или просто сервиса. Только с сервисом нужно таскать сервис и дергать метод
The Ant
С этими биндингами потом устанешь разгребать где чо, когда их наберется целая куча
Павел
И можно игджектить просто string $userLocale, который вернёт фабрика которая может зависеть там от чего хочет уже
Основная проблема неймбиндига-очень неявная зависимость которую надо держать в уме и тяжело рефачить, искать использование. Ну только по названию в тексте искать
Павел
Но мейджик, как вариант, интеренсый
Юра
Ну поиск согласен сложнее чем кликнуть по методу
Юра
А сам биндинг все равно явно определен, с этим особой проблемы нет
Юра
Можно вынести в отдельный конфиг типо биндинги
Юра
Если их много. Но их редко бывает много
The Ant
Кроме этого есть ещё интерфейсы, с несколькими реализациями, которые биндчтся также. Крч путаница потом ппц. Я стараюсь это говно не юзать )
Юра
Тогда только ИИ )
Юра
На питончике накидать
Павел
Кроме этого есть ещё интерфейсы, с несколькими реализациями, которые биндчтся также. Крч путаница потом ппц. Я стараюсь это говно не юзать )
Ну тут палки на 2 концах. Логгеры, кэши - удобно по автобингдунгу, опять же прокинуть енв, базовый путь проекта через стринг - тоже удобно
The Ant
Юра
А ещё вариант
Юра
$_GLOBAL
Юра
))
Павел
Просто был опыт небольшой делали 2 UrlGenerator сервиса с разными base url как раз конфиг через di , но 1 физический класс. Биндились по имени.
Ну вот путаница была:
1) рефачить
2) Понять где какой вызывается, так как по фактту это 1 класс.
Павел
А как сделать удобнее - тоже хз. Делать 2 класса выглядит бредова, кидать фабрику - и из нее создавать разными методами - чет тоже какой то болерплейт
Юра
Я так делал два конекта к редису
Юра
Тоже по имени
Юра
До рефакторинга не дошло поэтому не могу сказать
The Ant
Просто был опыт небольшой делали 2 UrlGenerator сервиса с разными base url как раз конфиг через di , но 1 физический класс. Биндились по имени.
Ну вот путаница была:
1) рефачить
2) Понять где какой вызывается, так как по фактту это 1 класс.
Есть такое 😄 стратегия хз. 1 интерфейс, разные реализации. Биндишь на переменную
Алексей
Привет чат!
Задача: получить данные о сущностях Х, которая состоит из Y, которая тоже состоит из Z(Х->Y->Z). Есть rest api:
1 GET - example.com/resource/X?limit=10 - получить список id сущностей X
2 GET - example.com/resource/X/id_x - получать данные по конкретной сущности Х.
3 GET - example.com/resource/X/id_x/Y - получать список id сущностей Y, привязанные к сущности Х
4 GET - example.com/resource/X/id_x/Y/id_y - получать данные по конкретной сущности Y.
5 GET - example.com/resource/X/id_x/Y/id_y/Z - получать список id сущностей Z, которые привязанные к Y, которая привязана к сущности Х
6 GET - example.com/resource/X/id_x/Y/id_y/Z/id_z - получать данные по конкретной сущности Z.
отдать древовидную структуру Х сущностей.
Понятно что нужно сделать асинхроно, использую symfony/messenger и rabbitmq. и вот тут возникает вопрос как передавать полученные данные из одного типа consumer'a в другой(я создал несколько типов очередей - для каждой сущности)? придется делать несколько MessageBus'ов? или можно как-то проще?
The Ant
Привет чат!
Задача: получить данные о сущностях Х, которая состоит из Y, которая тоже состоит из Z(Х->Y->Z). Есть rest api:
1 GET - example.com/resource/X?limit=10 - получить список id сущностей X
2 GET - example.com/resource/X/id_x - получать данные по конкретной сущности Х.
3 GET - example.com/resource/X/id_x/Y - получать список id сущностей Y, привязанные к сущности Х
4 GET - example.com/resource/X/id_x/Y/id_y - получать данные по конкретной сущности Y.
5 GET - example.com/resource/X/id_x/Y/id_y/Z - получать список id сущностей Z, которые привязанные к Y, которая привязана к сущности Х
6 GET - example.com/resource/X/id_x/Y/id_y/Z/id_z - получать данные по конкретной сущности Z.
отдать древовидную структуру Х сущностей.
Понятно что нужно сделать асинхроно, использую symfony/messenger и rabbitmq. и вот тут возникает вопрос как передавать полученные данные из одного типа consumer'a в другой(я создал несколько типов очередей - для каждой сущности)? придется делать несколько MessageBus'ов? или можно как-то проще?
можно проще, делая это синхронно 🤷♂️
тебе асинк тут никак не поможет, потому что все равно получение сущностей будет последовательным
Юра
Гет запросы через очереди? Или я чего не понял
Юра
Выглядит так будто тебе нужно вместо рест graphql
Павел
Если проблема именно в скорости, и все это виснет и нужен какой то долгособирающийсся отчет, то да можно асинк, но с гетом и апи вообще не связано
Юра
Да просто делай пост запрос на создание так сказать отчёта, возвращай айди задачи и пингуй её статус например
Алексей
Выглядит так будто тебе нужно вместо рест graphql
это стороннее апи и оно существует, я его изменить не могу.
The Ant
Если проблема именно в скорости, и все это виснет и нужен какой то долгособирающийсся отчет, то да можно асинк, но с гетом и апи вообще не связано
асинк не поможет никак, потому что каждая сущность зависит от предыдущей )
можно все в одном делать
Юра
Единственное что сразу предусмотреть кеш
Юра
С каким-нибудь настраиваемым ttl
Алексей
можно проще, делая это синхронно 🤷♂️
тебе асинк тут никак не поможет, потому что все равно получение сущностей будет последовательным
синхронно не могу, очень долго отвечает.
Юра
синхронно не могу, очень долго отвечает.
Так сделай свой запрос асинхронный а запросы к их апи синхронно
Алексей
асинк не поможет никак, потому что каждая сущность зависит от предыдущей )
можно все в одном делать
а как это можно ускорить? распараллелить хотелось бы
Юра
Как распаралелить если задача зависит от предыдущей?
Павел
это стороннее апи и оно существует, я его изменить не могу.
Можно делать 1 очередь под эту задачу и несколько консюмеров и несколько месседжей
Павел
Я так понял надо собрать какие то данные с внешнего апи начиная с рутовой сущности в и вглубь дерева
The Ant
а как это можно ускорить? распараллелить хотелось бы
Юрий вон подсказал. Внутри своего воркера делаешь запрос газлом, параллельно 10 штук получая сущности, сначала Х, потом Y, и последним Z. Затем всё мерджишь
Павел