Привет, спасибо за видос! Я правильно понял, что в концепции GraphQL не представляется возможным сделать кастумный вывод. Например если я хочу отдать структуру, в которой наименования полей будут отличаться от названия полей в базе или захочу добавить кастумныхз пару полей, то GraphQL не мой случай?
Добрый день! Можно запросто переименовать поле на любое другое название, то что Вы хотите называется alias, вот небольшой пример квери: query { getUsers { id userName: name } } Из примера понятно, что сервер переименует поле name (хранящееся в базе) в userName (это то что увидит пользователь).
@@pavelzloi Спасибо, круть! А есть возможность добавления произвольной вложенности? Или например привязки не к модели данных Eloquent, а к неким dto-шкам?
@@andreydmitriyev4582 конечно можно, но это нужно описывать в типах данных схемы графа и ещё реализовывать кастомные квери, способные возвращать произвольные наборы данных отличных от базы. Просто это уже немного выходит за стандартный набор возможностей и каждую фичу нужно будет прорабатывать отдельно, но ничего сложного в этом нет, не волнуйтесь :)
10:00 GraphQl playground содержит устаревший websockets client, если вручную собрать (а есть специальная artisan command), возможно и заработает 20:30 Решение сделано, возможно, для того чтобы у каждого пользователя была собственная подписка, мол если есть права админа, то ради тебя особенного lighthouse сделает отдельный запрос в pusher из этого иная проблема, (если будет 1000 пользователей), то необходимо на pusher сделать 1000 запросов, ну такое.... (хотя могу ошибаться)
Приветствую! Благодарю за комментарий. Да, мобильное приложения делал (к сожалению оно ещё пока не зарелизено и у меня NDA, поэтому рассказать подробности не могу пока), в принципе разницы со SPA на JS особой нет, везде используется клиент аполло или вариации на тему, единственное что было сложно реализовать так это сабскрипшены. Но и с ними по итогу получилось разобраться.
Ещё раз внимательно перечитал комментарий, мобильные приложения делал на разных технологиях как на чистом rest так и на soap. В целом особой разницы между технологиями нет, ведь задача отправить с клиента запрос, а серверу ответить на него данными из базы. Технология на самом деле вообще не имеет значения, важна только бизнес логика которую эта технология должна решать :)
Думаю, что претензии к lighthouse не очень обоснованные. Проблема subscribtion растёт скорее из laravel, а если глубже копнуть - то из php. Разработчики lighthouse неплохо реализовали subscribtion поверх стандартного laravel broadcast механизма. Выглядит конечно коряво, но в php с websocket по другому никак. Имхо было бы гораздо хуже, если б lighthouse тащил собственную реализацию websocket/broadcast. Pusher можно подменить beyondcode/laravel-websockets. По поводу версионирования - из того что я понял про GraphQL - бест практисом считается отсутствие такового - в этом плане lighthouse не отличается от других решений. См волшебные директивы типа @deprecated
Добрый вечер! Благодарю за комментарий, насчёт претензий соглашусь, данный плагин настолько великолепен, что я с трудом смог набрать 9 вещей которые мне не понравились, и то как понятно из видеоролика больше половины к Lighthouse (LH) не относятся. Основной посыл данного видео это обратить внимание аудитории к небольшим проблемам, решение которых поможет сделать проект лучше :) Насчёт вебсокетов, их мне больше нравится реализовывать через например socketio или на пыхе через react-php, тут уж дело вкуса и очень зависит от решаемой задачи, в принципе в паре с LH можно реализовать практически любой механизм взаимодействия с клиентами, но мне не понравилось что разработчики LH не описали это в доке, да хотя бы в двух словах сказали что Pusher это лишь один вариант из великого множества (о том что это так я пришёл спустя несколько дней тщетных попыток понять что я делаю не так). Насчёт версионирования, авторы GraphQL явно пишут на своём сайте, что программистам ничего не мешает такую фичу реализовать и это как раз таки и является best practice graphql.org/learn/best-practices/#versioning А вот то что этого нет в Lighthouse скорее недостаток плагина, ведь даже во всяких генераторах свагер документации или простеньких плагинах для Laravel часто есть поддержка множества подключений, хороший пример это github.com/cviebrock/laravel-elasticsearch в нём данный подход реализован на мой скромный взгляд почти идеально. Но учитывая текущее состояние кодовой базы и то что многие параметры то тут то там используют абсолютные пути из конфига вместо того чтобы работать с некоей абатрактной сущностью передающейся через конструктор, и переделать это будет большой проблемой, но уверен такая проблема возникала не у одного лишь меня и рано или поздно будет решена совместными усилиями.
@@pavelzloi хм.. возможно я не очень в инглише, но по ссылке которая про версионирование, я читаю что-то вроде: Хотя нет ничего, что препятствовало бы управлению версиями службы GraphQL, как и любого другого REST API, GraphQL твердо придерживается мнения о том, чтобы избежать управления версиями, предоставляя инструменты для непрерывного развития схемы GraphQL. Т.е. вместо версионирования они предлагают постепенное развитие схемы ( добавление новых типов и @deprecated старых ) Про варианты websocket: beyondcode/laravel-websockets - это обвязка над react-php и, как вариант для nodejs, есть laravel-echo-server , который также подменяет pusher Про качество кода и гибкость сказать ничего не могу, т.к. не пользовался LH. В LH меня лично подкупает возможность быстро набросать прототип, который можно очень быстро изменять. Имхо именно возможность быстро вносить изменения выгодно отличает LH от rest api (если сравнивать LH vs rest api в laravel). Имхо, с rest-api приходится очень много "думать", особенно когда появляются relation-ы в моделях , когда появляется нужда в rpc-like вызовах (смена статуса и тп), или когда модельки начинают вылазить за пределы "банального" CRUD (документ со строками и тп). Судя по всему LH позволяет решить эту проблему . Своего мнения по LH у меня пока не сложилось - на уровне подходов всё очень радостно и позитивно, я почти поверил в то, что можно не вылазить дальше моделек и схемы. Понятно, что по всем законами природы в этой бочке мёда должна присутствовать и ложка дёгтя, но очень сильно надеюсь с ней не встретится. Так же очень удивило и порадовало то, как можно работать с morphTo- релейшенами в graphql и в самом LH, особенно учитывая что работает оно из коробки.
> хм.. возможно я не очень в инглише, но по ссылке которая про версионирование, я читаю что-то вроде: Вы всё верно поняли по ссылке про версионирование, считайте это моей вкусовщиной или даже шишками набитыми в процесс работы, но лично я считаю что более безопасно не трогать уже работающую схему, особенно когда эта схема нужна для работы текущего приложения. Одно дело вебсайт, который собирается тут же через laravel-mix и деплоится вместе с API, другое дело мобильные приложения, которые юзеры могут не обновлять месяцами, и вот я послушав что «версионирование не нужно» выкатываю новую версию и теряю часть клиентов, после чего хозяин бизнеса вполне обоснованно считает виноватым меня, с точки зрения бизнеса это неправильно :) Поэтому лично мне было бы гораздо удобнее если бы версионирование таки было (хотя бы опционально), но как я сказал в видео его отсутствие вообще не проблема если придерживаться идеи с несколькими бренчами и CI которая из этих бренчей собирает контейнеры и деплоит на прод, после чего роутингом уже занимается Ingress. > Про варианты websocket: beyondcode/laravel-websockets - это обвязка над react-php и, как вариант для nodejs, есть laravel-echo-server , который также подменяет pusher Вот о том что можно вместо Pusher использовать что угодно я узнал лишь на второй день экспериментов с type Subscription, а было бы это сказано в доке, то вероятно справился бы за один день. > Про качество кода и гибкость сказать ничего не могу, т.к. не пользовался LH. В целом проект LH прекрасен, есть лишь небольшие моменты, которые мне не нравятся, очень рекомендую реализовать что-нибудь простое, дабы распробовать LH во всей красе. > В LH меня лично подкупает возможность быстро набросать прототип, который можно очень быстро изменять. Имхо именно возможность быстро вносить изменения выгодно отличает LH от rest api (если сравнивать LH vs rest api в laravel). Меня тоже поразила скорость с которой я добираюсь от пустого проекта до полноценного MVP написанного с использованием большинства современных паттернов, в том числе и с тестами (как юнит, так и интеграционными). Вспоминая сколько времени я тратил на тоже самое используя REST подход становится дурно. А к REST'у ведь ещё надо документацию прикрутить чтобы фронтендеры могли самостоятельно разобраться с API, а за этой документацией надо пристально следить. > Так же очень удивило и порадовало то, как можно работать с morphTo- релейшенами в graphql и в самом LH, особенно учитывая что работает оно из коробки. На мой взляд лучше переложить это на плечи Elouqent и описать в моделях что требуется, хотя сама возможность очень радует, как в принципе вообще все возможности которые даёт LH, это на мой взгляд один из лучших плагинов для Laravel с которым мне доводилось работать.
Добрый день. Посмотрел видео, согласен LH не идеален, вот сейчас сам столкнулся с проблемой как написать where для связей, но вот по поводу create не согласен, вы можете посмотреть в документации как в связях делать изменения lighthouse-php.com/4.18/eloquent/nested-mutations.html#belongsto . А вот если знаете как применить where для связей, то буду благодарен такому видосу, с меня прям троекратный лайк будет)
Добрый день! Прошу прощения за столь долгкий ответ, ютуб по какой-то причине посчитал что Ваш комментарий не проходит какие-то их правила и комменатарий висел во вкладке ожидания одобрения (нотификаций о сообщения попадающих туда понятное дело нет), возможно всё дело в ссылке, поэтому я только сейчас увидел :) Насчёт @where для связей если честно не пробовал, но подозреваю что через кастомный метод или специальный builder что-то такое запилить всё таки получится, обычно @where я использую для поиска в переделах таблицы, дальше не хожу, для решения моих кейсов этого как правило хватает. Скорее всего в Вашем случае придётся писать кастомный обработчик такого рода запросов на стороне моделей бэкенда, делается это просто, дальше надо будет лишь вывести модели в схему и описать что можно передавать. PS. За ссылочку спасибо, не знал что можно и таким способом работать с моделями через LH, как-то по старинке привычнее, хотя описанный в доке вариант намного изящнее.
Павел, привет! Весь твой канал перерыл, но не нашёл ни одной ссылки хоть на какую-либо соц.сеть, где с тобой можно связаться)) Волнуют вопросы касательно связки Blade с Vue. Можешь оставить хоть какие-то контакты? Заранее спасибо
Добрый день! В соц.сетях присутствую, например в Twitter или Discord, прочие типа VK или Facebook не использую из-за неоднозначного отношения у этих соц.сетей к персональным данным :)
![[UA] Team Vitality проти NAVI | IEM Cologne 2024](http://i.ytimg.com/vi/wttO1zVRTC0/mqdefault.jpg)
GraphQL же не предпологает версионирования в классическом понимании )
Привет, спасибо за видос!
Я правильно понял, что в концепции GraphQL не представляется возможным сделать кастумный вывод.
Например если я хочу отдать структуру, в которой наименования полей будут отличаться от названия полей в базе или захочу добавить кастумныхз пару полей, то GraphQL не мой случай?
Добрый день! Можно запросто переименовать поле на любое другое название, то что Вы хотите называется alias, вот небольшой пример квери:
query {
getUsers {
id
userName: name
}
}
Из примера понятно, что сервер переименует поле name (хранящееся в базе) в userName (это то что увидит пользователь).
@@pavelzloi Спасибо, круть! А есть возможность добавления произвольной вложенности? Или например привязки не к модели данных Eloquent, а к неким dto-шкам?
@@andreydmitriyev4582 конечно можно, но это нужно описывать в типах данных схемы графа и ещё реализовывать кастомные квери, способные возвращать произвольные наборы данных отличных от базы.
Просто это уже немного выходит за стандартный набор возможностей и каждую фичу нужно будет прорабатывать отдельно, но ничего сложного в этом нет, не волнуйтесь :)
@@pavelzloi Благодарю за ответ!
10:00 GraphQl playground содержит устаревший websockets client, если вручную собрать (а есть специальная artisan command), возможно и заработает
20:30 Решение сделано, возможно, для того чтобы у каждого пользователя была собственная подписка, мол если есть права админа, то ради тебя особенного lighthouse сделает отдельный запрос в pusher из этого иная проблема, (если будет 1000 пользователей), то необходимо на pusher сделать 1000 запросов, ну такое.... (хотя могу ошибаться)
Приветствую, Ян! Благодарю за замечание, постараюсь учесть этот момент при записи следующего уточняющего видеоролика про Lighthouse.
А мобильное приложение на какой технологии делал ?
Приветствую! Благодарю за комментарий. Да, мобильное приложения делал (к сожалению оно ещё пока не зарелизено и у меня NDA, поэтому рассказать подробности не могу пока), в принципе разницы со SPA на JS особой нет, везде используется клиент аполло или вариации на тему, единственное что было сложно реализовать так это сабскрипшены. Но и с ними по итогу получилось разобраться.
Ещё раз внимательно перечитал комментарий, мобильные приложения делал на разных технологиях как на чистом rest так и на soap. В целом особой разницы между технологиями нет, ведь задача отправить с клиента запрос, а серверу ответить на него данными из базы. Технология на самом деле вообще не имеет значения, важна только бизнес логика которую эта технология должна решать :)
Думаю после реализации 3 - 5 разных апи, разработка последующих превращается в копипаст с незначительными изменениями)
Привет! Совершенно верно, но зачастую можно скопировать далеко не всё, а лишь что-то общее.
Думаю, что претензии к lighthouse не очень обоснованные. Проблема subscribtion растёт скорее из laravel, а если глубже копнуть - то из php. Разработчики lighthouse неплохо реализовали subscribtion поверх стандартного laravel broadcast механизма. Выглядит конечно коряво, но в php с websocket по другому никак. Имхо было бы гораздо хуже, если б lighthouse тащил собственную реализацию websocket/broadcast. Pusher можно подменить beyondcode/laravel-websockets.
По поводу версионирования - из того что я понял про GraphQL - бест практисом считается отсутствие такового - в этом плане lighthouse не отличается от других решений. См волшебные директивы типа @deprecated
Добрый вечер! Благодарю за комментарий, насчёт претензий соглашусь, данный плагин настолько великолепен, что я с трудом смог набрать 9 вещей которые мне не понравились, и то как понятно из видеоролика больше половины к Lighthouse (LH) не относятся.
Основной посыл данного видео это обратить внимание аудитории к небольшим проблемам, решение которых поможет сделать проект лучше :)
Насчёт вебсокетов, их мне больше нравится реализовывать через например socketio или на пыхе через react-php, тут уж дело вкуса и очень зависит от решаемой задачи, в принципе в паре с LH можно реализовать практически любой механизм взаимодействия с клиентами, но мне не понравилось что разработчики LH не описали это в доке, да хотя бы в двух словах сказали что Pusher это лишь один вариант из великого множества (о том что это так я пришёл спустя несколько дней тщетных попыток понять что я делаю не так).
Насчёт версионирования, авторы GraphQL явно пишут на своём сайте, что программистам ничего не мешает такую фичу реализовать и это как раз таки и является best practice graphql.org/learn/best-practices/#versioning
А вот то что этого нет в Lighthouse скорее недостаток плагина, ведь даже во всяких генераторах свагер документации или простеньких плагинах для Laravel часто есть поддержка множества подключений, хороший пример это github.com/cviebrock/laravel-elasticsearch в нём данный подход реализован на мой скромный взгляд почти идеально.
Но учитывая текущее состояние кодовой базы и то что многие параметры то тут то там используют абсолютные пути из конфига вместо того чтобы работать с некоей абатрактной сущностью передающейся через конструктор, и переделать это будет большой проблемой, но уверен такая проблема возникала не у одного лишь меня и рано или поздно будет решена совместными усилиями.
@@pavelzloi хм.. возможно я не очень в инглише, но по ссылке которая про версионирование, я читаю что-то вроде:
Хотя нет ничего, что препятствовало бы управлению версиями службы GraphQL, как и любого другого REST API, GraphQL твердо придерживается мнения о том, чтобы избежать управления версиями, предоставляя инструменты для непрерывного развития схемы GraphQL.
Т.е. вместо версионирования они предлагают постепенное развитие схемы ( добавление новых типов и @deprecated старых )
Про варианты websocket: beyondcode/laravel-websockets - это обвязка над react-php и, как вариант для nodejs, есть laravel-echo-server , который также подменяет pusher
Про качество кода и гибкость сказать ничего не могу, т.к. не пользовался LH.
В LH меня лично подкупает возможность быстро набросать прототип, который можно очень быстро изменять. Имхо именно возможность быстро вносить изменения выгодно отличает LH от rest api (если сравнивать LH vs rest api в laravel).
Имхо, с rest-api приходится очень много "думать", особенно когда появляются relation-ы в моделях , когда появляется нужда в rpc-like вызовах (смена статуса и тп), или когда модельки начинают вылазить за пределы "банального" CRUD (документ со строками и тп). Судя по всему LH позволяет решить эту проблему .
Своего мнения по LH у меня пока не сложилось - на уровне подходов всё очень радостно и позитивно, я почти поверил в то, что можно не вылазить дальше моделек и схемы. Понятно, что по всем законами природы в этой бочке мёда должна присутствовать и ложка дёгтя, но очень сильно надеюсь с ней не встретится.
Так же очень удивило и порадовало то, как можно работать с morphTo- релейшенами в graphql и в самом LH, особенно учитывая что работает оно из коробки.
> хм.. возможно я не очень в инглише, но по ссылке которая про версионирование, я читаю что-то вроде:
Вы всё верно поняли по ссылке про версионирование, считайте это моей вкусовщиной или даже шишками набитыми в процесс работы, но лично я считаю что более безопасно не трогать уже работающую схему, особенно когда эта схема нужна для работы текущего приложения.
Одно дело вебсайт, который собирается тут же через laravel-mix и деплоится вместе с API, другое дело мобильные приложения, которые юзеры могут не обновлять месяцами, и вот я послушав что «версионирование не нужно» выкатываю новую версию и теряю часть клиентов, после чего хозяин бизнеса вполне обоснованно считает виноватым меня, с точки зрения бизнеса это неправильно :)
Поэтому лично мне было бы гораздо удобнее если бы версионирование таки было (хотя бы опционально), но как я сказал в видео его отсутствие вообще не проблема если придерживаться идеи с несколькими бренчами и CI которая из этих бренчей собирает контейнеры и деплоит на прод, после чего роутингом уже занимается Ingress.
> Про варианты websocket: beyondcode/laravel-websockets - это обвязка над react-php и, как вариант для nodejs, есть laravel-echo-server , который также подменяет pusher
Вот о том что можно вместо Pusher использовать что угодно я узнал лишь на второй день экспериментов с type Subscription, а было бы это сказано в доке, то вероятно справился бы за один день.
> Про качество кода и гибкость сказать ничего не могу, т.к. не пользовался LH.
В целом проект LH прекрасен, есть лишь небольшие моменты, которые мне не нравятся, очень рекомендую реализовать что-нибудь простое, дабы распробовать LH во всей красе.
> В LH меня лично подкупает возможность быстро набросать прототип, который можно очень быстро изменять. Имхо именно возможность быстро вносить изменения выгодно отличает LH от rest api (если сравнивать LH vs rest api в laravel).
Меня тоже поразила скорость с которой я добираюсь от пустого проекта до полноценного MVP написанного с использованием большинства современных паттернов, в том числе и с тестами (как юнит, так и интеграционными). Вспоминая сколько времени я тратил на тоже самое используя REST подход становится дурно.
А к REST'у ведь ещё надо документацию прикрутить чтобы фронтендеры могли самостоятельно разобраться с API, а за этой документацией надо пристально следить.
> Так же очень удивило и порадовало то, как можно работать с morphTo- релейшенами в graphql и в самом LH, особенно учитывая что работает оно из коробки.
На мой взляд лучше переложить это на плечи Elouqent и описать в моделях что требуется, хотя сама возможность очень радует, как в принципе вообще все возможности которые даёт LH, это на мой взгляд один из лучших плагинов для Laravel с которым мне доводилось работать.
Добрый день.
Посмотрел видео, согласен LH не идеален, вот сейчас сам столкнулся с проблемой как написать where для связей, но вот по поводу create не согласен, вы можете посмотреть в документации как в связях делать изменения lighthouse-php.com/4.18/eloquent/nested-mutations.html#belongsto . А вот если знаете как применить where для связей, то буду благодарен такому видосу, с меня прям троекратный лайк будет)
Добрый день! Прошу прощения за столь долгкий ответ, ютуб по какой-то причине посчитал что Ваш комментарий не проходит какие-то их правила и комменатарий висел во вкладке ожидания одобрения (нотификаций о сообщения попадающих туда понятное дело нет), возможно всё дело в ссылке, поэтому я только сейчас увидел :)
Насчёт @where для связей если честно не пробовал, но подозреваю что через кастомный метод или специальный builder что-то такое запилить всё таки получится, обычно @where я использую для поиска в переделах таблицы, дальше не хожу, для решения моих кейсов этого как правило хватает.
Скорее всего в Вашем случае придётся писать кастомный обработчик такого рода запросов на стороне моделей бэкенда, делается это просто, дальше надо будет лишь вывести модели в схему и описать что можно передавать.
PS. За ссылочку спасибо, не знал что можно и таким способом работать с моделями через LH, как-то по старинке привычнее, хотя описанный в доке вариант намного изящнее.
Павел, привет! Весь твой канал перерыл, но не нашёл ни одной ссылки хоть на какую-либо соц.сеть, где с тобой можно связаться)) Волнуют вопросы касательно связки Blade с Vue. Можешь оставить хоть какие-то контакты? Заранее спасибо
всё зависит от того, с какими целями связь. А так комменты Павел читает иправно. Чем комменты не связь?
@@compolomus9719 мне необходимо личное обращение. Для меня это принципиально.
Добрый день! В соц.сетях присутствую, например в Twitter или Discord, прочие типа VK или Facebook не использую из-за неоднозначного отношения у этих соц.сетей к персональным данным :)