• Как объединить 2 записи в одну по признаку?

    @Vitsliputsli
    Объединить можно с помощью group by. Но нужно определиться, что подразумевается под first и second. По какому признаку вы в employee_id_first поместили 1, а в employee_id_second 2?
  • Какие существуют решения для синхронизации БД на фронте и бэкенде?

    @Vitsliputsli
    Надим Закиров, то что вы хотите невозможно, все валидации должны быть на беке, т.к. фронту доверять нельзя, поэтому в любом случае придется делать только там. Для бека верно, это ORM, бывают совершенно разные, начиная от ActiveRecord заканчивая Doctrine, и почти как вы хотели, почти все автоматически. Но такая автоматическая работа слабо ориентирована на тонкую настройку, а база штука капризная, поэтому на высоких нагрузках - не вариант.
  • Блокировка PHP flock создает последовательную очередь?

    @Vitsliputsli
    Я бы на это не расчитывал, все-таки это просто блокировка, а не очередь, иначе бы это явно прописали в доке. Я не очень представляю, как можно просто и легко организовать очередь для разных процессов, а здесь задачи явно такой не было, поэтому вряд ли она есть и блокировку возьмет тот, кто первый ее проверит после снятия, т.е. любой.
  • Как передать на бекенд требования к API?

    @Vitsliputsli
    Антон Бреславский, ни проблем, ни негатива. Лишь описание ситуаций, принимать решения вам, нести за них ответственность тоже.
    Как опять от согласования перешли к "Но если у меня на картинке (окей, экране интерфейса) список пользователей, я не могу спроектировать к этой области API вместе с DTO (модель, схема данных)?" я не понял.
    И если ничего не смущает в фразе: "бизнес логика на беке, сущности в первую очередь создаются там, их взаимодействие тоже, отображение вторично, но можете сделать наоборот", то вам с этим разбираться.
    У меня новых аргументов не будет.
  • Как передать на бекенд требования к API?

    @Vitsliputsli
    Антон Бреславский,
    Вся суть вопроса только в этом, не заменить бэк, не отнять у них работу, а оперативно согласовывать API

    В 4ый раз, в согласовании ничего плохого нет.

    Но если у меня на картинке (окей, экране интерфейса) список пользователей, я не могу спроектировать к этой области API вместе с DTO (модель, схема данных)?

    Можете. 2ой раз, бизнес логика на беке, сущности в первую очередь создаются там, их взаимодействие тоже, отображение вторично, но можете сделать наоборот.

    Это ваша личная оценка, у меня это был как вопрос
    "Получает бек должен хорошо разбираться в дизайне, понимать как работает приложение и т.д. Верно?"
    Поэтому оценка, что бекенд не может, ваш вывод.

    Не вопрос, моя оценка. Но поверьте, лучше бы подразумевалось "бекенд не может", иначе, это полная жесть.
  • Как передать на бекенд требования к API?

    @Vitsliputsli
    Антон Бреславский,
    у меня где-то написано про такую позицию? Если описание DTO на фронтенл для API вызывает такую реакцию, то у бекенд разработчика проблемы с самооценкой наверное.


    я вот про этот комментарий на ответ AgentSmith:
    То есть в Вашем случае, мы должны ставить задачи беку и прикладывать к ним картинки? По этим картинкам они уже создают API? Фронты пока сидят и ждут когда бэк что-то уже сделает? Получает бек должен хорошо разбираться в дизайне, понимать как работает приложение и т.д. Верно?

    Что api создаются по картинкам, и если их отдать беку, то что они могут хорошего сделать, если не понимают как работает приложение, т.е. картинки. Только не говорите, что это AgentSmith придумал, что api создаются по картинкам. Вообще, эпичный комментарий, ничем не хуже того, что я про базу писал в ответе.

    И какой, нафиг, DTO, если по вашему мировозрению вы его из картинок должны составлять?

    Хотя, то что на ходу переобуваетесь, значит все что мы тут пишем не прошло даром, и вы что-то начали понимать, вон уже и DTO вспомнили.

    В качестве вывода, в Вашем случае фронт все таки не могут предлагать контракт взаимодействия с беком путем написания его в Swagger со последующим обсуждением и правками с бэком?

    Неа, раза 3 уже написал, что я не про это говорю, так как проблема не в этом.
  • Как передать на бекенд требования к API?

    @Vitsliputsli
    Антон Бреславский, да ничего удобного, просто отметил, на тот случай, если не правильно трактовал фразы, но раз спорите не с ними - значит можете вычеркнуть "скорее всего".
    Разработка API связана с проектированием передачи сущностей и контроля их взаимодействия. Так как бизнес-логика находится на беке, то создаются эти сущности в первую очередь на беке, в какие сущности они будут переданы на фронте и как отображены - вопрос вторичный. Поэтому проектирование API без бека - это мягко говоря странно. А то, что кто-то не знает, что такое mvc, это печально, но к делу не относится.
    И вы зря так про интерфейсы, "HTTP, сокеты ли даже командная строка" - это не "всего лишь интерфейсы", это разные архитектурные подходы, воплощающие разное взаимодействие, поэтому чаще всего они будут использованы для разной бизнес-логики. Да, есть такой момент, когда при невозможности соединиться по ws используют костыль - sse или long-polling, но это частный случай.
    Просто подумайте:
    http - клиент-серверные заросы в сторону сервера, подразумевающее обработку разными процессами, как правило независимые.
    cli - работа app по параметрам или интерактивное, подразумевающее запросы от сервера.
    ws - клиент-серверное взаимодействие в обе стороны.
    Т.е. в зависимости от архитектурных требований, будет использоваться разный подход.
    Почему заранее нельзя договориться с фронтом как данные будут бегать туда-обратно и начать работу параллельно?

    Ну я же ответил на это в комментариях к соседнему ответу. Можно, а то и нужно, но если вы к этому подойдете с позиции аля "бекенд не знает ничего о приложении" - будет хреново.
  • Как передать на бекенд требования к API?

    @Vitsliputsli
    Антон Бреславский, звучит неплохо, но на практике это может значить что угодно. От реального согласования API, до требования пришли мне по одному запросу несвязанные сущности, отправь почту еще по одному условию и свари кофе, но можешь как пожелаешь назвать свойства у возвращаемых объектов.
  • Как передать на бекенд требования к API?

    @Vitsliputsli
    Антон Бреславский, поэтому и пишу "скорее всего" и многие, а не все. Дело не в унижении или оскорблении, если ваше восприятие совпадает, с описанном выше, то следует срочно его пересмотреть, т.к. здесь дело даже не в том, что что-то не знаешь или неправильно видишь, все мы что-то не знаем и где-то ошибаемся, а в том, что координально не правильно воспринимаешь и не знаешь базисных принципов, это катастрофично для проекта. Если выше написанное не про вас, не воспринимайте на свой счет, если что-то зацепило - то стоит задуматься.
    Вы правильно здесь пишите, но теперь перенесите это и на бек тоже, именно про это я писал, нисколько не умаляя сложностей фронтенд разработки, я остерегал от поверхностного отношения к беку. Огромный - это нисколько не показатель сложности для запроса в базу. Возможно у вас, действительно, на беке нет ничего сложного, а только запросы к бд, но даже в этом случае, нужно пересмотреть отношение к API, иначе это будет не интерфейс взаимодействия независимых сервисов, а прослойка, которая увеличит зацепленность и многократно усложнит их взаимодействие. Поэтому вопрос не в том, что "фронтенд проектирует API и делает это всегда плохо", а в том, что по вашему описанию, вы сейчас руководствуетесь неправильными принципами подходя к проектированию API, это и есть проблема. И речь не про swagger и yaml, или моки, или что фронт и бек умеют договариваться, тут все верно, но если бы все так и было, то не было бы и вопроса.
  • Как передать на бекенд требования к API?

    @Vitsliputsli
    Антон Бреславский, двойная работа и узкое место будут тогда, когда вы вместо API нафигачите узкоспециализированные запросы к беку, и при малейших изменениях на фронте или беке придется пределавать много и во многих местах.
  • Зачем в обычном проекте может понадобиться использование __invoke?

    @Vitsliputsli
    Максим Федоров, ну, может я и ретроградствую, время покажет.

    А что за DSL? Арифметические вычисления с алгеброй логики? Вызов одиночных функций с параметрами? Или язык с операторами, функциями, условиями и алгеброй логики?
  • Golang и PHP, дань моде или необходимость?

    @Vitsliputsli
    Роман Мирр, речь больше не про готовые решения, а про написание бизнес-логики: это работа с типами, это структуризация ООП. В Go придется относительно низкоуровнево работать с данными, что здесь не нужно, и тогда будет потрачено больше времени. А для какой-нибудь задачи чисто технической, скажем поднять ws-сервер и наладить его взаимодействие с очередью, там разницы особой не будет, т.к. Go действительно простой язык.
  • Зачем в обычном проекте может понадобиться использование __invoke?

    @Vitsliputsli
    Максим Федоров, спасибо большое за пример, теперь понятно о чем речь. Да, здесь уже функциональное, но зачем функциональное маскировать под ООП, сделали бы обычными функциями, было бы очевиднее. При процедурном или ООП подходе все выглядело бы еще проще, не проще только, если нужно переиспользование, но и здесь сохранить последовательность шагов не сильно усложнит код. И это я говорю без учета того, что там еще что наверчено внутри класса pipeline.
    ООП не процедурное программирование, от слова совсем. Да, в ООП зачастую не обойтись без отдельных процедурных вещей, впрочем как и в функциональном. Так что это заявление бессмысленно. Но в ООП это используется на нижнем уровне, и вы прекрасно можете использовать ООП по назначению - структурировать код. В функциональном не обойтись без процедурного на самом верхнем уровне, потому как структурировать функционально проблематично.
    Впрочем, спорить о ООП, функционально и процедурном бессмысленно. Я это уже подчеркивал выше, нравится вам функциональный - используйте, хоть прям внутри метода объекта, но маскировать функциональное программирование под ООП - это странно. А вытаскивать функциональное на верхний уровень параллельно с ООП - опасный подход. И выглядит это прекрасно только в примитивном примере с арифметическими опреациями над одной переменной и засчет отказа от функциональной записи и последовательного применения функций. Как-только будет чтото сложное - начнется ад, никто не пишет DSL функционально, поэтому фича забавная, но не более того.
  • Зачем в обычном проекте может понадобиться использование __invoke?

    @Vitsliputsli
    Роми, только, если вы завязались на тип callable и не можете с него слезть.
    Т.е. у вас есть метод:
    function method(callable $func)
    Вы можете создать мутанта $mut и скармливать его:
    $class->method($mut)
    а можете создать обычный объект Common $obj с методом methodLikeInvoke:
    $class->method([$mut,'methodLikeInvoke'])
    или так, как вы писали выше:
    $class->method('Common::methodLikeInvoke')
    Вариант с мутантом, работает, потому как можно сделать так $mut(). Это чистой воды процедурный подход, вы создали функцию и потом ее вызываете, в код случайно затесались какие-то объекты, но это уже не ООП.
    Еще раз, если вы используете процедурный подход, то вопросов нет, но если вы пишите с помощью ООП, то все эти функции из процедурщины нужно заменить на нормальные объекты. Чтото вроде такого:
    function method(ActionInterface $action) {
        return $action->methodLikeInvoke();
    }
    
    Interface ActionInterface 
    {
        public function methodLikeInvoke() : bool
    }
    Class Action implements ActionInterface
    {
        public function methodLikeInvoke() { ... }
    }

    Все, все в рамках ООП, используются объекты, никакой процедурщины, никаких процедурных функций, который нужно маскировать под объекты, никаких процедурных вызовов, контракты описаны, с указанием типов, никаких callable, которые не несет никакой информации о бизнес-объекте, а просто говорят что это функция, т.е. еще одна часть из процедурного подхода.
  • Зачем в обычном проекте может понадобиться использование __invoke?

    @Vitsliputsli
    Максим Федоров, ну где здесь функциональный? Функциональный это совсем другое, это функция в математическом понимании.
    Если вы объявляете функцию, а потом ее вызываете - это чистый процедурный подход. Если вы функцию замаскировали под объект, но все равно все работает как в предыдущем предложении - это процедурный подход. Если вы в классе наделали статических функций и вызываете только их - это процедурный подход со странным неймспейсами через классы.
    в любом случае в invoke и ответственность закрывается одна
    в случае паттернов появляется гибкость, да одни плюсы, минусов просто нет... не понимаю вас

    Это вам хочется верить, что ответственность одна, потому что у недообъекта только один метод-функция, ответственность абсолютно от этого не зависит, даже в одном методе можно нафигачить все что угодно.
    Второе предложение вообще не понял. О каких паттернах идет речь? И что за плюсы и минусы, можно их перечислить?
  • Зачем в обычном проекте может понадобиться использование __invoke?

    @Vitsliputsli
    Максим Федоров,
    вы ошибаетесь, если представить процесс объектом, то как раз его функциональное представление — наиболее лаконичное и целостное представление

    Если "масло масленное", то назовите
    $validator->process($obj)
    да, немного подлиннее, чем
    $validator($obj)
    но несколько лишних символов, это не та проблема, которую нужно решать путем ввода новой сущности мутанта "объект-функция" и переходом от ООП стиля к процедурному.

    По-моему, запись через invoke говорит о том, что нам нужна только функция, и мы не придумали как сделать нормальный объект. Быть может это действительно очень простой объект, а может просто не удачно выбранный. Но в любом случае, расширить его до нормального объекта уже не получится, он так и будет всегда недообъектом.
    Да, и введение новых сущностей, когда прекрасно можно обойтись без них, это ненужное усложнение и запутывание кода.
  • Зачем в обычном проекте может понадобиться использование __invoke?

    @Vitsliputsli
    Максим Федоров,
    а вот так лаконично
    class Validator {
    public function __invoke($data)
    }

    $validator($obj)

    а вот так еще лаконичнее:
    function validate($data)
    validate($obj)

    В ООП мы вводим объекты не потому что так лаконичнее, а потому что с их помощью структурируем код, поэтому зачастую приходится писать даже больше. Если вы пишите в процедурном стиле и объекты в него затесались случайно, то это норм, но это не ООП,
  • Зачем в обычном проекте может понадобиться использование __invoke?

    @Vitsliputsli
    Роми, процедурное, функциональное. Но я имел ввиду другое, если используем ООП, значит ориентироваться должны на объекты, а не на функции.
    А давайте посмотрим на этот метод:
    Guard

    /**
         * Retrieve the authenticated user for the incoming request.
         *
         * @param  \Illuminate\Http\Request  $request
         * @return mixed
         */
        public function __invoke(Request $request)
        {
            if ($user = $this->auth->guard(config('sanctum.guard', 'web'))->user()) {
                return $this->supportsTokens($user)
                            ? $user->withAccessToken(new TransientToken)
                            : $user;
            }
    
            if ($token = $request->bearerToken()) {
                $model = Sanctum::$personalAccessTokenModel;
    
                $accessToken = $model::findToken($token);
    
                if (! $accessToken ||
                    ($this->expiration &&
                     $accessToken->created_at->lte(now()->subMinutes($this->expiration)))) {
                    return;
                }
    
                return $this->supportsTokens($accessToken->tokenable) ? $accessToken->tokenable->withAccessToken(
                    tap($accessToken->forceFill(['last_used_at' => now()]))->save()
                ) : null;
            }
        }


    Круто, что есть описание: "Retrieve the authenticated user for the incoming request.", но почему-то return mixed, с чего бы это, если вроде как нам должен быть возвращен user, Почему не return User ?
    Внутри еще интересней:
    return $accessToken->tokenable->withAccessToken(
                    tap($accessToken->forceFill(['last_used_at' => now()]))->save()
                )

    Что это? save неожиданно что-то вернет и это будет "authenticated user"? Я бы не сказал, что это очень понятный код, поэтому invoke используется скорее всего просто потому, что автору так нравится.
  • Зачем в обычном проекте может понадобиться использование __invoke?

    @Vitsliputsli
    Роми,
    Но я все равно не понял :)
    А почему мы просто не можем вызвать
    SomeClass::someStaticMethodInsteadInvoke()
    в чем именно преимущество Invoke перед обычными методами?
    // я просто пытаюсь понять, могу ли я где-то применить Invoke в своих проектах, и главное: нужно ли мне это?))

    Правильно, что не поняли, т.к. вам никто и не ответил.
    Совершенно верно, можно просто указать метод, там где тип callable, и разницы нет никакой.
    А можно как, выше написал Лентюй, просто вызвать метод класса, а его необходимость описать в интерфейсе без всяких callable вовсе.
    Если вы используете ООП, то invoke вам не нужен, оперируйте объектами, а не функциями, и не мутантами вида "объект как функция".
  • Как защититься от двойного списания в многопоточном приложении?

    @Vitsliputsli
    Как раз уровень изоляции. При правильно выбранном уровне хрен чего второй прочитает, пока первый не завершит свою транзакцию и не отпустит ресурсы.

    А вы применяли этот уровень изоляции на хорошо нагруженной системе?