Laravel Lighthouse #6 - Критика

[@andreydmitriyev4582]

Привет, спасибо за видос! Я правильно понял, что в концепции GraphQL не представляется возможным сделать кастумный вывод. Например если я хочу отдать структуру, в которой наименования полей будут отличаться от названия полей в базе или захочу добавить кастумныхз пару полей, то GraphQL не мой случай?

[@pavelzloi]

Добрый день! Можно запросто переименовать поле на любое другое название, то что Вы хотите называется alias, вот небольшой пример квери: query { getUsers { id userName: name } } Из примера понятно, что сервер переименует поле name (хранящееся в базе) в userName (это то что увидит пользователь).

[@andreydmitriyev4582]

@@pavelzloi Спасибо, круть! А есть возможность добавления произвольной вложенности? Или например привязки не к модели данных Eloquent, а к неким dto-шкам?

[@pavelzloi]

@@andreydmitriyev4582 конечно можно, но это нужно описывать в типах данных схемы графа и ещё реализовывать кастомные квери, способные возвращать произвольные наборы данных отличных от базы. Просто это уже немного выходит за стандартный набор возможностей и каждую фичу нужно будет прорабатывать отдельно, но ничего сложного в этом нет, не волнуйтесь :)

[@andreydmitriyev4582]

@@pavelzloi Благодарю за ответ!

[@gnidkoav]

GraphQL же не предпологает версионирования в классическом понимании )

[@ЯнГус-х7д]

10:00 GraphQl playground содержит устаревший websockets client, если вручную собрать (а есть специальная artisan command), возможно и заработает 20:30 Решение сделано, возможно, для того чтобы у каждого пользователя была собственная подписка, мол если есть права админа, то ради тебя особенного lighthouse сделает отдельный запрос в pusher из этого иная проблема, (если будет 1000 пользователей), то необходимо на pusher сделать 1000 запросов, ну такое.... (хотя могу ошибаться)

[@pavelzloi]

Приветствую, Ян! Благодарю за замечание, постараюсь учесть этот момент при записи следующего уточняющего видеоролика про Lighthouse.

[@sliders23]

А мобильное приложение на какой технологии делал ?

[@pavelzloi]

Приветствую! Благодарю за комментарий. Да, мобильное приложения делал (к сожалению оно ещё пока не зарелизено и у меня NDA, поэтому рассказать подробности не могу пока), в принципе разницы со SPA на JS особой нет, везде используется клиент аполло или вариации на тему, единственное что было сложно реализовать так это сабскрипшены. Но и с ними по итогу получилось разобраться.

[@pavelzloi]

Ещё раз внимательно перечитал комментарий, мобильные приложения делал на разных технологиях как на чистом rest так и на soap. В целом особой разницы между технологиями нет, ведь задача отправить с клиента запрос, а серверу ответить на него данными из базы. Технология на самом деле вообще не имеет значения, важна только бизнес логика которую эта технология должна решать :)

[@kuzuru]

Павел, привет! Весь твой канал перерыл, но не нашёл ни одной ссылки хоть на какую-либо соц.сеть, где с тобой можно связаться)) Волнуют вопросы касательно связки Blade с Vue. Можешь оставить хоть какие-то контакты? Заранее спасибо

[@compolomus9719]

всё зависит от того, с какими целями связь. А так комменты Павел читает иправно. Чем комменты не связь?

[@kuzuru]

@@compolomus9719 мне необходимо личное обращение. Для меня это принципиально.

[@pavelzloi]

Добрый день! В соц.сетях присутствую, например в Twitter или Discord, прочие типа VK или Facebook не использую из-за неоднозначного отношения у этих соц.сетей к персональным данным :)

[@123krip]

Добрый день. Посмотрел видео, согласен LH не идеален, вот сейчас сам столкнулся с проблемой как написать where для связей, но вот по поводу create не согласен, вы можете посмотреть в документации как в связях делать изменения lighthouse-php.com/4.18/eloquent/nested-mutations.html#belongsto . А вот если знаете как применить where для связей, то буду благодарен такому видосу, с меня прям троекратный лайк будет)

[@pavelzloi]

Добрый день! Прошу прощения за столь долгкий ответ, ютуб по какой-то причине посчитал что Ваш комментарий не проходит какие-то их правила и комменатарий висел во вкладке ожидания одобрения (нотификаций о сообщения попадающих туда понятное дело нет), возможно всё дело в ссылке, поэтому я только сейчас увидел :) Насчёт @where для связей если честно не пробовал, но подозреваю что через кастомный метод или специальный builder что-то такое запилить всё таки получится, обычно @where я использую для поиска в переделах таблицы, дальше не хожу, для решения моих кейсов этого как правило хватает. Скорее всего в Вашем случае придётся писать кастомный обработчик такого рода запросов на стороне моделей бэкенда, делается это просто, дальше надо будет лишь вывести модели в схему и описать что можно передавать. PS. За ссылочку спасибо, не знал что можно и таким способом работать с моделями через LH, как-то по старинке привычнее, хотя описанный в доке вариант намного изящнее.

[@compolomus9719]

Думаю после реализации 3 - 5 разных апи, разработка последующих превращается в копипаст с незначительными изменениями)

[@pavelzloi]

Привет! Совершенно верно, но зачастую можно скопировать далеко не всё, а лишь что-то общее.

[@zenkovr]

Думаю, что претензии к lighthouse не очень обоснованные. Проблема subscribtion растёт скорее из laravel, а если глубже копнуть - то из php. Разработчики lighthouse неплохо реализовали subscribtion поверх стандартного laravel broadcast механизма. Выглядит конечно коряво, но в php с websocket по другому никак. Имхо было бы гораздо хуже, если б lighthouse тащил собственную реализацию websocket/broadcast. Pusher можно подменить beyondcode/laravel-websockets. По поводу версионирования - из того что я понял про GraphQL - бест практисом считается отсутствие такового - в этом плане lighthouse не отличается от других решений. См волшебные директивы типа @deprecated

[@pavelzloi]

Добрый вечер! Благодарю за комментарий, насчёт претензий соглашусь, данный плагин настолько великолепен, что я с трудом смог набрать 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 в нём данный подход реализован на мой скромный взгляд почти идеально. Но учитывая текущее состояние кодовой базы и то что многие параметры то тут то там используют абсолютные пути из конфига вместо того чтобы работать с некоей абатрактной сущностью передающейся через конструктор, и переделать это будет большой проблемой, но уверен такая проблема возникала не у одного лишь меня и рано или поздно будет решена совместными усилиями.

[@zenkovr]

​@@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, особенно учитывая что работает оно из коробки.

[@pavelzloi]

> хм.. возможно я не очень в инглише, но по ссылке которая про версионирование, я читаю что-то вроде: Вы всё верно поняли по ссылке про версионирование, считайте это моей вкусовщиной или даже шишками набитыми в процесс работы, но лично я считаю что более безопасно не трогать уже работающую схему, особенно когда эта схема нужна для работы текущего приложения. Одно дело вебсайт, который собирается тут же через 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 с которым мне доводилось работать.