Николай

При использовании Lumen рано или поздно придется тащить пакеты из Laravel. Иногда это просто, иногда занимает много времени (я периодически работаю с Lumen, так что это практика, а не теория). С версии 5.2 Lumen четко обозначил свою область:

Lumen 5.2 represents a shift on slimming Lumen to focus solely on serving stateless, JSON APIs. As such, sessions and views are no longer included with the framework. If you need access to these features, you should use the full Laravel framework.

Да, в версии 5.8 еще по прежнему доступен illuminate/view. Но сессии, CSRF да и много чего еще придется тащить. В Laravel нет ничего сложного или избыточного для вашего сайта. Просто не используйте то, что вам не нужно. Остальное есть из коробки.

Так же решить любую проблему для Laravel намного легче, так как примеров для Laravel намного больше и их не надо адаптировать.

В общем, я бы не рекомендовал вам Lumen для сайта галереи.

Ну а какие варианты? Фронт где-то далеко в системе клиент-сервер. Если фронт закончил запрос к серверу, то для него, что очередь там, что не очередь. Т.е. в вопросе два момента:
1. Как фронт получает обновление статуса: либо обращается к нужному ендпоинту, либо поднимает веб-сокет соединение и слушает.
2. Как бэкенд понимает, что Job готов. Насколько я помню, в Laravel есть события для этого. Дальнейшая реализация обработки событий зависит от того, как фронт "слушает" изменения - выставляешь ты флаг для ендпоинта или отправляешь событие в сокет.

Я много лет долбался с Laravel Dusk, а недавно открыл cypress. Это просто сказка. Посмотри видосики на официальном сайте, поиграйся с ним - уверен, что он понравится.

Как уже верно отметили, надо не забывать про id в вашей связи. Ещё можно сделать динамически. В Laravel 5.5 и выше, можно попробовать сделать так:

\Request::user()->tickets()->with('messages.user:id,name,surname')->find($id);

Ну или типа такого:

\Request::user()->tickets()->with(['messages.user'=>function($query){
        $query->select('id', 'name', 'surname');
    }])->get();

P.S. Возможно, во всех случаях надо from_id возвращать, чтобы связь смогла разрешится. Попробовать надо.

Например, вот так:

it('Request', () => {
    cy.server()
    cy.route("POST", '/oauth/token').as('getToken')

    cy.get(['data-cy="button-get-token"]').click()

    cy.wait('@getToken').its('status').should('eq', 200)
  })

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

Итак, ситуация. Вам необходимо сделать возможность вставки своих виджетов в код сторонних сайтов. Для реализации этого сторонний сайт вставляет в свой код ваш JS-код. Далее ваш JS код вставляет виджет. Виджет можно вставить либо прямо в код страницы (далее прямая вставка в DOM) либо создать Iframe. Рассмотрим потенциальные проблемы обоих подходов.

JS конфликты
Прямая вставка в DOM
Здесь не должно быть конфликтов, когда используется “пространство имен”. Но при использовании сторонних библиотек, некоторые из них могут обращаться напрямую к window и это невозможно контролировать. Я столкнулся с проблемой когда vuetify обращается к window.$vue из своего кода и просто падает.

Iframe
Полная инкапсуляция, конфликты исключены

CSS конфликты
Прямая вставка в DOM
Потенциально очень серьёзные конфликты. Код внешнего сайта влияет на виджет, код виджета влияет на внешний сайт. Ваш виджет ломает внешний сайт, внешний сайт ломает ваш виджет.

Iframe
Полная инкапсуляция, конфликты исключены

Cookies (описанное ниже так же относится и к localStorage)
Если необходимо отправлять ваши кукисы из виджета

Прямая вставка в DOM
Мы не можем отправлять кукисы третьей-стороны из JS. Если использовать для отправки кукиса заголовки с сервера во время загрузки статики или скрытый iframe, то браузер будет опознавать их как кукисы третьей стороны. По современным оценкам кукисы третьей стороны отключены у 25-50% пользователей. И тренд такой, что это число будет только расти.

Iframe
Мы можем устанавливать свои кукисы, как кукисы первой стороны. Возможно, для некоторых браузеров, потребуется выполнить POST запрос для одобрения установки кукисов.

Безопасность
Прямая вставка в DOM
Если ваш виджет должен общаться с вашим сервером, то прямая вставка - это полный провал в безопасности. Для возможности выполнения запросов вам необходимо будет включить CORS (отключить same-origin policy). Это приведет к тому, что уязвимость, позволяющая исполнять код на внешнем сайте, позволит злоумышленнику отправлять запросы на ваш сервер от чужого имени, при стечении обстоятельств.

Еще одна проблема, если ваш виджет предоставляет какой-то функционал конечным посетителям сайта, то все их данные становятся доступны внешнему сайту (как владельцу, так и злоумышленнику способному интегрировать код). Так же владелец сайта сможет отправлять запросы от их имени. Короче, это фиаско.

Iframe
Продолжаем использовать same-origin policy. Данные виджета изолированы.

Заключение: единственный адекватный вариант - вставка через iframe.

P.S. Тимлида я обыграл. Но меня поражает: как люди с такими познаниями становятся тимлидами с зп >700к (это не Россия, но все равно дофига)?!

Note: While this concept looks similar to the object property feature, there is an important difference. For normal object properties the property value is of the same type as the defining getter method. A relation method however returns an yii\db\ActiveQuery instance, while accessing a relation property will either return a yii\db\ActiveRecord instance or an array of these.

Yii2 docs

У меня хоть и не связи, но логика та же применяется.

Используйте сессии. А вот где уже их будете хранить - дело третье. Неоспоримым плюсом сессий является то, что можете легко изменить их место/способ хранения не затрагивая логику приложения. По умолчанию сессии хранятся в файлах, но легко переделываются на хранение в БД (что позволяет очень гибко с ними работать, да и при больших объемах БД ведет себя увереннее файлов - несколько лет назад было так, может сейчас уже и файлы подтянулись), если не хватает скорости, то есть расширения для php которые хранилищем сессий делают в memcache или redis (в тяжелых проектах сам использую этот вариант - можно смело говорить о десятках тысяч сессий). Используя механизм сессий, вы сможете переключаться между типом хранения буквально за 5 минут.

Только обратите внимание, что если вы измените настройки пользователя в соответствующей ему записи в БД, то в сессии они еще останутся старыми. Этим надо будет управлять. Все зависит от целей приложения. Но в любом случае, сессия берет на себя передачу данных между запросами, и почему бы не вынести в нее часть информации. Вы же все равно как-то передаете логин и статус, что пользователь залогенен, скорее всего используете сессии. А если сессия у вас уже есть, то она будет быстрее вытаскивать еще некоторое количество информации о пользователе.

Я думаю, нужно делать так, как вам удобнее. Универсального решения для абстрактного проекта не бывает. Оптимизировать на начальном этапе тут нечего.