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

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

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

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

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

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

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

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

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

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

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

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

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

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